Peer Review - Boulder Beeman

[beemanbp03]

@jbrischke

Design/Code Review 1

​

Project: Ratings Anonymous

​

Developer: @jbrischke

​

Reviewer: Boulder Beeman

​	Item	Considerations	Comments/Suggestions
Reviewer comments and suggestions go here. Each item should have at least one "kudos" and two suggestions for improvement
Problem Statement	1. Accurately describes project purpose 2. Is professional and free of typos, slang, etc. 3. Fully explains the problem and the solution 4. Is understandable by the average person	1. The purpose of the project is very clear and what a great idea. I agree, many game review outlets are as bad a corporate media with their "spin" on their subject matter. 2. It is presented in a professional manner and I didn't notice any typos. 3. The problem and solution are both clearly explained in the problem statement. 4. I think the average gamer would understand this. If you are worried about a non-gamer understanding the purpose, try explaining how game review sites get paid by big game companies to review their games, so if they are honest about their EA Madden reviews, EA would NEVER allow anyone to review their Madden games, because each review would be horrible.
Design Documentation	1. Navigation/flow through the application is logical and easy to use. 2. The order in which values are displayed are logical and easy to understand/use 3. The order in which the form fields entered are logical and easy to understand/use 4. All data discussed/documented (problem statement, flow, db design, etc.) is represented on the screens	1. I would put your "technologies used" section at the bottom of the design document, kinda like how a video games has minimum/recommended specifications on the bottom of the game's page. 2. Your application flow is very in-depth and easy to follow good work on that. 4. You need to finish up your tasks section flesh out your Project Plan timeline.
Data model/Database	1. Everything on the screens and problem statement/flow is represented in the model 2. There is at least one 1-to-many relationship. 3. The model represents good database design	1. Everything you have talked about in the documents appears in your database design. I have a suggestion though, maybe include a RATING column in your REPORT table so that people can give the game a score out of 5 or 10 or whatever. Or a thumbs up/down even! 2. I don't see a one-to-many relationship in your database design. I'm assuming you are going to have users have many reports kind of relationship? 3. As far as I can tell, the database you have is designed well. Just need to include that one-to-many relationship in it.
Code	1. Proper Maven project structure is used 2. a .gitignore file for IntelliJ Java projects has been implemented 3. There is not any redundant or copy/paste code in the JSPs or classes 4. Classes are appropriately-sized (no monster classes) Property files are used appropriately: no hard-coded values 5. Logging statements are used rather than System.out.println and printStackTrace. 6. There are appropriate unit tests/code coverage.	N/A

[pawaitemadisoncollege]

@beemanbp03 Is this the complete review?

[beemanbp03]

@pawaitemadisoncollege @jbrischke Peer review has been completed

[pawaitemadisoncollege]

@jbrischke I thought you had some java code in this application - but it's not visible here?

[pawaitemadisoncollege]

@beemanbp03 This looks much better in terms of the review - thank you.

[jbrischke]

@pawaitemadisoncollege @beemanbp03 I just pushed my current stuff to GitHub. I forgot to do so last night ;(