# SE475 Design Journal - Week 4
## 10/1
I spent some time putting together a guidline for our team in order to make the process more consistent for all members. Many details that I haven't thought through when making the plan, such as documenting our code (including the header specifying who writes this file), a more detailed naming convention for all our test classes, how the pull request and code review process should look like. I wasn't sure how other team members felt about these guidelines though because no one said anything. But at least it's something that I would always want to have when working as a team.

## 10/3-10/4
From a feedback of a team member, I realised that I had used a wrong setup for our test project in the solution. I spent some time figuring out how to fix it. The error seemed to be NuGet related, but I am not exactly familiar with the package manager. And since it built successfully on my computer, I couldn't recreate the error to debug it. Eventually, I switched the whole setup to the one that team member used and that somehow solved the problem.

One thing that I felt a bit frustrated about was that, I posted this project setup a week ago and asked all team member to experiment with it, but apparently no one really did test it. We would have solved that problem earlier before everyone started the actual implementation. But I guess that's the hard part of doing a team project. You can't really expect people to approach things your way without some effective planning and management.

## 10/5
I kind of waited for other team members to start implementing, make sure that the project environment worked, before I started mine. It was already the day that I originally set as the deadline for finishing the code and creating pull request. Given the time left, I didn't really test my method thoroughly. Some code pathes of my mthod were really tricky to reach. While reading the code, I felt that this program is not particularly a very testable code. Too many methods are highly coupled and you can't test one without the other. A lot of the methods are accessing class attributes directly, which is quite confusing when reading the code and requires a lot of stub variables in the unit tests. I think this is a good lesson to learn that, when writing code, we should always thrive to make it easily testable.

## 10/6
This was the designated code review and merge day based on our schedule. All members in our team successully pushed their code to repo and created pull requests. I had a lot of fun reviewing other people's code. Just by reading their code, you notice how people approach a problem, which is a very good opportunity to learn and progress my skill.

I have used other similar code review tool before, so there was nothing that I need to learn from scratch per se. I did have to get used to how everything works on GitHub. Also, when reviewing, I noticed that we didn't really discuss the criterias in terms of what needs to be revised and what not. Perhaps it will be better to have an agreed code style manual or something. We also didn't plan out our test in a very detailed way, so I ended up approving everything as long as it compiles and passes.