Journal 6:

This journal covers the Process learning area with an emphasis on Requirements validation and the Construction learning area with an emphasis on Refactoring. Refer to the Journal Overview page for details on how to format and submit this journal.

Question 1: Reflecting on code review

In Journal 3, you identified best practices for code review from projects in the wild, with supplemental guidance provided in the solution. Now that you've had the opportunity to both author and review pull requests, you can reflect on the development of your practical skills and adherence to best practices. To do so:

• Link to the first PR that you authored for the project and describe what you considered before requesting a review from your team. Reflect on any changes to your process between your first PR and most recent PR. If there were no changes, describe what you would consider when creating your first PR at a new job where you want to make a good impression with your team.

• Link to one PR that you reviewed for the project and describe at least three aspects of the PR you focused on. If this was a PR at a company, do you feel you have an ethical responsibility to take code review as seriously as code you write? Why or why not?   

Question 2: Assessing quality attributes

In Journal 5, you identified three quality attributes for your C2 implementation.

• For one of these attributes, measure whether your implementation achieved the target value you specified. In particular, state your quality attribute, the procedure you used to measure it, your target value, and the actual value achieved by your implementation.

Question 3: Addressing technical debt in Agile

Technical debt arises from decisions that are made today at the cost of (what might be) better for tomorrow. A nice definition from Christian Nelson, VP of engineering at Carbon Five:

"Technical debt is when the implementation – the code – for a product becomes unnecessarily complex, inconsistent, or otherwise difficult to understand. While there is no perfect code, code that contains technical debt [moves] farther [away] from a good solution for the problem it solves. The more debt, the farther the code misses the target. Technical debt makes it harder to understand what the code does, which makes it harder to build upon, and ultimately results in poor productivity and defects in the product."

Based on this definition:

• Identify and describe tech debt that your project accumulated during C1.

One of the most common ways that teams address technical debt by refactoring the code. Refactoring involves making structural (behaviour-preserving) changes that makes code easier to evolve.

• Provide a detailed plan for how you will pay down the debt: will you have a dedicated "refactor all the code" work item  or will you make changes through refactorings when implementing new C2 behaviour. Justify your decision; is it consistent with the decision of the rest of your team. Regardless of your decision, it is best practice to commit refactors separately (since they are unlikely to introduce bugs). While it requires discipline to avoid mixing refactors with other code changes, it can pay off by keeping your work structured, simplifying code reviews, and maintaining a clean project history.