Design/Code Review 1

[OscarJohnson6]

Design/Code Review 1

Project: Nudge Writing App

Developer: Jordan Gruel

Reviewer: Oscar Johnson

Item	Considerations	Comments/Suggestions
Problem Statement	Accurately describes project purpose Is professional and free of typos, slang, etc. Fully explains the problem and the solution Is understandable by the average person	Your problem statement and reasoning for the application make a lot of sense its also a really interesting app. It looks professional and I think does well to improve from the design in Write or Die. One suggestion is to specify if you would be changing or doing something different from the features in Write or Die. Another would be to include a description on what each feature does like danger or savior mode.
Design Documentation	Navigation/flow through the application is logical and easy to use The order in which values are displayed are logical and easy to understand/use The order in which the form fields entered are logical and easy to understand/use All data discussed/documented (problem statement, flow, db design, etc.) is represented on the screens	I really like the screen designs you made, they all flow nicely, and make sense. I also like the color themes used it also helps with making it easy to follow. These are really small suggestions but you could change birthdate to be a calendar type input. On the sign in page the create account button could say go to create an account, as it might be mistaken for actually creating account.
Data model/Database	Everything on the screens and problem statement/flow is represented in the model There is at least one 1-to-many relationship The model represents good database design	The database design set up makes sense and has 1-to-many with saving user accounts and their many writings. Some suggestions/ideas for tables since we talked about it. For storing in the session table you could have it auto save when the time goal runs out, the other table could be user saved/finished works so they can easily go back to it. Otherwise you could have a table for saving a users preferred writing settings.
Code	Proper Maven project structure is used a .gitignore file for IntelliJ Java projects has been implemented There is not any redundant or copy/paste code in the JSPs or classes Classes are appropriately-sized (no monster classes) Property files are used appropriately: no hard-coded values Logging statements are used rather than System.out.println and printStackTrace There are appropriate unit tests/code coverage No sensitive information is visible in the repository (secrets, passwords, etc.)	You have a maven structure, a gitignore file, class size are appropriate/make sense, properties files and logging are being used, and you have majority/all of the unit tests that are needed. One suggestion is to remove the resource properties files from GitHub, I noticed because I have to do the same. Another is to include the html tag at the top of your head.jsp so you won't need it in other jsp's.

[pawaitemadisoncollege]

Hi @OscarJohnson6 - thanks for sharing your review of @potatoesnmolasses project so far. Your comments show you took time to dig into the project and were thoughtful about what is on target and what could be improved.

Regarding your comment about the html tag - I think it is a best practice to open and close tags in the same jsp to avoid the possibility of unclosed tags. I suppose if we know the head tag will always be used, this might be ok, but it's something to consider.

I did a quick search in GitHub for "Print" and found a few that snuck in: