IMHO You should not waste time reviewing things that tools can find for you. Before setting up a code review process, I would start with :
- Define a coding format and use Checkstyle to enforce it (IDE can help you out with this) - Enforce a 0 compiler warning policy - Use PMD and Findbugs to look at the code. You will also need to define what FindBugs/PMD issues you're willing to live with. After you set these foundations, I would use crap4j to list the crap in the code base. And I review that starting with the crappiest. In order to keep this answer short, I'm not going to address TDD. Which can also be good for reviewing good and share knowledge. On Thu, Feb 12, 2009 at 5:01 AM, jvb <[email protected]> wrote: > > In our company, we are thinking about introducing some formalized form > of peer code review. We (the Java guys) are a small team of 5 > developers only, and in practice we already discuss each others code > all the time (informally). There are of course some highly specialized > parts of the codebase that are almost exclusively known by one or two > persons only, certainly because we don't work on a single application > but more a whole suite of applications (used to manage satellite earth > stations). > > The person who wants to introduce this idea of a more formalized peer > code review comes from a different enviroment (mainframe stuff) where > the write/compile/test cycle was much slower. In his environment it > was obvious that code review (even before compiling if I understand > correctly) is very usefull to find bugs which would otherwize slow > down the already slow write/compile/test cycle even more. > > Now I'm thinking how we can translate this to our java development > environment. We are obviously not going to review code to find compile > errors ;-) > > - What kind of errors should we focus on when doing code review > (style? concurrency issues? use of patterns? whether it fits in the > overall architecture? whether the code actually implements the > requirements? ...) > - How do we best organize these peer reviews such that they will > provide a real benefit, knowing that our day to day way of working > already implies working with each others code a lot? > - Should we be focussing on the parts of the code that are less known > by everybody? > - Should we be sitting together around a screen/projector, or should > we simply assign parts of the codebase to be reviewed by certain > developers on their own? > - Should we be looking at tool support? > - ... > > Does anybody has any experience and/or usefull information to share? > > many thanks in advance, > Jan > > > -- Luc Trudeau -- A computer scientist is someone who, when told to 'Go to Hell', sees the 'go to', rather than the destination, as harmful. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
