Peer-review by Endless Maze
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: 4
- Justification: The project idea is original and unique, I liked the fact that you can run the project as a telegram bot.
-
G2: How difficult was it to implement the project? (0: no challenge, 1: very easy, 2: easy, 3: fair, 4: complex, 5: insane)
- Answer: 5
- Justification: The project uses many advanced techniques.
-
G3: List 3 positive aspects of the project. Motivate your selection.
- 1 Multiple user interfaces – portability: The code is portable and you can play in two different ways.
- 2 Good branch strategy
- 3 Multi threading and the efficiency of the code
-
G4: List 3 negative aspects of the project. Motivate your selection.
- 1 The shop is not completely centered on linux
- 2 Unable to adapt to full screen
- 3 Lack of objects description in the shop
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: Streams used made the code more readable and understandable as they are supposed to do.
-
2 Method overriding
- Answer: 5
- Justification: Different methods are overridden, mainly in classes that uses design patterns.
-
3 Singleton pattern
- Answer: 5
- Justification: Used to share variables for all the concurrent processes. It creates (ONLY) one instance of the class Balance and provides a global access point to that instance.
-
4 Serialization
- Answer: 5
- Justification: Serialization (and de-serialization) is used to save the progress of the game using the Jackson library.
-
- Multithreading
- Answer: 5
- Justification: Multiple threads are used, one for updating the timer, the balance and the object bought and one for updating the GUI.
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: All extensions format and files that are not needed are ignored.
-
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 file is well written, it explains the project, how to compile it and how the program works. I also found the video attached very exhaustive.
Maven
-
M1: Can you compile the project via Maven? (0: no, 1: yes, but..., 2: yes)
- Answer: 2
-
M2: Can you clean the project via Maven? (0: no, 1: yes, but..., 2: yes)
- Answer: 2
-
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
-
M4: Are the project's dependencies appropriately configured in pom.xml? (0: no, 1: some, 2: yes)
- Answer: 2
-
M5: Are all Maven plugins appropriately configured in pom.xml? (0: no, 1: some, 2: yes)
- Answer: 2
-
M6: Does the project adopt Maven's standard directory layout? (0: no, 1: yes, but..., 2: yes)
- Answer: 2
Testing
-
T1: Are all tests passing? Run mvn test. (0: no, 1: yes, but..., 2: yes)
- Answer: 2
- Justification: All 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: The tests cover all important methods ranging from de/serialization, concurrency, math and logic.
-
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: Tests cover all important methods and their behaviour. The methods that implement concurrencies are tested more than once to make sure that the results are reliable.
-
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: Most of the tests are easily understandable but I would suggest some comments or documentation in tests that are more difficult to understand.
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: Documentation is present in every method and it explains the basic purpose of its method.
-
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 is useful, although some of the text written explains only the main objective of the method, the code is clear and is not difficult to understand how is implemented.
-
D3: Can you generate documentation files for this project? Run mvn javadoc:javadoc. (0: no, 1: yes, but..., 2: yes)
- Answer: 2
-
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: There are not many comments outside the javadoc ones but they serve their purpose.
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 style is 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: code duplication was not encountered during evaluation.
-
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: It is not easy to understand everything at first glance but the code is clear.
-
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: The program is efficient thanks to the use of concurrency.
-
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 worked as intended during the whole period of testing.