Anselm Paulinus wrote:There is a new school of thought that believes that code review should be a distinct entity like QA, outside the purview of those who developed the code. What is your take on this and did you address this type of issue in your book debug it?
paul.butcher->msgCount++
Author of Debug It!: Find, Repair, and Prevent Bugs in Your Code
[OCP 17 book] | [OCP 11 book] | [OCA 8 book] [OCP 8 book] [Practice tests book] [Blog] [JavaRanch FAQ] [How To Ask Questions] [Book Promos]
Other Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, TOGAF part 1 and part 2
Paul Butcher wrote:Up until fairly recently, the "received wisdom" was that it was impossible for a developer to test his or her own code - that the primary purpose of testing was to uncover the developer's broken assumptions, and that had to be done by someone independent, who hadn't been "polluted" by those broken assumptions.
Anselm Paulinus wrote:There was a time when testing was done by the developer and the owner of the software, any mention of a dedicated testing arm would have mey some opposition; today we can tell of the benefits of having a dedicated testing team in an organisation, only time will tell if code review would be given the same prominence as testing.
SCJP 5 | SCWCD 5
[How to ask questions] [Twitter]
Jeanne Boyarsky wrote:I see a huge advantage of having teammates review the code - it gets them familiar with the code. After all, who has to maintain the code? It isn't the QA department.
Mike Simmons wrote:... Similarly, should code review be done by a separate entity (not QA, but some new entity), or by developers? The answer to this second question is up for grabs at the moment. But let's be clear: we're not talking about whether QA should review code. We're talking about whether some independent entity should review it.
In general though, I see much more value in having other developers do it. Preferably, other devs on the same team, or maybe on other teams likely to interact with that code in the near future. There may be some value in having an independent team do it as well - maybe. But only in addition to having regular developers do it, I think.
Vikas Kapoor wrote:
Mike Simmons wrote:... Similarly, should code review be done by a separate entity (not QA, but some new entity), or by developers? The answer to this second question is up for grabs at the moment. But let's be clear: we're not talking about whether QA should review code. We're talking about whether some independent entity should review it.
In general though, I see much more value in having other developers do it. Preferably, other devs on the same team, or maybe on other teams likely to interact with that code in the near future. There may be some value in having an independent team do it as well - maybe. But only in addition to having regular developers do it, I think.
If you mean other project team (luckily working on the same technology) by saying 'new entity' then only it makes sense other wise having a new guy/team for code review is impractical and not economical. She/Team has to cope up with the business functionality, technology and what not. Ideally they are just any other developer in the team (better than developers) but not doing any development but code review only.
Anselm Paulinus wrote:There is a new school of thought that believes that code review should be a distinct entity like QA, outside the purview of those who developed the code. What is your take on this and did you address this type of issue in your book debug it?
Vikas Kapoor wrote:Will not that confine the quality up to certain extent? To review the code somebody should be better than the one who coded it, shouldn't be? then only she can give suggestion, improvements or feedback in general.
[OCP 17 book] | [OCP 11 book] | [OCA 8 book] [OCP 8 book] [Practice tests book] [Blog] [JavaRanch FAQ] [How To Ask Questions] [Book Promos]
Other Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, TOGAF part 1 and part 2
Did you see how Paul cut 87% off of his electric heat bill with 82 watts of micro heaters? |