Code Review - Write your code right
Writing code is definitely subjected to individual thinking, logics and perspective. How he writes code is completely depend on his technical and logical skills. 2 different people can write same code in entirely different tactic (May be both logics of the code are right in their own way). Even 2 persons can write bad code as well as good code as per standard.
In real world it is most likely possible that one writes the code and same will be read multiple times by many other developers to fix the bugs, improve the features, understand the code. That is why each language has its own style of coding and guideline to make it more meaningful and understandable.
Most of time the Developers struggle to understand the code written by someone else in team. I have even heard people saying that its difficult to read someone else code rather writing same from scratch.
I would like to highlight few compiled techniques in once place to make writing code better.
Classical Method
Classical method is tools based code review. Developers write their code and submit for review in some 3rd tool like review board, Rietveld, Collaborator for somebody to review the code.Tool will be used to track code change, comments, patches and review. Someone can merge code to the active branch once it is review. Reviewer can have a look at the code and provide comments and inputs to the relevant piece of code.
The good side is that it can be used almost all sort of old source code tools and very much compatible with most of the version control tool.
Problem with this mechanism is that it needs another tool other then version control system to maintain code review related information.
Integrated Method
To
overcome the classical method downside, review system has been
introduced with in version control tool; a very good example of this is
GIT. Where there is no (or rarely) 2nd tool needed to perform code
review activity. Code review can be done via pull request even before
merging.Comments, issues, patches can be tracked within Version control
system with same workflow.As mentioned earlier everything related to review remains with in same system and that is the biggest benefits of this system.But this mechanist also needs the same time and effort for someone else go through the code and sign off.
Extreme Workflow
Pair programming falls under this category. In this Technique, two programmers work as a pair together on one workstation. One writes code while the other, the observer, pointer or navigator, reviews each line of code as it is typed in. The two programmers switch roles frequently.This way coding and its review happen at same time by 2 programmers simultaneously.
Some says that 2 developers working on same code at same time doesn't make any sense, as they will be end up spending double man hours. It may lead to problems with practical implementation of the technique.
But the good part is that they don't need to spend extra time to understand and perform code review. It removes to and fro communication between developers. You don't even need another tool for additional help to submit patch.
In conjunction with review techniques I would like to add one more point about who can review code.
- Leaders review the code: - One of the very common processes is that 2-3 leads will review the code always from the entire team (number depends on team size). They are always whole responsible for performing the review, checking the code before it goes for further consumption.
- Anybody can review the code: - Another technique is that anybody with in team can review the code. Only restriction is that the one is writing code cannot review his own code because this doesn’t make any sense to review your own written code. There is no leader who is responsible for code review. A junior programmer can also review code written by senior, as there is no reason to allot hard role and not allowing others to review code.
Comments
Post a Comment