7 —
Due Thursday, 12 November 2020, 11:59:59pm Friday, 13 November 2020, 05:30pm
Delivery Place the product of this week’s project steps into your repo in a repo-level directory named 7, formatted as specified below:
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.
Successfully completing your self eval is a prerequisite for receiving any of this assignment’s points.
Tasks Welcome to a new partner and possibly a new code base.
Like all software projects, your code base has accumulated a significant technical debt, partly due to conflicting understanding between your "customer" and you, partly 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 1.
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 `board` structure;
... other related bullets elided ...
[ ] delete inconsistent and superfluous purpose statement,
create unit tests for `int get_number_of_fish_from(Tile t)`
... other related bullets elided ...
[ ] inspect the failing integration test from `5/houston/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 of integration) test that points to a bug: Describe the bug in one line and the fix on a second one. (More 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 `place_penguin` function failed to check for boles in the board
failing unit test prior to fix: ... github.ccs.neu.edu ...
fix: ... github.ccs.neu.edu URL to commit ...
the `deserialize` function for boards did not fill rows with holes at the
end of "short" specifications
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 Game Tree representation
we defined Trees as `(node state-info [Hashof Action [-> Tree]])`
... github.ccs.neu.edu URL to commit ...
board: missing data interpretation for Board
we added an ASCII diagram to the `board.py` file and explained how
tiles in this diagram map to fields in our array
... 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.