Code review and cooperative pair programming best practice

📝 Abstract

We need ways to improve the code quality. Programmers have different level of tenure and experience. Standard and programming languages change and we are forced to re-use legacy code with minimum revision. Programmers develop their habits and can be slow to incorporate new technologies to simplify the code or improve the performance. We rolled out our customized code review and pair programming process to address these issues. The paper discusses the about the improvement of mandatory code review and pair programming practiced in the commercial software development, and also proposes effective approaches to customize the code review and pair programming to avoid the pitfalls and keep the benefits.

💡 Analysis

We need ways to improve the code quality. Programmers have different level of tenure and experience. Standard and programming languages change and we are forced to re-use legacy code with minimum revision. Programmers develop their habits and can be slow to incorporate new technologies to simplify the code or improve the performance. We rolled out our customized code review and pair programming process to address these issues. The paper discusses the about the improvement of mandatory code review and pair programming practiced in the commercial software development, and also proposes effective approaches to customize the code review and pair programming to avoid the pitfalls and keep the benefits.

📄 Content

CODE REVIEW AND COOPERATIVE PAIR PROGRAMMING BEST PRACTICE Qiang Fu1, Francis Grady1, Bjoern Flemming Broberg1, Andrew Roberts1, Geir Gil Martens1, Kjetil Vatland Johansen1, Pieyre Le Loher1 1 Schlumberger Information Solutions AS, Stavanger, Norway Qfu3@slb.com ABSTRACT We need ways to improve the code quality. Programmers have different level of tenure and experience. Standard and programming languages change and we are forced to re-use legacy code with minimum revision. Programmers develop their habits and can be slow to incorporate new technologies to simplify the code or improve the performance.
We rolled out our customized code review and pair programming process to address these issues. The paper discusses the about the improvement of mandatory code review and pair programming practiced in the commercial software development, and also proposes effective approaches to customize the code review and pair programming to avoid the pitfalls and keep the benefits.
KEYWORDS Code review, pair programming, customization

1. INTRODUCTION Several common issues can be noted from the programming practice of working on an existing big software:

1. outdated routines/patterns are still used, 2) some code does not follow the industrial standards, 3) changes are not properly documented. The importance of code quality can never be underestimated even for a deadline-driven world. Code review, a manual inspection of source code by developers other than the author, is a common software engineering practice employed in industrial contexts and is recognized as a valuable tool for reducing defects and improving quality. The policy of 100 percent code review has been implemented/discussed in many commercial software projects.
   Classical pair programming is an agile software development technique in which two programmers work together at one workstation [1]. Traditionally, one programmer writes code while the other reviews each line of code as it is typed in. The two programmers switch roles frequently. Some obvious benefits can be achieved with pair programming: 1) fewer bugs, 2) lower cost on production maintenance, and 3) knowledge transfer [2, 3]. Another benefit is that both developers acquire a good understanding of all the written code; they know what the design choices were and how the code works. From many aspects, this reduces the fragmentation of knowledge within a team.
   Another agile software development technique, pair programming is also becoming increasingly popular in the software industry. It is more suitable for centrally-located team than the geographically-distributed team. It is commonly considered that pair programming can get more maintainable design with better quality, but in real working environment it often trapped in some pitfalls [4, 5]:
2. Discourages introversion. The coder must “program aloud” while the reviewer listens. Some developers will not raise concerns or suggest corner cases, thus turning the pair programming into “solitary programming” with automatic code review, which wastes resources.
3. Prevents creativity. Contrary to the value of “group brainstorming”, creative work sometimes requires independence and autonomy. In pair programming, developers must be able to convince a partner of the merits of an idea. This requires talking through the implementation
4. Step by step and risking being judged if the idea fails.
5. Tiring practice. A good pair programming session is intense and mentally demanding. Programmers have reported significant exhaustion after just a few hours. This is a common observation, even from the most experienced practitioners and the advocates of pair programming.
6. Demanding balance maintenance. Pair programming can cost more work-hours than solitary programming to produce the same feature if the cooperation is not planned properly. A balance must be maintained carefully between the quality of code and the increased programming cost.
   Mandatory code review and pair programming are being practiced in our team recently. Based on the actual circumstance of our team, the traditional code review and pair programming are tailored to get the advantages and avoid the pitfalls mentioned above.

2. CODE REVIEW Mandatory code review was introduced in our team in July 2016. Although our main motivation for conducting code reviews was finding bugs, we found that reviews brought several additional benefits including knowledge transfer, increased team awareness and the creation of more elegant solutions. From the outset, we established some principles:

1. Programmer reviewing. Code should be reviewed by active programmers, not the managers.
2. Rotating reviewer. Many code review guidelines recommend that the original author of a piece of code perform the review of any subsequent changes; in our case, that is largely impossible. Team and code ownership changes mean that the original author may work in a different tea

This content is AI-processed based on ArXiv data.