7 —
Due Wednesday, 10 November 2021, 11:59:59pm
Delivery Place the product of this milestone into a repo-level directory named 7:
bugs.md, the list of fixed correctness bugs exposed by any failing test;
reworked.md, the list of reworked code pieces; and
todo.md, a todo list of still outstanding items that would improve the code base.
Clean-up Tasks
Like all software projects, your code base has accumulated a significant technical debt, partly due to the usual kinds of disagreement between your "customer" and you, mostly due to the usual deadline stress.
Your team manager has decided that the project needs to reduce this debt now, mostly because you have a new partner. This will give you a chance to work through design rationales, document all critical and difficult to decipher code snippets, and assess the qualities of the code base in general.
Step 1 Compile the feedback you have gotten for the past six
milestones: failing integration tests, missing unit tests, demands for
improved data definitions, and so on. If you have items of your
own—
Group this list of potential todo items around (1) data representation and (2) functionality per data representation. Summarize the items appropriately. Simply submitting all of your feedback in raw form is inappropriate.
Each summary is a todo item. Format the list as shown in figure 4.
Order these todo items by priority, from highest at the top to lowest at the bottom, and place the list in todo.md.
As you work through issues, mark the finished items with an "X" between the two brackets.
[ ] need a data definition and interpretation for the `map` structure;
... other related bullets elided ...
[ ] delete inconsistent and superfluous purpose statement,
create unit tests for `int get_segment_number_from(Connection c)`
... other related bullets elided ...
[ ] inspect the failing integration test from `5/yellowstone/Tests/1-in.json`
... other related bullets elided ...
Step 2 Create bugs.md and reworked.md.
Step 3 As you work through this todo list, document the changes in the one of the two files as appropriate:
bugs.md—
For each failing (unit or integration) test that points to a bug: Describe the bug in one line and the fix on a second one. (Use more lines only if absolutely needed.) Then point to (1) the git commit with the unit test that made the bug repeatable (see —
Debugging) and (2) the git commit of the bug fix itself.
the `acquire_conn` function failed to check whether it exists on the map
failing unit test prior to fix: ... github.ccs.neu.edu ...
fix: ... github.ccs.neu.edu URL to commit ...
the `deserialize` function for map did not remember the visualization hints
for cities
failing integeration test prior to fix: ... github.ccs.neu.edu ...
fix: ... github.ccs.neu.edu URL to commit ...
reworked.md—
For each fixed item of code-inspection feedback on a prior milestone, quote the feedback, explain your approach to remove the deficiency, and point to URLs of git commits that fix the problem.
missing data definition for the Action representation
we defined Acquisition as ...
... github.ccs.neu.edu URL to commit ...
map: missing data interpretation for the Map data representation
we added an ASCII diagram to the `map.py` file and explained how
connections in this diagram map to data representations
... github.ccs.neu.edu URL to commit ...
Learn You will want to learn how to squash git commits for this exercise. Google "interactive git commit" or "squashing git commits". While squashing isn’t strictly needed, anyone who reads git commits for design, rework, and bug-fix information will prefer to have all changes on a single page. You might as well figure out squashing now.