Feedback Sprint 4

[lkrombeen]

sprint planning:

• Prioritization is better. Adjust it slightly so the different categories are also prioritized e.g. which issue with priority label A is the most important, put that above the other issues with a label A. Unless you have already done that in which case you can ignore this.
• Retroperspective has improved. It is good that you are honest that you do not know how to improve, but it would be even better to come up with something and reflect on that next week. You could discuss which team members do some tasks easier than others. If one person is really good at testing you may let him do it. If you are doing the estimates by group you may want to change that to a different system where the person assigned estimates how long he thinks it will take for him to implemented it. Try something, if it works it works, if it does not you can try something else. You are graded on how well you implemented your own advice for future sprints, so it is a case of “something is better than nothing”. I would like to add that you should fail fast. Do not hold onto something the entire week if it did not work in the first day. If you fail, you can reflect, improve etc.. Rinse repeat :)
• Nice to see that you are making up some of your hours! keep it up guys :)
• Splitting is much better.

code evaluation

• Rename the “Parsing” folder to “parsing” to fix the compile errors.
• No direct commits in master, good!
• Two pull requests which had a build failure were merged and not discussed why this was acceptable in the pull requests.
• Always close your FileReader and FileOutputStream Objects. For example in Parser.java, SegmetDB.java and FileSystem.java
• There are some classes with methods that have a high complexity. For example Node.java which has a method with complexity 18 and 2 triple nested if/for/while loops.
• If you use a string multiple times, define it as a constant. For example “Segment.txt” which is used three times in Parser.java.
• When referring to class variables, use this. For example, this.backLog in window.java. Otherwise you should make the variable static.
• NodeTest.java has a confusing method: equals.
• Logger.java has commented code.
• The variable newCache in Parser.java is unused. So it int y = 291. So is openButton in Controller.java.
• NEVER use node.equals(null). This will always return false. Use node == null to check for nullity.
• If you override an Object.equals() method you should also override the Object.hashCode() method.
  line.indexOf(‘\t’) is faster than line.indexOf(“\t”) (difference between char and strings)
• “” + some int is not the way to convert an int to a String. user Integer.toString() instead.
• Add @overide annotations above some methods signature. For example at NodeCenter.handle().
• The location of your tests are not fixed. Use the default maven testing setup so that when you run mvn cobertura:cobertura a nice report gets generated which shows the what is covered and what not.
• There are some warnings in your project e.g. unused imports.
• Use your logger to log exceptions that are not rethrown for example.
• Code reviews have improved.
• Good use of branching.