Peer Code Review

In today's exercise, with a partner from your SLogo team, take some time to review how your APIs have changed during the course of the project. If you have time after that, work on finding and fixing design issues in your code.

API Changes

At the beginning of this project your team defined four APIs: an external and internal set of public methods for each "side" of the project. For most of you this was your first time specifically designing an API and you did not know a lot about the project you were building. Since then you have also learned new Java techniques that you may have incorporated into your design.

Start by reviewing your original API designs (in your DESIGN.md file and the interfaces you created to express that design) as well as your current API (represented here as your project's public methods). When looking at the current version of your API you may decide that some methods do not actually need to be public or that a new interface or class would be useful to more clearly separate part of an internal from an external API — it is fine to change them within your code now. To help you clarify the design goals of your APIs, you may want to spend some time describing your internal APIs to each other (e.g., how to add a new command to the backend or a new view component to the front end).

Recall that one of the requirements for this project is that your team complete a document, called API_CHANGES.md, that describes how your APIs have evolved over the course of the project. This exercise is intended to help you determine the content of that document. Thus, as a team, your goal is to determine:

• what changes that have been made to the APIs
• if those changes are major or minor (justify your distinction based on how much they affected your team mate's code)
• if those changes are for better or worse (if for the worse, is there a way to improve it or was the original API overly optimistic)
• if your foresee any significant changes coming in the next few days as you finish the project (based on your experience and the fact that you now know all the features to be implemented)

Record the results of your discussion in your team's API_CHANGES.md file on your master branch. You are welcome to include any additional supporting documents you feel are useful as well.

Refactoring

If you have additional time, create a branch in your team's repository called refactored_NETIDs, where NETIDs is your pair's Duke NetIDs. As a pair, refactor some code smells and describe your decision making process in a separate file using Gitlab's markdown format.

If you do not already have a piece of code in mind, use static analysis tools like CheckStyle or the results of a simple script to check some basic features of your code to locate problem code in your project.

With your partner, agree on at least one section of code to refactor (it does not necessarily have to be code you wrote). In your discussion file, describe why you choose this section of code to refactor.

Submission

At the end of class, push your group's refactored code and your discussion files to your team's repository. Make sure both people's NetIDs are in the title of your branch and that both people's names are in the discussion file.