（转载）敏捷开发一千零一问系列之三十三：天天编码多少行？

（转载） 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。这种状态下，不如让他们跟着高手先精心写好一些代码，再继续前进，不然累死。