Almost everyone I meet who practices pair programming says that they don’t need other forms of code review.
They have a point: Pair programming is in some sense the “ultimate code review.” It’s continuous, so you’re not just getting feedback at the end. It’s deep, so subtle important problems are identified that might be hard to find in a later pass. It’s personal, so people develop more rapport and a better working relationship with each other.
But is that the end of the story on code review? I’d argue no, in two ways: That certain important problems are missed in pair programming, and that we should all be open to applying different kinds of code review (including pairing) in different situations, rather than being absolute like “Pairing is always efficient.”
To address the first point, consider briefly why peer review is so useful (and is required) in other disciplines such as writing. Every book author has an editor, and not because the author is unable to write. Rather, no matter how adept we are at the subject matter and the art of writing, we can’t see the errors in our own work — both at a detailed level (incorrect wording) and macro level (whether this reads well to a new reader, or what passages are difficult to parse).
“每本书都会有一个编辑,并不是因为这个作者不能写,而是因为:不管我们在我们自己的写作领域多么地强,我们很多时候是发现不了自己的错误的 - 不管是在细节的地方(例如:用词不当),还是在宏观的把握上(例如:我们写的东西对于初学者是否易于理解)”
The editor isn’t there necessarily to instruct the author but rather to do what the author would herself do if the author weren’t so close to the material. It’s a matter of closeness, not ability. That’s why everyone needs an editor.
Code reviews are the same. Of course, if someone else wrote that code and you were the reviewer you would have picked up on a lot of that too! Or if you were the domain expert you’d have the same insights. That makes sense, and that’s why we all need code review.
Now back to pair programming. One of the (very few!) drawbacks about pair programming is that both people are involved in the creation. They’re both “authors” in the sense that neither can assume the perspective of a developer who wasn’t privy to this intense, deep process of creation and still needs to understand the code. That’s something only an outsider can bring, by very definition.
“结对编程不好的地方在于:结对的两个人都是创作者,他们都是‘作者’!”
You can argue how valuable that perspective is, or how much time it’s worth to get that perspective after already incurring the cost of pair programming. I think the answer is: In some cases it’s quite valuable, and in many it’s not. You as the developer should use your judgment and be honest about when a particular change might be hard for a third developer to understand, and therefore it would be valuable to have someone else evaluate.
Also, it’s different when you do a separate code review looking only for maintainability. Normally it takes lots of time because you’re looking at correctness and scalability and compatibility and formatting and all sorts of things, but not in this case. If you’re scanning only for comprehension, it can go really fast, like just 5 minutes for 100 lines of code. In that case, I’d argue the time trade-off is often valuable.
Speaking of the time all this takes, let’s address the second point: the time-commitment for pair programming. Clearly the practice causes the immediate development to take twice as many staff-hours. The theory is that the quality of the code — both in direct bugs and in architecture and documentation — is improved so much that in the long view we actually spend less time to deliver solid, working, maintainable code.
I won’t argue that other forms of code review are as intense or as deep, but it’s obvious that other forms take less time up-front. (In our studies at SmartBear, users of our software Code Collaborator spend about 1/8th of the time in code review than in writing the code.) And it’s clear that these other forms will certainly confer some of the benefits of pair programming, such as finding bugs, making code more maintainable, spreading knowledge, and working together. Just not as much as pair programming.
Suppose the benefit is 36% as good as pairing but 12% of the time commitment. That’s a 3x more efficient use of your time.
Clearly sometimes the code warrants pairing. For example, when the problem at hand is really difficult, or when one of the pair is a domain expert at the problem, or when you’re training someone. But often the change is simple and a quick look-see is sufficient. Or most of the change is in your area of expertise and you need a domain expert to peek at just one file.
Clearly in those areas it’s probably more efficient to use another form of code review.
Maybe now we can all stop being so dogmatic about pair programming as the be-all-end-all, or that pair programming always takes too much time, and just agree to be sensible about how and when it’s useful, and what advantages and disadvantages it presents.
<!--<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:trackback="http://madskills.com/public/xml/rss/module/trackback/"> <rdf:Description rdf:about="http://www.softwarequalityconnection.com/2011/04/does-pair-programming-obviate-the-need-for-code-review/" dc:identifier="http://www.softwarequalityconnection.com/2011/04/does-pair-programming-obviate-the-need-for-code-review/" dc:title="Does Pair Programming Obviate the Need for Code Review?" trackback:ping="http://www.softwarequalityconnection.com/2011/04/does-pair-programming-obviate-the-need-for-code-review/trackback/" /> </rdf:RDF>-->
相关推荐
编程设计范式 介绍现代程序设计范例。 从功能程序设计开始,介绍设计配方的概念。 后者由两部分组成:任务组织(从... 除了学习程序设计之外,学生还有机会练习结对编程和公共代码审查技术,如当今工业界所发现的那样。
不必费心去理会代码审查系统和结对编程。需要搞这些的都是新手,它们只会毁掉你的声誉。 5. 知识就是力量 让那些不如你的人知道你的优势。提点他们,有导师就最好。 6. 快鱼吃慢鱼 要是你还认为像“龟兔赛跑”里的...
非常适合远程结对编程,实时调试,甚至代码审查。 视觉交流 使用Screen的始终在线绘图,您可以在屏幕上快速绘图以突出显示某些内容,或更好地传达想法。 就像在同一房间一样集思广益 白板从未如此简单。随时随地涂鸦...
矮人剧本 矮人基金会是一家创新服务公司。 自2013年以来,我们一直在建立...一起工作:结对编程 自述驱动开发 敏捷要求:用户故事 文件图 编写REST API 错误约定 写作测试和材料 代码审查 完成的定义 版本控制 写一
快乐的团队 视频@ RubyConfTaiwan 2014: : mCF67x2rP38 幻灯片: : 我想建立快乐团队,并成为快乐团队的一部分。... 代码审查/结对编程 代码样式指南 编写测试 持续集成/部署 自动化 团队
每月应用程式的心情这个小型项目的目标是在... 您可以尝试eXtreme编程概念,例如结对编程,代码审查,测试驱动开发等,并花一些时间共同计划项目的重要部分。 但是,您的“客户”所要求的唯一一件事就是使您的“概念证
我们学会了使用项目管理软件(Trello / Pivotal Tracker)将项目的组件分配给不同的团队成员,并通过规划、开发、提交、代码审查和合并开发阶段跟踪进度。 我们练习结对编程,确保定期切换合作伙伴并在驱动程序和...
突出一个你不完全知道如何在没有测试的情况下实现的功能,废弃代码,一旦你有了更好的计划,就从头开始 有一个功能是你自己的责任,当你有问题的时候和你的导师配对,审查和测试这个功能,一起重构你的代码 时间表和...
我不是在求职面试中问技术问题的忠实拥护者:我宁愿与应聘者坐在一些真实的代码前,用手按键盘,面对一个真实的问题,并希望整天进行结对编程与所有其他团队成员一起轮换。 但是,我觉得一些技术性问题可能是开始...
我不是在求职面试中问技术问题的忠实粉丝:我宁愿与考生坐在一些真实的代码前,用手在键盘上,面对一个真实的问题,并希望整天进行结对编程与其他所有团队成员一起轮换。 但是,我觉得一些技术性问题可能是开始进行...