Weekly Journal : OOGASalad Project Analysis

Mindfulness in the essence of engagement, [without it we are] frequently in error, but rarely in doubt. — Ellen Langer

This analysis is your opportunity to demonstrate your own thinking and knowledge of design concepts represented (or not) in the project's code. The course staff can readily identify the good and bad aspects of project's design, so we are looking to see if you can also acknowledge these as well. The goal of this retrospective is to draw meaningful conclusions to help you learn from your past successes and failures.

Submitting Your Work

Individually, complete the following on the master branch of your portfolio_NETID repository:

• oogasalad folder:
  • Example Game: submit your example game and a 1-2 minute video of it running that shows off something interesting about your project
  • Code Masterpiece: Java file(s), totaling approximately 200-400 lines, that demonstrate well designed code you primarily wrote during the project
• top-level:
  • a Markdown file, named week17_oogasalad_analysis.md, with your reflection on the project's design based on the questions below

Specifications

Example Game

Create your own "interesting" game variation and copy its associated data file(s) (no Java files should be changed) to your individual portfolio_NETID repository. Ideally, you will be able to use your project's Authoring Environment to generate the data files rather than editing them directly. The data file(s) do not need to represent a complete or fun/sensical game, but could just highlight something specific.

Record a 1-2 minute video of playing your game (the video can cover any part of the game, not just beginning) and provide a voice over on the video to describe what is happening in the code from a design perspective. The easiest way to make a video of your running project is to start a Zoom call, share your screen, start recording, and talk over your demo. There are also many free screen capture tools available or free trials of commercial tools.

Submit both the video and data files.

Code Masterpiece

Choose class(es) you primarily wrote that you feel demonstrate good design for us to review in detail.

The code should represent a component within your larger project that is small enough to be separable, but functionally significant enough to have some interesting design element. The term "component" is used rather than "class" because it may be several classes that work together, e.g., a few classes that work together or a superclass and its sub-classes. Note, if your component is specifically intended to be superclass, it must include enough detail that it is clear how to extend it and at least one example subclass to how it supports an abstraction.

• Every line of code in the class(es) you submit will be judged, you cannot specify parts of a class to ignore or include large sections of commented out code
• Every public method must be commented using Javadoc and every non-public method must include an inline comment briefly describing its purpose as well (like my example code)
• In comments included at the top of each submitted class,
  • describe this code's purpose and why you think it is well designed (i.e., what you think it shows what you have learned from the course)
  • include links to specific GIT commits where this code was refactored and tested during the project (i.e., to show the iterative nature of your GIT process when developing code)

Copy only the Java code files you want reviewed from your project to your individual portfolio_NETID repository without renaming them so we can easily compare them to previous versions (you do not have to include other files they depend on as we will not be compiling these versions, just commenting on them).

Your refactored masterpiece code must total between approximately 200-400 lines, including comments.

Design Review

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 agree with the team or 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).

• Overall Design. Reflect on the entire project by reviewing all the code, especially parts you did not write:
  • Describe the overall design of the program(s) in your own words, without referring to specific data structures or actual code (focus on how the APIs/classes relate to each other through behavior (methods) rather than their state (instance variables)).
  • Describe how the five SOLID Design Principles and the four pillars of Object-Oriented design are displayed in the project's design based on the following change scenarios:
    • What is needed to add a new game variation (such as new code, resources, data, or asset files)?
    • Which classes would be affected by changing the format of the data files that determine the game variations (say from JSON to XML)?
    • How would you add a new view to the Player (say the games played most often, game high scores, or details about when each game was played)?
    • How would you add an Extension Feature of your choice that your team was not able implement?
  • Review two design decisions discussed by the team — one significant change (i.e., those that affected many on the team) and one implementation change (i.e., those that could be hidden behind abstractions):
    • What alternate designs were considered?
    • What are the trade-offs of all the design options (describe the pros and cons of the different designs)?
    • Which did you prefer and why (it does not have to be one that is currently implemented)?
    • Why are you satisfied or not with the final solution (i.e., in hindsight do you wish it could have been done differently due to how it made coding more difficult, based on the course readings, etc.)?
  • Review two APIs (one or more class's public methods), with specific examples supporting your views — one that you feel was fairly stable and one that you feel changed or emerged during the project:
    • What service does this API provide?
    • What makes this API easy to use and hard to misuse?
    • What implementation detail does this API hide and how does it support extension?
  • Review two features a teammate implemented in detail — one that you feel is well designed and one whose design could be improved:
    • Describe the code's design for each in detail (what implementation details are encapsulated? what assumptions are made? etc.)
    • Evaluate the design of each (justifying why you feel it is good or explaining how you would improve it)
• Your Design. Reflect on the coding details of your part of the project:
  
• Describe one assumption or choice made about the assignment specifications or the code that had a global or significant impact on your design
• Describe two design challenges you wrestled with:
  • What are the trade-offs of the design choice?
  • What alternate designs did you consider?
  • How did you eventually handle it?
  • Why are you satisfied or not with the final solution?
• Describe one Design Pattern in the project's design (that you implemented, extended, simply used, or wished to have implemented)
  • Describe the specific design problem it changed your perspective on or solved
  • Describe the specific classes and methods that implement it
  • Describe how it helped (or would have helped) your design
• Review one API you designed or helped significantly with the implementation, with specific examples supporting your views:
  • What service does this API provide?
  • What makes this API easy to use and hard to misuse?
  • What implementation detail does this API hide and how does it support extension?
• Describe two features you implemented in detail — one that you feel is well designed and one whose design could be improved:
  • Describe the code's design for each in detail (what implementation details are encapsulated? what assumptions are made? etc.)
  • Evaluate the design of each (justifying why you feel it is good or explaining how you would improve it)
• Conclusions. Reflect on how your perspective and practice has changed during the semester:
  
  • What are two specific things you have done to improve as a coder/designer?
  • What are two specific things you have done to improve your teamwork or to be a better teammate?
  • What are two specific things you have done to improve how you manage "large", ambiguous, open ended projects?
  • What are your two biggest strengths as a coder/designer?
  • What is your favorite or most satisfying part of working on "large" team software projects (it may or may not be the actual coding)?

Your analysis must cite specific code examples from the project and citations from the course readings.