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:4
Justification: Clicker games are very popular, but the implementation and the Telegram bot are very creative.
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 usage of threads and the implementation of the Telegram bot surely added challenges.
G3: List 3 positive aspects of the project. Motivate your selection.
1. The UI of the Game is very pretty and intuitive to use.
2. The Autosaving feature is very nice.
3. The Telegram is a very unique feature that makes it special.
G4: List 3 negative aspects of the project. Motivate your selection.
1. The game doesn't have a real final goal
2. The UI is not resizable.
3. Finding another one would be forcing it, the code and the UI is clean and we couldn't find any other bugs.
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. Streams
Answer:5
Justification: They used streams to calculate the number of generators that a player owns, so the intended use.
2. Exception Handling
Answer:5
Justification: They used Exception catching to catch all the thrown errors, for example when using file IO, or the TelegramApi.
3. Lambdas
Answer:5
Justification: They used Lambdas mainly in testing and in the correct way.
4. Test Hooks
Answer:5
Justification: They used Test Hooks to correctly to create and then delete files used in testing.
5. Serialization
Answer:5
Justification: They use Jackson to serialize the gamestate to save it in a file, to manage the savegame.
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 contained all the information requested, and explaind the structure and usage very well.
Maven
M1: Can you compile the project via Maven? (0: no, 1: yes, but..., 2: yes)
Answer:2
Justification: The project compiles successfully.
M2: Can you clean the project via Maven? (0: no, 1: yes, but..., 2: yes)
Answer:2
Justification: The project cleans without issues.
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: The provided command runs the application correctly.
M4: Are the project's dependencies appropriately configured in pom.xml? (0: no, 1: some, 2: yes)
Answer:2
Justification: All used dependencies are configured correctly and comments lead to the documentation of them.
M5: Are all Maven plugins appropriately configured in pom.xml? (0: no, 1: some, 2: yes)
Answer:2
Justification: All the plugins are appropriately configured for the intended usage.
Justification: The project follows the standard maven structure perfectly.
Testing
T1: Are all tests passing? Run mvn test. (0: no, 1: yes, but..., 2: yes)
Answer:2
Justification: All tests run without issues.
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: Since 100% test coverage is unrealistic for a JavaFX application, we think that they really put time and effort into testing, so they deserve it.
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: The tests verify the expected behaviour nicely.
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: All the tests are commented well, and the naming is appropriate.
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:5
Justification: The documentation covers and explains all the classes, fields and methods of the program.
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:5
Justification: The documentation shows their goal of clean code and the time they spent on the documentation.
D3: Can you generate documentation files for this project? Run mvn javadoc:javadoc. (0: no, 1: yes, but..., 2: yes)
Answer:2
Justification: All documentation is generated correctly by using the maven command.
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: All the non-javadoc comments are used appropriatley to explain something more in detail.
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 code is clean and well organized and keeps the same formatting throughout the project.
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: Our resdearches have not found any code duplications.
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:3
Justification: With the help of the tests, documentation and well structured code it is easy to understand how the application works.
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 could not locate any excessive inefficiensies.
Q5: Does the program crash unexpectedly (e.g. by an uncaught exception)? (0: all the time, 1: rarely, 2: it happened once, 3: never)