Implementation

A software development practice we used was refactoring. One way the code was refactored was by improving readability of the code and reducing repetition. This was done through extracting repeated blocks of code into functions. Moreover, we followed the SOLID principles - Single Responsibility to ensure classes have one responsibility. Some of the functions from the Model class were moved into their respective Note and Notebook classes, which increases cohesion.

Since our group consists of developers at different skill levels, we did a lot of pair programming and coded together. This included class time and joining group calls together at night or during the weekend. This gave us more opportunities to bounce ideas and clarify any misunderstandings. In the case where we were unsure about how to complete a task, others could pitch in their ideas. Through these sessions, everyone understands sections that others are working on and can learn from how they approach their respective tasks. This was particularly effective especially with simplifying solutions and finding better/more effective solutions.

Similar to this practice, we also used peer review for merge requests. Every task is completed in a different branch from master and whenever the task is completed, we put in a merge request. Everyone must go through the pushed code and approve the request before it can be merged with master. If there is any problem that is found, it would be commented on in the merge request and a notification will be sent to the person who created the request. This avoids merging any issues that we oversaw and can get it fixed immediately. This also avoids adding any unwanted files into the main program.

Finally, we also did standup meetings at the beginning of every class. Each person in the group talks about what they did before coming to class, what they plan to complete before next class and if they have any blockers. This ensures that everyone is on track for completing their assigned tasks. It also gives us the opportunity to go over any problems that we may have and brainstorm how we can solve it. This practice didn’t work very well for our team because although we had these meetings, we often forgot to fill out a tracking form. So looking back the sheet may not have been as accurate to what everyone was working on. There were unfinished tasks in our sprints and adapting work load could have gone better if our standup tracking was more accurate.

Overall, we worked in an agile environment in which we worked in sprints. For each sprint we would start off by assigning tasks from the sprint backlog. In between, we would have our scrum meetings at the beginning of the class. There would also be testing once a feature was finished and at the end of the sprint, we would reflect and evaluate on what has been completed. This helps us adjust and be more efficient in the next sprint.