您的位置:首页 > 其它

敏捷开发一千零一问系列之三十三:每天编码多少行?

2013-04-11 10:44 225 查看

这是敏捷开发一千零一问系列的第三十三篇。(在这里提问之一之二之三问题总目录

原问题来自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。这种状态下,不如让他们跟着高手先精心写好一些代码,再继续前进,否则累死。
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: 
相关文章推荐