Sprint 6 Retrospective

This sprint was a combination of trivial issues and minor successes. The biggest goal that we were able to complete was tackling the add method. Since the beginning of this project, it has been giving us nothing but issues. The first time we wrote that method, it wouldn’t accept JSON objects, only generic objects. Then we were having issues seeing the JSON data when we knew the object had been pushed to the PouchDB instance. Eventually, we were able to add a full object but we were having issues with the revision number and id fields. Finally, we are now able to add an object, when we call a collection of promises that include error catching statements. This was a large feat for our group and something that we are very proud of.

I would have to say the hardest part about this past weeks sprint was understanding the promises in TypeScript. For someone that wasn’t too familiar with this language at the beginning of the semester, I felt as thought I should have covered this earlier. Also, I was adopting more Java and JavaScript style coding during development, which does not translate well to TypeScript. My beginner skills definitely contributed to me not being able to implement the sequence of promises required to get the add method working, even thought I understood the fundamentals behind design. Regardless, I wish I spent more time researching and practicing implementing promises for asynchronous programs, for that would have largely benefited us.

Another issues that I believe our group struggled with was the testing aspect and creating the singleton pattern for our code. It is very hard to test this asynchronous style code, especially when we didn’t have enough time to use integration testing. Also, we were trying to initiate a singleton design pattern, but experienced issues when we tried to declare the constructor private, but it didn’t exhibit private properties when ran. Due to this error, our program cannot be truly singleton, and we should have tried to structure our program after this pattern earlier in development. This issue is something that we have not come to fully understand yet, for it is an odd phenomena. The testing aspect of this project was also problematic and time consuming. While it is difficult to test when implementing new methods in a new program with a new language, we should have advocated for more test driven development. However, at the time of writing our code, our priority was to write code, get results, and then act upon them. The testing portion of this project was always in the back of our mind, but it proved more difficult as time went on, and we would collect additional warning and errors as a result. Next time I will be more adamant about testing earlier, while learning, even though that seems challenging.

Overall, this final project has taught me a lot about developing in a new language in a team setting. There are a variety of things that I would do differently and an abundance of things that I would put more effort into trying.

Leave a comment