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 problem statement acurately describes the project. 2. "track stats for teams and players that are interested in" you are missing the subject "they". 3. It might be good to elaborate more on what is meant by "discover random stats when something piques their curiosity". 4. No issues here.
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. Design documentation is incomplete and does not show all screens. Additionally, the ScreenDesign page contains only a link to a file instead of displaying the screenshot in the ScreenDesign.md page/file itself. 2. Yes. 3. N/A 4. Screen are unfinished, so no.
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
No database model was in the repository. Although,
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.
1. Project uses proper Maven structure. 2. A git ignore file is used but the real database config with credentials has not been ignored. 3. No redundant code found. :-) 4. All good here. 5. No system.out's. However, some debug logging might produce unusable results when used in a real world scenario. For example: In getAllUsers() you attempt to output ALL OF THE USERS to the log. Imagine if you had a 100,000 users. 6. Units test appear good.
Design/Code Review 1
Project: nbaStatsFun
Developer: Kailyn Angelo
Reviewer: John Oliver
2. Is professional and free of typos, slang, etc.
3. Fully explains the problem and the solution
4. Is understandable by the average person
2. "track stats for teams and players that are interested in" you are missing the subject "they".
3. It might be good to elaborate more on what is meant by "discover random stats when something piques their curiosity".
4. No issues here.
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
2. Yes.
3. N/A
4. Screen are unfinished, so no.
2. There is at least one 1-to-many relationship.
3. The model represents good database design
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.
2. A git ignore file is used but the real database config with credentials has not been ignored.
3. No redundant code found. :-)
4. All good here.
5. No system.out's. However, some debug logging might produce unusable results when used in a real world scenario. For example: In getAllUsers() you attempt to output ALL OF THE USERS to the log. Imagine if you had a 100,000 users.
6. Units test appear good.