Weekly Journal : Breakout Project Analysis

Follow effective action with quiet reflection. From the quiet reflection will come even more effective action. — Peter Drucker

Now that the project has been turned in, take a few hours to relax and reflect, then analyze your experience. It is important for you to review your past performance, analyzing its positive and negative aspects to maximize what you learn from this experience. The goal of this retrospective is to draw meaningful conclusions to help you learn from your past successes and failures. They are an integral part of a project because, if taken seriously, they can be an extremely productive method of improving your development practices.

Submitting Your Work

In the breakout_NETID repository provided for you in the course's Gitlab group, push the following (no other modifications to this project repository should be made):

• a Markdown file, named DESIGN.md, that describes the design intentions of your code (note, any part of this document can also be used within your analysis as appropriate)

In the portfolio_NETID repository provided for you in the course's Gitlab group, push the following:

• a Markdown file, named week03_breakout_analysis.md, with your reflection on the project's design

Specification

Explain your view of how your program is organized and why it was done that way. This is an opportunity to describe how you might fix a problem, conceptualize something you thought about but could not figure out how to implement, or present an alternate design if you did not have time to actually refactor the code after learning something new, or any other learning you want to tell us about that the code does not convey.

If you think something is good, justify your opinion. If you think something is bad, justify your opinion and suggest how to improve it. Use specific code examples and supporting reasons related to design principles discussed in class or in the readings rather than general terms like "clearly/obviously", "good/sucks", "elegant/ugly", or "like/hate".

Note, no design is perfect so including both pros and cons (i.e., its trade-offs) or alternate designs you considered is highly encouraged (often designs cannot be seen as better or worse than another, but rather as a specific set of trade-offs that prioritize different goals).

• Planning
  • Did you over- or underestimate the size of this project?
  • How did thinking about the entire project before coding help or hurt your efforts?
  • How can you plan better in the future?
• Project Management
  • How did you start this project (from basically nothing) and how were you able to make progress?
  • What parts did you do early, middle, or late and how did you choose or prioritize them?
  • How can you better manage (your part of) a project in the future?
• GIT
  • Do you feel you committed often enough that others could have reviewed, understood, and integrated your commits in a timely manner in a team setting? Why or why not?
  • Reviewing your commit messages, do you feel they accurately represent your project's "story"? Why or why not (provide specific examples)?
  • GIT Best Practices (just the first four). Describe two commits (one you are satisfied with and one that could be improved):
    • Identify this commit by its date and message and files changed.
    • What was the purpose(s) of this commit and what kind of coding did it reflect (i.e., new code, refactoring, debugging, etc.)?
    • Why did you choose to include the changes in this commit as you did?
    • What value did this commit have to the overall project?
    • What about this commit made it good (or could be improved to better follow a best practice)?
• Coding
  • Where is your code not DRY (i.e., where does duplication exist within your code)?
    Note, you can use IntelliJ to help you find code duplication within your project
    
  • How could your code do better Telling the Other Guy (i.e., empower a class to do something itself rather than doing it yourself in the "primary" class)?
    Note, you can use IntelliJ to help you analyze how data flows within your project so you can see where data can be better encapsulated
  • Clean Code: Describe two methods in detail (one you believe is readable and one that could be improved):
    • Describe this method's purpose
    • What makes this method easy (or hard) to read and understand (i.e., does a method do what one would expect, are there places where it requires comments to understand)?
    • Why do you feel this method does (or not) embody the Single Responsibility Principle?
    • How much did this method benefit (or not) from refactoring and how many "drafts" did it go through?
• Design
  • Where is your code not SHY (i.e., what dependencies exist between classes or methods)?
    Note, you can use IntelliJ to help you find the dependencies within your project
  • Describe two classes in detail (one you believe is well designed and one that could be improved):
    • Describe this class's design in detail:
      • What were your goals did you have (beyond simply making it work)?
      • What assumptions did you make (to make it easier, etc.) and did they affect any other parts of the program?
    • Did it make implementing any future project features easier or harder?
    • Did the design of this class change during the project?
    • Why are you happy with its design or, in hindsight wish it could have been done differently (e.g., due to how it made coding more difficult, based on the course readings, etc.)?
  • Trade-offs: Discuss two design issues you wrestled with beyond simply making the code work (one you are satisfied with and one that could be improved):
    • Describe the issue and the trade-offs you considered
    • What alternatives did you consider?
    • How did you eventually handle it?
    • Are you satisfied with the final solution? Why or why not?
• Conclusion
  
  • Which kinds of tasks (e.g., debugging, writing features, refactoring, learning new tools/frameworks, or even just thinking):
    • were easiest
    • were hardest
    • did you spend the most time on
  • What coding habits did this project make you want to change and/or convince you to keep?
  • How could you improve your overall coding process to make it more reliable, efficient, enjoyable, etc. in the future?