Software Best Practices

Voices on Software Development Best Practices
Welcome to Software Best Practices Sign in | Join | Help
in Search

Browse by Tags

All Tags » Peer Review (RSS)
  • Re: The "correct" time for peer reviews

    100% complete says: "I am ready for review"? Several issues with this method: In my opinion, only valid versions of the code should be checked into the source repository. Since the source repository only holds valid version of the code, the code is 100% complete. If 100% complete state is required...
    Posted to Forum by malcolmdavis on 05-22-2007
  • Re: The "correct" time for peer reviews

    The answer to that varies a little bit from one team to another, but in general, they make an explicit action to declare the code complete, and that action is not triggered by the source code management system (for most, it's part of the issue tracking system). Different teams have different conventions...
    Posted to Forum by Joe Eggers on 05-22-2007
  • Re: The "correct" time for peer reviews

    Is the code considered 100% complete when the code is checked into the source repository, or when the developer marks the code complete through some other means such as an issue tracking system, repository tag, or something else?
    Posted to Forum by malcolmdavis on 05-22-2007
  • Re: The "correct" time for peer reviews

    By 100% complete I meant that the developer is 100% complete with coding, commenting, and unit testing (and yes formatting, but I don't tend to think of that as a separate step) . In other words, the developer asserts that the code does not need to be touched again for any reason unless the code...
    Posted to Forum by Joe Eggers on 05-22-2007
  • Re: The "correct" time for peer reviews

    Is 100% complete equivalent to zero defect software, or 100% complete imply that all the steps to QA delivery have been followed (formatting, reviews, testing, etc.)?
    Posted to Forum by malcolmdavis on 05-22-2007
  • Re: The "correct" time for peer reviews

    Our code review practices have been very effective in reducing the number of defects delivered from development to the test group. First, understand that this is within a framework where the mantra for the development team is "zero defects delivered to QA" . Our practice is to review code at...
    Posted to Forum by Joe Eggers on 05-19-2007
  • Re: The "correct" time for peer reviews

    Jumping into the middle of an already-going conversation can be a bit dangerous, but... First off, I think you need to be careful about what you mean by "review". Reviews come in all shapes and sizes and for all kinds of different purposes. Sometimes a "design review" to kick around...
    Posted to Forum by Steve Tockey on 05-07-2007
  • Re: The "correct" time for peer reviews

    Bob, I like the idea of a few strict rules if they are the rules that, if broken, will cause you the most pain and suffering. I don't like strict rules for their own sake. I also like the idea of investing the limited time again where a mistake will cause the most pain. These are things you may even...
    Posted to Forum by Earl Beede on 05-04-2007
  • Code review is old school; it is about the build process.

    The concept of reviewing for rules validation bothers me. In the Java arena, there is numerous free and open source software (FOSS) offerings that can do automated rules review. The rules can be anything from the basic to complex rules validation. Normally, I just have everybody turn on all compiler...
    Posted to Forum by malcolmdavis on 05-04-2007
  • Re: The "correct" time for peer reviews

    We're trying to improve our approach to reviewing at the moment, so I appreciate this thread. I agree that reviewing the "inputs" is more valuable; so timing should perhaps be "as early as possible". A major aspect of timing is: how long does it take? A useful source on this is...
    Posted to Forum by bobcorrick on 05-04-2007
Page 1 of 2 (15 items) 1 2 Next >
Seminars           www.Construx.com           Consulting