（转载）敏捷开发一千零一问系列之三十三：每天编码多少行？
（转载）http://blog.csdn.net/cheny_com/article/details/8786595
这是敏捷开发一千零一问系列的第三十三篇。（在这里提问，之一，之二，之三，问题总目录）
原问题来自http://blog.csdn.net/cheny_com/article/details/6594507#comments六楼，经读者同意，摘录如下：
“一般而言，大致每天高手能编写100多行有效代码（按分号计数），新手会多一些但也不超过200（他们编写代码比较费）。” 从整年平均来说，这个数据是不是有点大？记得在你的哪篇博客里有提到，你说过你工作的4-5年间，仅写了2万行代码而已——平均一天不到20行啊。我以前一直认为日均100行大概是一个主流行情，我所经历的项目大概是这个水平，那是因为我们项目是从零做起，而且界面较多，编码难度不大（但业务难度较大）。最近我们的项目要产品化，修修补补了一年多，突然发现，即使对我们的软件，也肯定不到日均100行啊。大部分时间在调试；改BUG；因需求调整，而做一些修改（修改人可能和开发者不是同一个人了），这时对原来代码有一个重新学习的过程（就是捋一遍）。------- 这其实是代码质量差的表现之一。所以我越来越想在项目中引入结对编程，以此提高质量，减少返工和重新学习代码所需要的时间。
（结对编程）你觉得可行吗？
答（原答案有扩充）
关于编码速度
大致的编码速度
“高手每天100行”是编码阶段的速度，也就是如果今天这个人在编码，那么差不多能出来100行。平均到全生命周期，比如每年，大约是40～50行（这个也偏高，等等说）。我个人在之前说的那个团队的工作中只有一半时间在编程，还有很多时间做别的。一个是数字电视的安全协议构建+IC卡外协之类的工作，另外一个是穿插到别的子团队帮别人做设计（这个可以说是松结对的来源）。
补充：我在2002年左右精确计数了一个项目的开发过程，是一个小瀑布模型，编码期27天日均编码108行，整个周期日均编码46行。两年前开始的火星人项目，编码时的日均编码速度也是100行左右。不过后来有了L型代码结构，编码速度明显下降了，一周可能只编写100～200行代码，多数时间用在界面设计上。这不是说“设计时间长了，编码时间短了”，而是说L型代码结构主要是代码装配过程，效率极高，因此“不太需要长时间编码”。
为何精简的代码速度更高
国外业界有一个说法：无论采用何种语言，编码的速度基本相同。比如如果用汇编，一天100行，那么用C++，也差不多是100行。因此，越高级的语言，越能节省代码。
另外一个则是：越精简的语言，越能节省代码，包括同一种语言。神奇的是，高手用精简的语言编写代码也能一天编写100行；而新手乍看能用1000行烂代码实现相同功能，而且时间也是一天。差别到底是什么呢？
首先，高手和而不同，新手同而不和。
如果10个高手看另外一个高手的100行代码，会说：“恩，差不多，让我做也差不多这个样子”。错误实现的路径很多，正确实现的路径相当有限。即使存在少量多个最佳实现，多数高手在采纳其中一个的同时，也曾经思考过别的方法。10个新手看另外一个新手的1000行代码，就不那么容易了。我们想象中的“冗长但容易理解的代码”，其实是对编写者而言的，旁观者其实很难看懂。我见过一个有44个return总长度550行的函数，最后总算变成110行，只有不到10个return了（多数都在函数开头）；另外一个则是4000行代码65个函数，被改成2个函数，加在一起不到55行。这些情况下，无论高手或新手都会认同后者更容易阅读和理解，实际上连原编写者写完后也有同感。而冗长代码别说新手能不能看懂，高手也得看一阵子才明白。
其次，精简的代码中有正代码，冗长的代码中有负代码。
为了精简代码，难免会用到类、函数、泛型这类封装。这些封装不但现在会用到，未来也会重用，从而大大节省未来的编码量——或者说未来编码速度不会有提高，甚至有下降，但功能产生的速度反而提高了（这正是之前提到的“火星人”中L型代码结构的现状）。除了重用产生的编程速度之外，由于重用的质量高于新代码（有前提但可实现），所以还节省了测试时间。
而冗长代码则有“负代码”。在围棋里边有个术语叫做“负目”，就是如果有一块孤棋，对方可能通过攻击而得利，那么在计算其所围面积的时候，要保守一些甚至减掉一些。冗长代码也是如此。无论是测试、尝试复用、修改需求、修改设计、修改其中的缺陷、转交给他人维护，冗长代码都会在未来产生额外的工作量。
再次，邀请新手向高手靠拢是一种正能量，而要求高手向新手妥协是一种负能量。
这也是本人为何极力推崇松结对编程和139团队的原因，一个团队的最佳状态显然是：编写高质量代码 + 高手帮助新手理解和编写高质量代码。我们当年那个25个人的团队在短短半年左右就差不多做到了这一点，而团队的多数人工作经验都小于4年（本人当时6年，是长的）。
所以不需要也不应该对中间状态有任何幻想和耐心。
关于编码的质量要求与编码速度的关系
感觉结对编程可行（不过推荐松结对），不过重构后的产品的函数、类一定要短、小，嵌套层数可以多一些。这样的好处是以后如果又要重构，多数情况下都不需要动每个函数，只要重构某些即可。
对质量而言，应该高到不会有明显在“改Bug”的时期，应该每个人回忆起来，除了干别的就是编码，很少能记起某段时间在调试Bug。这样编码速度和编码占整个时间的比例就会更高。反正你统计一下就可能发现：高手可以一天100行，平均到一年是50行；而新手可能一天1000行，平均到一年却不是100行，而是更少，因为有很多时间在改Bug。这种状态下，不如让他们跟着高手先精心写好一些代码，再继续前进，否则累死。
