Game : Analysis

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.

Submission

In addition to documenting your project (and noting the cheat keys you installed in your README), complete the following parts directly in your portfolio_NETID repository:

• Written analysis: complete the template file, already started for you, called 01_game/ANALYSIS.md. It must be completed using Gitlab's markdown format.
• Code masterpiece: copy one or more classes from your project repository to your portfolio repository. Your code must total no more than 250 lines, including comments.

Specifications

Your analysis document should be divided into two parts:

• project journal
• review of the project's design

Your analysis is your opportunity to demonstrate your knowledge of design concepts represented (or not) in the project's code. We 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. If it is also an honest and thoughtful reflection, it can also help you identify specific actions you can do to improve future projects.

The following sections must be included in your analysis. Questions are provided to get you started thinking about what to consider within each section; you may, of course, include anything else you feel is relevant. In other words, do not be limited by these questions, but respond to them at least.

Project Journal

This section represents your view of the project's planning and progress. Analyze your plan and how the project's outcome could be improved. Describe specific, important, events during the project's time line to justify your comments rather than general terms like "always late", "bad code", etc.

• Time Review
  Reflect on how you spent your time while working on this project.
  • Report how many hours you spent on the project as well as its start and finish dates (do not forget to include time spent planning and reading).
  • Describe how you spent your time (i.e., coding new features, refactoring, testing, reading, designing, debugging, documenting, or meeting with team members).
  • Describe how you personally managed your code (i.e., how often did you develop, test, commit, or push pieces)?
  • Reflect on what what tasks were easiest for you to do and what were hardest; what were good uses of your time and what were bad.
• Commits
  Reflect on how often you committed code as well as the size and purpose of your commits.
  • Report how many times you committed code and the average size of those commits.
  • Look back over your commit messages, do you feel they accurately represent your project's "story"?
  • Describe two of your commits (identified by their message) in detail:
    • what was the purpose of your commit (i.e., new feature, refactoring, debugging, etc.)?
    • why did you choose to package these changes as a commit?
    • is this commit's size reasonable for someone else to review before allowing it into the repository?
• Conclusions
  Reflect on how effectively you worked on the project.
  • Did you over- or underestimate the size of this project? How can you estimate better in the future?
  • Which parts of your code required the most editing? why?
  • To be a better designer, what should you start doing, keep doing, or stop doing?
  • If you could work on one part right now to improve any aspect of your project, what would it be?

Design Review

This section represents your view of how your program is organized and why it was done that way. It can be a chance for you to describe how you might fix a problem or refactor the design if you did not have time to actually change the code.

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 reasons related to principles discussed in class or in the readings rather than general terms like "clearly/obviously", "good/sucks", "elegant/ugly", or "like/hate". Note, since no design is perfect, including both pros and cons of a design (i.e., its trade-offs) or alternate designs you considered is highly encouraged.

• Status
  Reflect on the coding details of the project by reviewing the code.
  • Is the code generally consistent in its layout, naming conventions and descriptiveness, and style?
  • Is the code generally readable (i.e., does it do what you expect, does it require comments to understand)?
  • Are the dependencies in the code clear and easy to find or do they exist through "back channels" (e.g., global variables, order of method call, or get methods instead of parameters)?
  • Describe two pieces of code in detail:
    • Describe the purpose of this code in the overall project.
    • What makes this code easy (or hard) to read and understand?
• Design
  Reflect on how the program is currently organized.
  
  • Describe the overall design of the program, without referring to specific data structures or actual code.
  • As briefly as possible, describe how to add a new level to the game.
  • Justify why your overall code is designed the way it is or what issues you wrestled with if you think its design is lacking in some way. Are there any assumptions or dependencies in your code that impact the overall design of the program?
  • Describe two features from the assignment specification in detail:
    • What classes or resources are required to implement this feature?
    • Describe the design of this feature in detail (what implementation details are encapsulated? what assumptions are made? do they limit its flexibility?).
• Alternate Designs
  Reflect on alternate designs for the project based on your analysis of the current design.
  • Describe two design decisions you made, or wish you had done differently, in detail:
    • What alternate designs were considered?
    • What are the trade-offs of the design choice (describe the pros and cons of the different designs)?
    • Which would you prefer and why (it does not have to be the one that is currently implemented)?
  • What are the three most important bugs that remain in the project's design or implementation?

Your analysis must be completed using Gitlab's markdown format and must be named 01_game/ANALYSIS.md.

Code Masterpiece

Take part of the project and refactor it to demonstrate what you now think of as good design. It should represent a feature or component within your larger project that is small enough to be separable, but functionally significant enough to have some interesting design element. I use the term "component", 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 show your design in "action".

In comments at the top of each class included, describe this code's purpose and why you think it is well designed (i.e., what you think it shows that you have learned so far in the course). Every line of code in the class(es) you submit will be reviewed, you cannot specify only part of a class to review or include large sections of commented out code. Simply copy only the Java code files you want us to grade from your project to your portfolio without renaming them so we can easily compare them to previous versions (you do not have to worry about other files they depend on).

Your masterpiece code must total between approximately 100-250 lines, including comments.