Peer review #1

[BryceAllard]

Design/Code Review 1

Project:

Developer:

Reviewer:

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	Good job introducing a new topic, this is something I've never heard of but I feel like I understand the goal and see the need for your app. I think it would be a bit clearer if you started with the organization name instead of the website and include the website later. Also, how does the team vs individual sport part work into the app? I'm not sure I understood how that part was relevant so maybe make that a little more clear.
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	Design documents look good. There are a lot of screens here but I think they all make sense. I assume there will be some kind of results/ history page showing how a team did in a race and how they've done over the years? The scope of this app seems pretty large but if you are comfortable with that, go for it!
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	Didn't notice much database related code, assuming that's coming and that's ok. Saw the user class is already implemented, that will be useful
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. 7. No sensitive information is visible in the repository (secrets, passwords, etc).	Structure looks good and saw the gitignore file. Looks like JSPs aren't implemented yet (mine aren't either) so you can add them when you have a chance. Didn't see any monster classes or System.out.printlns. Overall, great work! Excited to see how it turns out.

[pawaitemadisoncollege]

Hi @BryceAllard Thanks for your review and feedback of @JBostroem96 's project so far. You make some good points about clarifying some of the problem statement phrasing/ideas. It's so helpful to have somebody unfamiliar with a problem space reviewing!

Digging into this a bit, following are a few additional things I noticed - I thought it might be helpful for both of you:

• [ ] User class - does not need password as cognito will handle this. I'm not sure that birthdate is relevant but it's up to @JBostroem96 if he wants to include it.
• [ ] DAOs - some redundant code - time to implement the generic dao.
• [ ] I don't see a pom.xml here and wonder if it may be gitignored? I think that is a good one to have in GitHub as a backup.

I noticed a some printlns have snuck in. Github's search feature is handy for finding these: