Project Peer Review
Review form
General
- G1: How creative is the project? (
0
: I've seen this on Youtube,1
: not creative2
: average,3
: creative,4
: very creative,5
: wow!)-
Answer:
5
- Justification: Didn't think a project like this could've been possible in a few months
-
Answer:
- 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: Every single option: IDE, New Language, Challenges, etc. by themselves are pretty complex, the fact that they are all in one project working together plus only two people working on it makes this project a defined masterpiece.
-
Answer:
- G3: List 3 positive aspects of the project. Motivate your selection.
- 1. Powerful yet discrete - it doesn't scream complex but the more you use it, the more it becomes clear that it's so much more than a simple app.
- 2. Clean code, well documented and easy to understand after a few minutes of reading the code
- 3. Overall a complete user experience, fun and catchy to use.
- G4: List 3 negative aspects of the project. Motivate your selection.
- 1. ?
- 2. ?
- 3. ?
Programming techniques
- PT1: Evaluate how well 5 programming techniques we learned throughout the course were adopted in the project. Assign a mark from
0
to5
to each technique, where0
means completely incorrect usage and5
means perfect usage.-
1. Abstract Classes
-
Answer:
5
- Justification: Present throughout different parts of the program, lead to a cleaner and more efficient code structure
-
Answer:
-
2. Exception Handling
-
Answer:
5
- Justification: Custom exceptions, mostly in the interpreter
-
Answer:
-
3. REGEX
-
Answer:
5
- Justification: Used for syntax highlighting in the editor making using it a pleasure
-
Answer:
-
4. File I/O
-
Answer:
5
- Justification: Used in multiple parts of the program to save and retrieve data about the state of the games and user, makes the overall experience more taylored towards the user
-
Answer:
-
5. Serialization and Deserialization
-
Answer:
5
-
Justification: Goes hand to hand with the
PT1.4
, the use of Gson made it cleaner and more efficient
-
Answer:
-
1. Abstract Classes
Git repository
- GR 1: How appropriate is the
.gitignore
file of the project? (0
: missing,1
: very bad,2
: bad3
: average,4
: good,5
: very good)-
Answer:
5
- Justification: No IDE files, No Output files and overall high-end structured .gitignore
-
Answer:
- GR 2: How appropriate is the
README.md
file of the project? (0
: missing,1
: very bad,2
: bad3
: average,4
: good,5
: very good)-
Answer:
4
- Justification: Instructions clear, everything about the developer-side of the project pretty clear, but it does only mention briefly the app itself and all its features.
-
Answer:
Maven
- M1: Can you compile the project via Maven? (
0
: no,1
: yes, but...,2
: yes)-
Answer:
2
- Justification: No problems found using Maven
-
Answer:
- M2: Can you clean the project via Maven? (
0
: no,1
: yes, but...,2
: yes)-
Answer:
2
- Justification:
-
Answer:
- 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:
-
Answer:
- M4: Are the project's dependencies appropriately configured in
pom.xml
? (0
: no,1
: some,2
: yes)-
Answer:
2
- Justification:
-
Answer:
- M5: Are all Maven plugins appropriately configured in
pom.xml
? (0
: no,1
: some,2
: yes)-
Answer:
2
- Justification:
-
Answer:
- M6: Does the project adopt Maven's standard directory layout? (
0
: no,1
: yes, but...,2
: yes)-
Answer:
2
- Justification:
-
Answer:
Testing
- T1: Are all tests passing? Run
mvn test
. (0
: no,1
: yes, but...,2
: yes)-
Answer:
2
- Justification:
-
Answer:
- 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:
-
Answer:
- 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:
-
Answer:
- 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: Pretty clear what tests are for and how they behave
-
Answer:
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: Split documentation to ease access makes it more understandable
-
Answer:
- 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:
-
Answer:
- D3: Can you generate documentation files for this project? Run
mvn javadoc:javadoc
. (0
: no,1
: yes, but...,2
: yes)-
Answer:
2
- Justification:
-
Answer:
- 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:
-
Answer:
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: Definitely consistent and clean
-
Answer:
- 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: Very few needed code duplication
-
Answer:
- 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 way it's structured makes it a walk in the park to understand
-
Answer:
- 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:
-
Answer:
- 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: Never crashed
-
Answer: