Skip to content

Latest commit

 

History

History
29 lines (16 loc) · 5.26 KB

workhabits.md

File metadata and controls

29 lines (16 loc) · 5.26 KB

Work habits, workflow and code quality

Work habits

The group started this iteration with a meeting to map out what needed to be done to fit the requirements, as well as our own motivation and goals. Started mapping out new possible features to add, and figuring out a way to set up a REST server. We set up initial issues following this meeting, and started working.

We have also had "daily" meetings when we met, compliant of the ones used in SCRUM. Everybody shared what they have done, what they plan on doing next, and if anybody needed help to solve their issues. We did some pair-programming, allthough usually only if some of us were struggling to complete their issue. This was done either digitally using screensharing or Live Share, or in person.

Workflow using Git

Efficient use of Git is crucial in developing in a team. The group has done all work through creating issues and branching from their respective issue. Each issue got a descreption, attached tags, and assigned to a member. We started using conventional commits in this issue, further clarifying what had been done in a commit-message. Conventional commits were written using VS Code extensions. Read more about conventional commits here

After an issue was resolved, a merge request was made. The merge-request had to be approved and looked over by another groupmember to assure code-quality and that the build would be stable.

Code quality

Tests were written for every new feature, to ensure better reliablity when changing or writing new code. Unittest were written using JUnit, and end-to-end tests using TestFX. We used Jacoco to check the code coverage. Our final code-coverage is at 92% for both rest and core module, and 74% for fxui module. The fxui tests are testing the core logic, and not code related to navigating between pages. If we figured a way of testing this, the coverage would be higher. Nonetheless, the fxui tests are testing the important core logic.

Spotbugs were used to find potential bugs, or poor code. Fixes were issued after finding them using this tool. Checkstyle was also used to improve code quality. Currently, checkstyle shows a lot of errors. None of the errors are major, mostly consisting of incorrect indentations etc.

Reason for late submission

We had to get a later deadline for the third release of the project. The main reason being that the amount of work on 3 people was alot. We are only 3 people in the group so tasks took a while since there was more work per person than in a group with 4 people. Especially making the project shippable proved to be quite hard and time consuming since we did not have any module-info.java files. There was also internal problems in the group that had to be dealt with. We belive the extended deadline would help us with showing our work and knowledge in a fair way.