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: Task Tracking is not a new idea, but their implementation (e.g. "Study mode") deserves extra credit.
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: Even though the logic is not very complex, the use of Spring and an SQL database added challenges to the project.
G3: List 3 positive aspects of the project. Motivate your selection.
1. The usage of the UI is very intuitive.
2. The presentation of the project, both in the README.md file and in the video, was very effective.
3. The project is very well structured and easy to understand.
G4: List 3 negative aspects of the project. Motivate your selection.
1. Incoherent color theme. For example, the "Study mode" has a totally different design, then the rest of the UI.
2. User input is not controlled properly, for example selecting the end time before the start time, simply does not create a task, and does not throw an error.
3. "Study mode" is hardcoded for a 1080p FullHD screen, therefore on other resolutions it doesn't fit the screen correctly.
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.
1. Abstract classes
Answer:5
Justification: The abstract class Task is used in the apropriate manner, since it serves as the parent class for the other tasks and has already Implemented methods.
2. Collections
Answer:5
Justification: They use many ArrayLists and Sets in the proper intended way.
3. Custom Exceptions
Answer:5
Justification: Well implemented and used in the GlobalExceptionHandler. However, Spring handles exceptions differently then vanilla Java.
4. Streams
Answer:5
Justification: They used streams to sort and filter Arraylists, to make the code more readable and efficient.
5. Method overriding.
Answer:5
Justification: Used correctly for example to configure the security of the application.
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: The .gitignore contains all the most important files.
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:5
Justification: The README.md includes all the information requested for the delivery of the project. The included video explains the use of the application very well.
Maven
M1: Can you compile the project via Maven? (0: no, 1: yes, but..., 2: yes)
Answer:2
Justification: It compiles successfully, even if the command is not mentioned in the README.md.
M2: Can you clean the project via Maven? (0: no, 1: yes, but..., 2: yes)
Answer:2
Justification: It cleans successfully, even if the command is not mentioned in the README.md.
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: It can be run successfully using, by using the jar command specified in the README.md
M4: Are the project's dependencies appropriately configured in pom.xml? (0: no, 1: some, 2: yes)
Answer:2
Justification: All dependencies are appropriately configured.
M5: Are all Maven plugins appropriately configured in pom.xml? (0: no, 1: some, 2: yes)
Answer:2
Justification: All maven plugins are appropriately configured.
Justification: The project structure follows the guidelines.
Testing
T1: Are all tests passing? Run mvn test. (0: no, 1: yes, but..., 2: yes)
Answer:2
Justification: All tests run correctly.
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:2
Justification: Only the 4 repository classes are covered, but some important checks are missing, for example if the data for a task creation is correct (e.g. past date or end time before start time).
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:3
Justification: Mostly only happy paths are tested.
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:5
Justification: The names and comments of the tests explain well what the tests should check.
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:3
Justification: Some methods are documented exstensively, while others are not documented at all.
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: The documentation for the methods appear to be useful, however most fields and classes are not documented at all.
D3: Can you generate documentation files for this project? Run mvn javadoc:javadoc. (0: no, 1: yes, but..., 2: yes)
Answer:2
Justification: The documentation can be generated without issues.
D4: How adequate are the non-javadoc comments written throughout the code? (0: mostly inadequate, 1: average, 2: mostly adequate, 3: awesome)
Answer:3
Justification: The comments are rarerly needed, and therefore rarely but correctly used.
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: The whitespaces, tabs and naming scheme are consistent.
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: We have not seen any significant code duplication.
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:2
Justification: Some fragments are harder to understand, however, this could also be due to the use of Spring, which is also new to us.
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:3 No excessive inefficiencies
Justification: We have not found any inefficiencies, however, we are not very familiar with the framework.
Q5: Does the program crash unexpectedly (e.g. by an uncaught exception)? (0: all the time, 1: rarely, 2: it happened once, 3: never)