Peer Review - from Carson Roedl

[Carson-Ray]

Design/Code Review 1

Project: Blog Project

Developer: David Calabrese

Reviewer: Carson Roedl

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	Very straight forward problem statement that really expresses the direction he would like to take the project in. Could make user stories a bit more involved to give a better idea of who is using the application, rather than just what they want.
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	There is not currently JSP files with the design, but from the code alone I can see a definite flow between the classes and test classes. The database model could be updated, and some of the files could be better contained to keep like files grouped together. Ohterwise, the figma markup gives a good idea of the overall product could look like.
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	Data model is very well thought out and comprehensive, covering almost all necessary columns needed. Options for tables look good, but the many to many with a bridging table looks like the best option. Could make changes to the test data being seeded in the database to possibly help with errors.
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.	Code looks very clean and well documented. Could clean up some of the methods that carried over from the exercise files, and once the properties loader is figured out I think the interface will be the way to go.

[pawaitemadisoncollege]

@Carson-Ray @davidtcalabrese An easy way to search for those sneaky print statements: https://github.com/mad-ent-java-s22/indie-project/search?q=print

[davidtcalabrese]

Thanks for the review Carson