CompSci 307 Fall 2021 |
Software Design and Implementation |
In your OOLALA team, use today's lab time to focus only on the project's design rather than adding new features.
You will know your design is on the right track if your code:
Work on today's lab following these steps:
REFACTORING_DISCUSSION.md
file and add it to the repository in the doc
folderrefactoringLab
At the end of lab, use Gitlab's Merge Request to submit your team's updated code and doc/REFACTORING_DISCUSSION.md
file from its separate refactoringLab
branch to the team repository's master
branch. Make sure the Title of your Merge Request is of the form "lab_refactoring - participating NETIDs".
It is fine to accept this Merge Request after lab whenever your team is ready.
To help you choose where to most effectively refactor your code as your project and team size increase, we have created a tool that helps highlight basic design flaws to give places to start your refactoring. It is based on SonarQube, which combines a number of static code analysis tools to automatically generate issues by looking for certain features in your code (such as public
instance variables). Note, IntelliJ also does this with its yellow warning marks on the right edge of the editor window, but they tend be "lower level" than the ones SonarQube finds (although there will be ones that overlap).
It should be noted that static analysis in no way guarantees your code is well designed, it only helps find potential flaws and brings them to your attention. For example, it is clearly a design flaw to have public
instance variables, but you can still have a bad design even if all of your instance variables are private
. While you are not required to remove all issues found by this tool, you should be prepared to justify your decisions if significant issues are left in your code (e.g., with comments near the lines flagged as issues in any of the reports).
To begin discussing the code's design, review the top issues found in your code's most recent master
branch using the following steps and record the results in your discussion file:
Some issues may refer to the same piece of code (likely making that code a higher priority to refactor), some issues may have easy fixes, and some may require more thought or require more sweeping changes. For example, as we have discussed in class, sometimes removing duplicated code is as simple as creating a new method and sometimes it requires creating a new class or abstraction.
Note, the top issues on the Dashboard that are organized roughly in the following order:
For each of these kinds of issues, you can also see the complete list of issues in your project rather than just the top ones by selecting a specific file, colored and sized by how many issues it has, or by the category option at the bottom of the Dashboard (in its footer).
Not every team will have all of the issues above, but every team has at least one of issue. They represent only a minimal set of design goals for this project that every team should be able to reach before completing the project.
Now that your team has considered how to improve the project's design, choose small refactorings to move forward implementing actual changes to your code to move it towards that design in a controlled manner. Let IntelliJ help you as much as possible with its Refactor menu and keep on top of any syntax errors that are produced with each change so it remains manageable and does not spiral out of control. Commit your changes to this lab's separate GIT branch frequently in case you need to roll back something.
Checkstyle is another static analysis tool that focuses primarily on the code's formatting, rather than design issues, and you can find its report linked on your team's Gitlab repository page.
https://coursework.cs.duke.edu/compsci307_2021fall/oolala_teamNN/
As a reminder, many of them can be fixed simply by downloading and applying the course coding conventions. Note, you do not need to worry about the length of your lines (80 characters).
Once you have verified that the primary issues and the formatting issues are taken care of, you can use the rest of the time to clean up any other aspect of the project's design or to add more tests.