Always at 23.59 on the same day as your TA session (Except Monday classes).
Consult the deadline for your class on the delivery plan.
The learning goals of this week are twofold: to analyze and refactor your current code base to clean up at least two methods so they adhere to Robert Martin's (and Henrik Bærbak's) properties of clean code; and to use the clean code template to ensure completeness of analysis as well as document it.
Choose two complex aspects (a complex method, or a feature coverede by a small set of methods) from your current HotCiv implementation and for each first analyze it in terms of the Clean Code template, and next refactor it so it adheres as best as possible to the Clean Code properties. (moveUnit() and city production/unit placement methods are probably obvious candidates for clean up).
Release your code base uing the tag/branch name "Release4".
Ensure that you have no items on your backlog before submitting this week. That is, all functional requirements on AlphaCiv, BetaCiv, GammaCiv, and DeltaCiv must now be fulfilled by your implementation!
Your submission is evaluated against the learning goals and adherence to the submission guidelines. The grading is explained in Grading Guidelines. The TAs will use the Iteration 4 Grade sheet to evaluate your submission. The score counts towards your final grade.
|Learning Goal||Assessment parameters|
|Submission||Git repository can be pulled. Git repository is not public! Code must compile; 'gradle test jacocoTestReport' must pass; required artefacts (report, screencasts, backlog) must all be present. The quality of screencast (video, audio) is OK.|
|Clean Code Analysis||The analysis of the choosen methods are correct, and the clean code templates are correctly filled for each property. Argumentation is concise and correct.|
|Refactoring||Refactoring is made to only clean up the properties mentioned. The screencast narration explains and refers to relevant clean code properties. All code changes are indeed refactoring changes (exact same behaviour before and after code changes). Test cases are run frequently to ensure small steps and no defects are introduced.|