Best Practices

The requirement sections identified “best practices” that you are expected to follow. Here are expanded details:

Project Practices

Practices related to communication, and tracking the project at a high-level.

Project tracking

You must create a GitLab project on the UW GitLab server, where you will store all of your project assets, including source code. Source code must be regularly committed to this repository.

Issue tracking

You must log all project tasks and the details of your work as issues in GitLab. Each project deliverable should be tracked as a `milestone` in GitLab. You should define the following milestones in your project:

• Proposal - tasks towards Proposal goals
• Sprint 1 - tasks towards Demo 1 goals
• Sprint 2 - tasks towards Demo 2 goals
• Sprint 3 - tasks towards Demo 3 goals
• Sprint 4 - tasks towards Demo 4 goals
• Release - tasks towards your software release

Issues must be logged for all work attempted in this course. Issues should be assigned and managed by team members during each sprint. See the Project > Sprints page for further details on assigning work.

Team members are responsible for updating issues with the details of the work that they have done, and closing issues when the task is complete.

Team meetings

You and your team will regroup at least twice per week and keep minutes of these meetings. You must take `team meeting minutes` when you meet. These can be brief, but should document any decisions that the team makes. The meeting minutes should be stored in a single wiki page, and have this format:

Development Practices

Practices to improve the quality, flexibility and usefulness of your code.

Layered architecture

You are expected to implement an architecture that was presented in-class, one of: MVVM, MVI or Clean. Note that MVC is not sufficient for full marks! See the instructor if this is unclear.

Pair programming

Team members will collaborate on difficult design and implementation issues. This will be discussed in-class; see slides.

TDD & testing

You must practice Test-Driven Development, and write comprehensive unit tests to follow your source code. You should be producing unit tests at each phase of your project (do NOT attempt to write them all at the end). This will be discussed in-class; see slides.

Code comments

When writing code, you should add strategic code comments to explain the purpose of your code (not "what it does", but "why is it done this way"). This does not need to be exhaustive, but it's a good practice for complex and/or critical code.

Git & feature branches

You are expected to regularly commit your code to git. It's a good practice to write your code incrementally: 1. Write a unit test for the code you are going to write. This helps define your interfaces. 2. Write code to achieve what you wanted, which also makes your test pass. 3. Add more tests to cover a reasonable number of inputs. 4. Commit to git! 5. Iterate.

For large features, you should be using Git feature branches and merging code back to main after each feature is complete.

Your Git commit history should reflect the work that you did during the sprint, and a TA should easily be able to see what commit belongs to which issue. A good practice is to put your issue number in the commit message to make it easy to find later!

Journalling

Each person on the team also needs to maintain a `development journal`: a wiki page with entries describing what you did in each sprint.

• You should have one section per week e.g., Week 10.
• There should be entries for every time you work on the project. I would expect multiple entries per week.
• Entries should include a date, and a brief description of what you worked on.