Review by group emergency
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: The idea is intresting, but a lot of similar games exist that are really similar to this one. The story and the telegram feature are interesting and bit unique
- 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 project has a lot of complex concepts like threads.
- G3: List 3 positive aspects of the project. Motivate your selection.
-
1. Having two different GUI for the same project is really interesting
-
2. The graphics of the game are great
-
3. It is nice that the game includes a small story
- G4: List 3 negative aspects of the project. Motivate your selection.
-
1. The window is not resizable and on monitors with high resolution really small
-
2. The arrows on the main page are shown even tough they can not be clicked
-
3. No feedback in the shop if a generator has been bought.
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. Builder Pattern
-
Answer: 5
-
Justification: The builder pattern was used to solve a important aspect of the game and it has been done correctly
-
2. Abstract class
-
Answer: 3
-
Justification: There is only on class that extends the GeneratorBody and the abstract class is not used often. Maybe some additional information in the documentation why this class exists could have been nice
-
3. Custom exceptions
-
Answer: 5
-
Justification: The custom exception was implemented well and has unique functionality and an unique use case.
-
4. JSON Serialization
-
Answer: 5
-
Justification: It was correctly used to store the game state in a file
-
5. Streams
-
Answer: 5
-
Justification: The streams in the code were useful to simplify the code
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 exludes all 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: All important information is given in the file
Maven
- M1: Can you compile the project via Maven? (
0
: no, 1
: yes, but..., 2
: yes)
-
Answer: 2
-
Justification: The project compiles fine
- M2: Can you clean the project via Maven? (
0
: no, 1
: yes, but..., 2
: yes)
-
Answer: 2
-
Justification: The projects is cleaned by maven
- 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: Both versions of the program run perfectly
- M4: Are the project's dependencies appropriately configured in
pom.xml
? (0
: no, 1
: some, 2
: yes)
-
Answer: 2
-
Justification: All the dependencies are correctly configured
- M5: Are all Maven plugins appropriately configured in
pom.xml
? (0
: no, 1
: some, 2
: yes)
-
Answer: 2
-
Justification: All the plugins are correctly configured
- M6: Does the project adopt Maven's standard directory layout? (
0
: no, 1
: yes, but..., 2
: yes)
-
Answer: 2
-
Justification: The layout was correctly followed
Testing
- T1: Are all tests passing? Run
mvn test
. (0
: no, 1
: yes, but..., 2
: yes)
-
Answer: 2
-
Justification: All the test are passing
- 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: 4
-
Justification: All important methods are covered.
- 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 most of the cases of each method
- 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 tests can be understood easily
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 is easy to follow.
- 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 provides important information to understand the code, but some things are not documented.
- 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 gets generated without errors
- D4: How adequate are the non-javadoc comments written throughout the code? (
0
: mostly inadequate, 1
: average, 2
: mostly adequate, 3
: awesome)
-
Answer: /
-
Justification: No non javadoc comments
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 codestyle is consistend 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: There is no code duplication that we noticed
- 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: The code is easy to understand
- 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
-
Justification: We have not seen any particulary inefficent code
- 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: The program never crashed on our test runs