Review by Group PP-BoardGames
Review form
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 is 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 maps and the complexity project make this a very hard.
- G3: List 3 positive aspects of the project. Motivate your selection.
-
1. GUI is very clear
-
2. Very well written documentation
-
3. The programming techniques taught in the course were used perfectly.
- G4: List 3 negative aspects of the project. Motivate your selection.
-
1. There is no subfolder on the part
gui
-
2. There are some bugs while resizing the GUI and some unfinished graphics
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 are used at perfection and easily readable
-
2. Collections
-
Answer:
5
-
Justification: They use of Lists and Sets in the proper way.
-
3. Deserialization
-
Answer:
5
-
Justification: The Converter classes are easily readable and very well explained
-
4. Regular expressions
-
Answer:
5
-
Justification: Regulars Expression was consistently used and skilfully implemented
-
5. Abstract classes
-
Answer:
5
-
Justification: The usage of
Vehicle
is a perfect example of an Abstract class
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's perfect
- 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:
4
-
Justification: The README.md includes all the information requested for compiling but not delivering. The included video explains the application quite rightly.
Maven
- M1: Can you compile the project via Maven? (
0
: no, 1
: yes, but..., 2
: yes)
- M2: Can you clean the project via Maven? (
0
: no, 1
: yes, but..., 2
: yes)
- 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:
1
-
Justification: There are some missing details like Java Version and how to get a package
- M4: Are the project's dependencies appropriately configured in
pom.xml
? (0
: no, 1
: some, 2
: yes)
- M5: Are all Maven plugins appropriately configured in
pom.xml
? (0
: no, 1
: some, 2
: yes)
- M6: Does the project adopt Maven's standard directory layout? (
0
: no, 1
: yes, but..., 2
: yes)
-
Answer:
2
-
Justification: In the
pom.xml
the <groupId>
is still the default org.example
Testing
- T1: Are all tests passing? Run
mvn test
. (0
: no, 1
: yes, but..., 2
: yes)
- 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)
- 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: 4
-
Justification: Every test possible in the logic has been made but there is no test for the GUI
- 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 test is nicely explained
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: There is the documentation for everything and every parameter is explained in great way
- 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: Without it it's complicated to know exactly what everything does
- D3: Can you generate documentation files for this project? Run
mvn javadoc:javadoc
. (0
: no, 1
: yes, but..., 2
: yes)
- D4: How adequate are the non-javadoc comments written throughout the code? (
0
: mostly inadequate, 1
: average, 2
: mostly adequate, 3
: awesome)
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 perfect
- 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)
- 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: The code is easily readable thanks to the comments, but in the
gui
is a bit confusing
- 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:
2
-
Justification: Apart from some duplications in the
gui
- Q5: Does the program crash unexpectedly (e.g. by an uncaught exception)? (
0
: all the time, 1
: rarely, 2
: it happened once, 3
: never)