Project Review of Maliha Bhuiyan
General
G1: How creative is the project? (0: I've seen this on Youtube, 1: not creative 2: average, 3: creative, 4: very creative, 5: wow!)
- Answer: 3
- Justification: When I first read about the idea of the project it looked familiar to me, but I was surprised (in a positive way) when I saw the implementation of the project because it was not as I expected it to be.
G2: How difficult was it to implement the project? (0: no challenge, 1: very easy, 2: easy, 3: fair, 4: complex, 5: insane)
- Answer: 4
- Justification: The structure of the project is very complex, with a high number of classes to handle.
G3: List 3 positive aspects of the project. Motivate your selection.
- The complicated structure of the project has been handled very well.
- The feature of manipulating nutritional information looks interesting.
- Abstract classes have been used in an organised way, most of the classes derive from abstract classes.
G4: List 3 negative aspects of the project. Motivate your selection.
- Too many classes have been used to handle ingredients, nutrients, and recipes that may be confusing. The structure could have been simpler with the use of designer patterns (e.g. decorator pattern).
Programming techniques
PT1: Evaluate how well 5 programming techniques we learned throughout the course were adopted in the project. Assign a mark from 0 to 5 to each technique, where 0 means completely incorrect usage and 5 means perfect usage.
- <:Exception handling>
- Answer: 5
- Justification: Exception handling has been appropriately used, and it has not been missed anywhere needed.
- <.Method overriding>
- Answer: 4
- Justification: the overriding methods have been implemented correctly.
- <.Interfaces>
- Answer: 5
- Justification: The two interfaces (IDosable and IRanking) have been structured very well. In addition, as all abstract and static methods in an interface are implicitly public, they correctly omitted the public modifier.
- <.Generics>
- Answer: 5
- Justification: a good use of generics have been made as they ensure an appropriate handling of object types.
- <.Abstract Classes>
- Answer: 5
- Justification: most of the abstract classes implement correctly the two interfaces. In my opinion this classes have an important role in the project, as most of the classes extend this abstract classes.
Git repository
GR 1: How appropriate is the .gitignore file of the project? (0: missing, 1: very bad, 2: bad 3: average, 4: good, 5: very good)
- Answer: 5
- Justification: it is appropriately written
GR 2: How appropriate is the README.md file of the project? (0: missing, 1: very bad, 2: bad 3: average, 4: good, 5: very good)
- Answer: 3
- Justification: It should have contained an explanation on how to use and run the project.
Maven
M1: Can you compile the project via Maven? (0: no, 1: yes, but..., 2: yes)
- Answer: 1
- Justification: at the beginning I had some errors regarding an abstract class.
M2: Can you clean the project via Maven? (0: no, 1: yes, but..., 2: yes)
- Answer: 2
- Justification: it works fine
M3: Can you run the project via Maven? Check README.md on how to run the project. (0: no, 1: yes, but..., 2: yes)
- Answer: 2
- Justification:
M4: Are the project's dependencies appropriately configured in pom.xml? (0: no, 1: some, 2: yes)
- Answer: 2
- Justification:
M5: Are all Maven plugins appropriately configured in pom.xml? (0: no, 1: some, 2: yes)
- Answer: 2
- Justification:
M6: Does the project adopt Maven's standard directory layout? (0: no, 1: yes, but..., 2: yes)
- Answer: 2
- Justification:
Testing
T1: Are all tests passing? Run mvn test. (0: no, 1: yes, but..., 2: yes)
- Answer: 2
- Justification:
T2: How well do the tests cover the code? (0: no tests, 1: no important method, 2: some important methods, 3: most important methods, 4: all important methods, 5: 100% test coverage)
- Answer: 5
- Justification:
T3: Do the tests actually verify the expected behavior of the program? (0: no tests, 1: useless tests, 2: most don't, 3: some do, some don't, 4: most do, 5: awesome tests)
- Answer: 5
- Justification:
T4: How well can you understand what the tests are supposed to verify? (0: no tests, 1: what is going on?, 2: most are not understandable, 3: some are understandable, some aren't, 4: most are understandable, 5: all test are understandable)
- Answer: 4
- Justification:
Documentation
D1: How understandable is the Javadoc written for classes, fields and methods of the program? (0: no documentation, 1: very poor, 2: poor, 3: average, 4: good, 5: awesome)
- Answer: 4
- Justification: it is precise in every class
D2: How useful is the Javadoc written for classes, fields and methods of the program? (0: no documentation, 1: irrelevant, 2: little utility, 3: average, 4: useful, 5: very useful)
- Answer: 4
- Justification: it is useful to understand the functionalities of classes and methods, occasionally I found it difficult to understand the explanations.
D3: Can you generate documentation files for this project? Run mvn javadoc:javadoc. (0: no, 1: yes, but..., 2: yes)
- Answer: 2
- Justification:
D4: How adequate are the non-javadoc comments written throughout the code? (0: mostly inadequate, 1: average, 2: mostly adequate, 3: awesome)
- Answer: 2
- Justification: comments give appropriate explanations on the intent of the code, but a few comments indicate the obvious
Code quality
Q1: Is the code style adopted throughout the project consistent? Consider how whitespace is represented (spaces or tabs), tab size, naming conventions for classes, methods and variables, indentation, braces usage, line width. See Google Java Style Guide as an example of code style guidelines. (0: no, 1: yes, but..., 2: yes)
- Answer: 2
- Justification:
Q2: How would you rate the project in terms of code duplication? (0: a lot of duplication, 1: some duplication, 2: barely any duplication, 3: no code duplication / only justifiable duplication)
- Answer: 3
- Justification:
Q3: How easy it is to understand how the program works by looking at the source code? (0: mostly hard to understand, 1: some fragments are hard to follow, 2: not hard, but not easy, 3: easy to understand)
- Answer: 1
- Justification:
Q4: Is any section of the program excessively inefficient? (0: mostly hard to understand, 1: some fragments are hard to follow, 2: not hard, but not easy, 3: easy to understand)
- Answer: 1
- Justification:
Q5: Does the program crash unexpectedly (e.g. by an uncaught exception)? (0: all the time, 1: rarely, 2: it happened once, 3: never)
- Answer: 3
- Justification: never crashed