Project Peer Review
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: A creative approach to solve a problem
- 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: Fair implementation but for the map without the documentation
- G3: List 3 positive aspects of the project. Motivate your selection.
-
1. Could be a great idea to solve communication problems
-
2. Well implemented map at the core of the application
-
3. Flexibility
- G4: List 3 negative aspects of the project. Motivate your selection.
-
1. Too "clunky" for real emergency situations
-
2. The project feels unfinished
-
3. Not so user-friedly/intuitive
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. Interface
-
Answer:
2
-
Justification: Only used once, one method inside.
-
2. File I/O
-
Answer:
3
-
Justification: Most of the time duplicate code could've been avoided
- **3.**Lambdas
-
Answer:
4
-
Justification: Used vastly throughout the code often in conjuction with streams
-
4. Streams
-
Answer:
5
-
Justification: Used with lambdas in various parts of the code
-
5. Serialization and Deserialization
-
Answer:
4
-
Justification: Some code duplication could be avoided
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: No IDE files, No Output files and overall complete .gitignore
- 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: Instructions clear, missing some details on the usage of techinques and on the usage of the app.
Maven
- M1: Can you compile the project via Maven? (
0
: no, 1
: yes, but..., 2
: yes)
-
Answer:
2
-
Justification: No problems found using Maven
- 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)
- 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)
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)
- 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: Even without a clear description, the methods name are descriptive enough to let the test be understandable
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:
4
-
Justification: Good documentation
- 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)
- 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)
-
Answer:
2
-
Justification: Clear enough to get what the method is for, but not so detailed
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:
1
-
Justification: Some avoidable 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: The comments help understand messy methods
- 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: Not so much, the .MainFrameController could be more efficient, but nothing too crazy
- 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:
0
-
Justification: Never crashed