Peer Review 2 (Live Odds)

[wgeorgeson]

@amoose20

Design/Code Review 2

​

Project: Live Odds

​

Developer: Austin M.

​

Reviewer: Bill Georgeson

​	Areas for Improvement	Criteria	Items Met or Exceeded
Project effectively utililizes the technologies and technques specified in the project objectives
Planned MVP Functionality	Yes
Logging framework used, i.e., no System.out.println() or printStacktrace() statements.	Yes
Hibernate used for all data access.	Yes
Authentication implemented.	Yes
Consumes at least one web service or public api using Java.	Yes
More CRUD capabilities through the application	Application is database-driven using full CRUD.	The DAOs have CRUD capabilities, but I didn’t notice full CRUD through the app
Database includes multiple one to many relationships.	No
Deployed to AWS for public access.	Yes
No evidence of data validation	Implements best practices (for example, data validation)	No
Synthesis of multiple concepts in unfamiliar situations requiring research beyond the scope of the class
Experiments individually, exhibits independence and drive, shows originality in the solution.	Yes
Implemented technologies or techniques not covered in course materials.	None that I noticed
Code quality - Evaluate code quality for the following and identify specific areas for improvement (class, method or line number). Be sure to list which code quality plugins/tools you used to assist with this analysis
Single-purpose methods	Yes
Well-structured project	Yes
Descriptive naming of packages, classes, methods, variables	Yes
Classes appropriately-sized (no monster classes)	Yes
CPD (copy paste detection, meaning are the same lines of code repeated?	Maybe a little
Are there candidates for super/subclass relationships, abstract classes, interfaces	No	are any values hard-coded that should be in a properties file?	No
Proper exception handling	Yes
Proper error reporting to the user - custom erro pages?	Yes
Code documentation	Yes
Is there code in the servlet doGet/doPost that should be refactored into testable classes or methods?	No
Evaluate the JSPs for templating, data validation, overall look and feel.	Templating - Yes
JSPs use JSTL and EL, no java code	Yes
Unit tests are truly a unit test rather than a high level functional test	Yes
Test data is appropriately cleaned up or handled	Yes
There is full coverage of methods that perform business logic or utility functions	Yes
Redundant code is eliminated by using set up and tear down methods, i.e., @Before, @After	Yes
Other comments/notes?
Demonstrates initiative and thoughtful planning to leverage available resources (time, equipment, external expertise) to meet milestones and project objectives.	Yes
Evidence of significant revision and incorporation of feedback.	Not sure
Project complexity	Not a lot of complexity, but that was part of the app’s purpose. There’s enough to meet the requirements of the project (mostly)
Aside from adding additional CRUD functionality more styling, its functioning properly as a Java Web app. Nice job Austin!	Additional Comments

[pawaitemadisoncollege]

Hi @wgeorgeson. I appreciate that you saw this review through to completion. Feedback like this could be improved by including detail about how an item is met and what could be improved.

A few examples:

1. Best practices of using properties rather hard-coded values: https://github.com/amoose20/indieProject/blob/5526976bcb4c8b2cbd360ea9853b18e5a72816db/src/main/java/com/liveodds/persistence/OddsApiDao.java#L17

2. There's duplicate code in the Daos - TeamDao and UserDao - better to use the GenericDao to eliminate this duplication.

3. Regarding revision and improvement of the product - here one might examine the open issues and check to see if feedback was implemented, such as this one: https://github.com/amoose20/indieProject/issues/3

No need to go back and make changes here at this point, but I hope this will help you improve in future code reviews.