Win a copy of Reactive Streams in Java: Concurrency with RxJava, Reactor, and Akka Streams this week in the Reactive Progamming forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Junilu Lacar
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Knute Snortum
  • Tim Cooke
  • Devaka Cooray
Saloon Keepers:
  • Ron McLeod
  • Stephan van Hulst
  • Tim Moores
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Piet Souris
  • Frits Walraven
  • Ganesh Patekar

Debug it as relates to code review

 
Ranch Hand
Posts: 390
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
author
Posts: 41
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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?



That's an interesting question, Anselm. I do mention code review in the book, but not in great detail.

I suspect that the answer is similar to the question of whether testing should be carried out by developers or a dedicated QA department. 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.

We now all realise that, although there is a kernel of truth in the above, it does not mean that developers shouldn't test their own code! The success of tools like JUnit demonstrates we developers (most of us, at least) are testing our own code and not simply relying on QA to uncover our mistakes. This is an entirely good thing - in fact I would argue that the widespread adoption of automated unit tests is probably the single most important step we've made as a profession in the last decade.

Does that mean that there's no value in a separate QA department? Of course not. But it's not a question of either/or, but both/and.

So coming back to code review, I suspect that it's also a false dichotomy. Does it make sense for developers to review their own (or their colleagues') code? Absolutely. Can the QA department's different perspective help? Absolutely. If I was working on safety critical software (where the cost of a bug might be someone's life), I would unquestionably want to see both forms of review taking place. For less critical software, it becomes a cost/benefit tradeoff where the right answer will depend upon your specific situation and the skills of the various members of your organisation.

What has your experience of code review been?
 
Anselm Paulinus
Ranch Hand
Posts: 390
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In my experience, I can say code review done by developers who developed the code is not without sentiments. At times one could write less efficient code, though we as developers might know ways of making such code efficient, but do not impress it on the programmer to re-write the code. This is more so when we have steep deadlines to work with. There are even cases where non working codes have been checked into the repository in order to beat development deadlines, hoping that the flows will be detected during testing and returned to the developer to complete the work. These little twists are what a dedicated code review team will be able to bridge. Corporations will be saved a lot of money by having such dedicated team especially in mission critical applications because it costs much much less to find a bug upfront than to find it later. This is my take on this topic. Hope others air their views as well.
 
author & internet detective
Posts: 39530
776
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 235
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I work within an organization who's QA department isn't technical enough to understand the code - so having them review it would be pointless. I'm going to agree with Jeanne here, those who write/maintain/debug the code should be reviewing it. I'll go a step further and say that the quality assurance departments job isn't to execute tests (use an automation tool for that). QA's responsibility is to *find* tests to be executed.
 
Rancher
Posts: 3369
31
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I don't think anyone was suggesting that QA actually do code review. Not that it isn't possible, in some circumstances, but that wasn't the point of this discussion. QA was cited as a parallel example: should testing be done by a separate entity (QA), or by developers? In many modern organizations, the answer is both. 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.
 
Anselm Paulinus
Ranch Hand
Posts: 390
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Mike Simmon for clarifying things here, for further clarification the code reviewers on their own are developers, definitely not QA. For those wanting to know more about this subject matter, please visit go2quality.com. There are bodies who are advocating for this separate entity of code reviewers for the reasons I pointed at earlier on.
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.
 
Mike Simmons
Rancher
Posts: 3369
31
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Interesting. Following up on a tangent here: on the topic of testing (not code review) by QA, I see two different, somewhat contradictory views of the past:

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.



At first glance they may seem incompatible, but on reflection there are many possible ways to resolve the apparent conflict. So now I'm wondering: were these views from two different points in time? (If so, which came first?) Or were these same views held concurrently by different groups? Or am I just misunderstanding one of these, or both?

To reiterate: this is a tangent, not the original point of the thread. I'm just curious about the historical context, how these views evolved. Thanks.
 
Bartender
Posts: 4101
64
Hibernate Fedora Chrome
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In my little industry experience generally QA people doesn't go in to code level testing as they might not be much familiar with them rather they so bit high level functionality testing of the application. But there can be places where QA people doing code level testing too. So I think as mentioned previously with tools like JUnit it's the developers (either same person or some other developer) responsibility to do the developer level testing.
 
Mike Simmons
Rancher
Posts: 3369
31
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
And just to muddy the waters with another digression that mixes the different issues from this thread: in my organization, and on my team specifically, we do sometimes have testers review code. And we're looking to do it more often. Our testers may not know Java very well (yet), but they're quite "technical" in other areas. And they tend to be much better than us at (a) understanding the user experience, and (b) ferreting out obscure corner cases that we haven't considered. Also (c) they've actually read, and remember, all the detailed requirements docs that we devs pay lip service to. Well, we pay more than lip service, but our testers pay a good deal more attention to all the details. Oh, and also (d) some of them want to learn more about Java programming to further their career goals. So including them in code reviews can benefit both developers and testers, and can reduce the cycle time to get things done. So while I understand there are plenty of situations where this doesn't apply, I also want to acknowledge that there are also situations where having QA do code reviews really does make sense. On my team, we've got some really good QA people - and I think we benefit greatly from including them in many traditionally "developer"-oriented activities.
 
Ranch Hand
Posts: 1374
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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.



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.
 
Vikas Kapoor
Ranch Hand
Posts: 1374
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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
Ranch Hand
Posts: 390
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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.



Have you been in a project where due to time constraint, everything was checked into the repository, even when you knew you had a less efficient code or a code that did not work at all. You buy time, wait for the testers to pinpoint the flaws, then you go ahead and complete the work, does it not make more economic sense to know that some code did not work and as a result be able to tell how productive/unproductive a team is? My take in this issue is that the code review team are not just there waiting for you to get done so they could perform code review on your code, rather they might be engaged in the review of other peoples codes as well, which means some code can only be said to be in a working state if approved by the code review team, especially with the wide use of scrum methodology in code development and task assignement, I think the code review team will be kept busy at all time. Also scentiments will be removed in the review, immagine what it would be like if you have programmers test their own codes. I bet some known flaws will remain hidden from the owner of the code, just for him/her to stumble on it some day and the developer will act like he never knew there was such flaw on the code.
 
Ranch Hand
Posts: 73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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?



We have been pushing this methodology in addition to developer/development team reviews for couple reasons:

1: We spend substantial time at the end of our interations/projects to document lesson learnt and as a result developed a checklist for developers. This is based on experience and mistakes/defects.
2. Time plays a very vital factor in delivery, but for us if you can't stick to the checklist at the minumum then its a No Go, because simple things have brought down big applications(read revenue).
3. Team reviews are helpful if its done with the right intention and teammembers take the effort, at times it was my code is fine yours if fine ....good thanks bye.

My two cents ...external entities are advantages depending on how its implemented.


 
Jeanne Boyarsky
author & internet detective
Posts: 39530
776
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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.


Not neccessarily. I think it is good to get code reviews from people who know more and less.

More - draw on their experiences
Less - expose them to different types of code styles, see how readable your code is

This is complicated by the fact that people know more about different topics without knowing more overall.
 
A timing clock, fuse wire, high explosives and a tiny ad:
Java file APIs (DOC, XLS, PDF, and many more)
https://products.aspose.com/total/java
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!