大规模视频网站的计费与流量管理
本次分享将会就大规模视频网站的计费与流量管理这个话题，从操作层面细细进行讲解和分析，为系统工程师们揭示平日里我们没有关心的另一些内容。同时也希望本次分享能揭示行业中的一些“潜规则”，让互联网行业的流量与带宽管理更为开放与简洁。
本次演讲视频录制于QCon杭州2011。
新闻
该内容已经被标记书签！
标记书签错误，请重试！
结对编程 vs. 代码复查
作者 Chris Sims 译者 李剑 发布于 2009年1月19日
结对编程、代码复查、鼓励知识共享，这些都可以有助于提升软件质量。当敏捷 vs.精益，XP vs.Scrum，vi vs.Emacs的争论渐渐消隐，开发人员又对结对编程和代码复查的价值所在展开了争论。Theodore Nguyen-Cao在他的文章中将代码复查者比作鸡，结对编程者比作猪。
在敏捷论文中常常会提到小鸡和猪的故事。在用熏肉和鸡蛋做的早餐中，鸡只是参与，而猪则是付出。所以，“猪”这个词用来形容对某件事情付出全部精力的人，而“鸡”虽然参与了，但是投入的程度比“猪”小。
做代码复查的时候，大家一起坐下来，看某个人的代码。每个人都会提出自己的意见，但是没人每天和那段代码一起工作。看上去每个人都参与了代码复查的过程，但是没人对它有铁定的兴趣。他们只是看看代码，互相问问：“这段代码看上去怎么样？有问题么？”这个出发点很消极。但是，结对编程的人会全心投入到手头的动作上。他们所写下的代码、做出的设计等等都会立刻被用到。每个人都在积极参与，对手头的任务持有浓厚的兴趣，因为他们在一起攻克难题。
Theodore还指出，在结对编程中的反馈环要比代码复查紧密得多。在结对编程的时候，两个人一直都在写代码、复查代码、修改代码。而代码复查就把复查代码的时间推后了一些，一般都是作者觉得代码可以用以部署以后才做代码复查。
众所周知，随着发现问题到修复问题之间的时间增加，修复的成本也会以指数级急剧攀增。所以，在结对编程中发现的问题，它的成本要远远小于代码复查中发现的问题。当然，这二者的成本也更是远远小于让bug留到发布以后才被发现。与其走到最后一步，还不如既做结对，又做代码复查。
你是喜欢结对编程，还是喜欢代码复查？两种方式都在用，还是都不用？请留下宝贵意见，与其他读者共享。
查看英文原文：Pair Programming vs. Code Review
译者 李剑 李剑──ThoughtWorks高级咨询师，在持续集成、重构等领域具有丰富的经验；多次为国内大型企业敏捷组织转型提供咨询和培训服务。
很不幸
发表人
白 玉京
发表于
Re: 很不幸
发表人
熊 小
发表于
Re: 很不幸
发表人
小刀 凉粉
发表于
应考虑开发者之间的水平差异
发表人
Song Timothy
发表于
Re: 应考虑开发者之间的水平差异
发表人
熊 小
发表于
Re: 应考虑开发者之间的水平差异
发表人
xiao qi
发表于
Re: 应考虑开发者之间的水平差异
发表人
帮 马
发表于
Re: 应考虑开发者之间的水平差异
发表人
zh jock
发表于
Re: 应考虑开发者之间的水平差异
发表人
Gu Changsheng
发表于
敏捷 vs.精益，XP vs.Scrum，vi vs.Emacs
发表人
Xiang Ran
发表于
我认为结对编程和代码复查需要有更详细的内容定义
发表人
何 铭华
发表于
正好项目使用了结对编程
发表人
Wu David
发表于
交流！交流！
发表人
徐 毅
发表于
两者应该不能比较
发表人
zhang leslee
发表于
具体问题，具体分析
发表人
张 国春
发表于
-
都没有用
-
若开发者之间水平相近，结对编程的效果应该更好！
若开发者之间水平有差距，那么进行代码复审，且高水平的开发者占据主导时，效果应该比较不错。
浅见浅见，不吝批评！Thanks！ -
vi VS Emacs，这个和前面那俩貌似不是一路的。
-
为什么没有用？是在什么样的情况下没有用？
-
水平固然是一个方面，我觉得文中这样一句话应该重点注意：
做代码复查的时候……每个人都参与了代码复查的过程，但是没人对它有铁定的兴趣……他们的出发点很消极。但是，结对编程的人会全心投入到手头的动作上……每个人都在积极参与……因为他们在一起攻克难题。
也就是说，投入程度非常重要！ -
结对编程,两者在利益上是一致的,就有可能出现劣质代码的存在.代码审查,应由没有利益关联的第三方进行.在同一项目中,应该由水平较高的程序员独立进行相应的代码审核.
-
同意，开发人员之间进行代码复查时，大多发现不了什么问题；我来复查开发人员的代码时往往会发现问题。
-
他的意思应该是“没有用到”吧
-
高水平的人进行代码复查，可是开发人也许没有能力修改。（我在组织公司的 Code Review，这样的事情让我很难受）
-
我认为结对编程和代码复查需要有更详细的内容定义。
结对编程，应当存在于培训新人， 知识传播等阶段， 一般的开发，结对编程的投入和收益比比较低。
而且结对编程对人员的磨合度和自觉度有很高的要求。
在做代码审查前，应该存在代码规范， 框架规范。 对于不同水平的开发者，审查的深度应该有所不同。 -
结对编程，个人感觉确实让代码质量提高了不少，但效率并不见得提高很多。
另外，结对编程，对程序员的素质要求比较高，最好针对有较好的团队意识和编程经验的程序员才使用结对编程这种开发模式。
代码复查，以前的项目中用过，小项目，当项目上了一定规模，这种代码复查的效率和质量，会随着代码量的增加而急剧下降，建议在中小规模的产品开发中使用。
这篇文章写结对编程的不错哦，建议大家看看。
tech.it168.com/a2008/1016/208/000000208191.shtml -
结对编程也是相互学习的一个机会，我到觉得提高代码质量是一个副产品，这个过程不能缺少交流。
-
代码复查一般都在一个团队中，初级的程序员写完代码，其师傅或者项目经理会进行一次代码复查，主要以检查为主。
而结队编程，虽然可能还是同一个项目，同样2个人，一个师傅带着刚入职的“新人”，但是他们同甘共苦，一起配合完成一个目标。
我觉得完全是 就跟做导师带着学生做毕业设计，导师可能兼着两个角色，一个是指导，另外一个他可能还和你一起做核心部分的东西。
我觉得只有根据实际情况来处理，不能说哪种好，哪种不好。也没有说复查的就不投入、结队的就是劳模。只是分工不同、职责不同。:) -
结对编程，轻量易于操作，但不够严谨。代码复审，严谨但成本较高。所以实际工作中，两种方法各有侧重比较好。对于日常开发，使用结对编程以达到相互自查的目的，而代码复审则针对关键部分代码，和缺陷率较高代码，并兼有培训目的。这样对于工程师和管理层都比较容易接受。
-
不一定哦 X理论和Y理论中对人们工作动机的看法是不同的 看你选择的是哪一种了 就我接触到的程序员来讲 都是愿意写出优质高效的代码的 并以此为成就
15 条回复
关注此讨论 回复