- 浏览: 317429 次
- 性别:
- 来自: 北京
文章分类
- 全部博客 (262)
- Java (20)
- 设计模式 (16)
- Oracle (13)
- Struts (1)
- 问题解决 (9)
- ibatis (2)
- Maven (5)
- Git (2)
- 实现原理 (6)
- 敏捷开发 (22)
- Spring (4)
- 算法 (8)
- MySQL (2)
- Java工具箱 (17)
- jQuery (1)
- 英语学习 (8)
- 杂谈 (15)
- 多线程 (15)
- Java解惑 (7)
- Linux (1)
- 重构36计 (6)
- 网络 (4)
- PHP (1)
- Socket (6)
- 面试 (1)
- JVM (14)
- 历史与故事 (5)
- 报表 (4)
- CMS (3)
- Windows (1)
- nginx (5)
- 架构设计 (7)
- RubyOnRails (2)
- Hadoop (8)
- Go (7)
- JS (1)
- Web (1)
- 项目实例 (5)
- ubuntu (4)
最新评论
-
jacking124:
按照你这个配置以后提示这个异常?Exception occur ...
Go语言学习:开发环境搭建及Hello World -
焦志广:
有请看http://jiaozhiguang-126-com. ...
Hadoop白皮书(1):分布式文件系统HDFS简介 -
w156445045:
Hadoop 有没windows环境下的配置呢,
谢谢。非常感 ...
Hadoop白皮书(1):分布式文件系统HDFS简介 -
xiangxm:
学习了。
Java 解惑知多少六 -
焦志广:
<div class="quote_title ...
易学设计模式四 命令模式(Commond)
松结对和紧结对不一样,两个人不是总坐在一起随时发现问题解决问题,而是很短时间地坐在一起。其中在后检查点发生的主要事情有两个:一是看结果是否符合需求(做什么),而是看代码是否存在问题(怎么做),后者就是代码检查。
代码检查(也称代码审查Code Inspection)是一种由来已久但是很神秘的东西,最初引入是在一些生命攸关、重大财产相关的软件开发中,典型的就是SSOS(美国航天飞机的软件),其每段代码都交由6个人审阅,方可入库。成果就是在1989年之前(之后笔者没有数据),SSOS在太空中失效次数只有一次。笔者亲身参与的代码审查活动包括某数字电视CA系统的代码审查(25个程序员只有1个测试,已用于CCTV)、某电信计费系统的代码审查(一周发现2400个缺陷)、某电信运维系统的审查(2天发现200个重要缺陷,其中1个已困扰团队5年)、某航空无损检测系统的代码审查(交付后一年内客户只发生一次失效)。
代码检查的基本原理就是相信人脑(而非人眼)是判断代码好坏的最好工具,比如如果代码中有一行:if (i == 1001) return die()的错误或非法代码,几乎无法经由测试包括自动测试发现,但肉眼却一目了然。
笔者曾编写过一个“复杂而彻底”的代码检查培训教材,但后来发现过于复杂而且还不彻底,所以作罢。下面将要介绍的是一种业余但却有效的代码审查方法。
-----------------------------------------------------------------------
程序员的质量观
有人曾把程序员分为四级:编写可用软件(大致是大学在校生的状态),编写可靠软件(大致是好一些的职业程序员的状态),编写精美软件(在简单性/可维护性/可复用性上有所突破),编写思想深邃软件(设计模式、MVC、JQuery及早期OLE、RPC等创始者所做的事情)。
但在现实中,却往往发现很多程序员停留在第一层次:“你测吧,测出缺陷来我改”“这个不用改也能运行”“这么编就是难读点而已”,师徒间的代码检查,就是把程序员从第一级别向上提高的过程。
第一段提到的25个程序员+1个测试人员的团队是01年我们所在的团队,当时保持了良好的质量风气。尤其由于大家知道没有测试人员擦屁股,留下缺陷相当于给自己找麻烦,所以大家不得不习惯自己动手防患于未然。这个产品后来发展势头很好,07年曾占据市场60%(之后不详)。
怎样检查
“高手本来自己就要开发很多代码,还要替新手检查代码,多花费时间啊……”这是一个常见问题,答案是:“每天,在后检查点,花费不超过15分钟时间,能看出什么来就说什么,时间到了就停。”
一般而言,大致每天高手能编写100多行有效代码(按分号计数),新手会多一些但也不超过200(他们编写代码比较费),也就是10个屏幕以内。有经验的人一定知道:高手看新手的软件,5秒钟就能发现问题。
常存在的一种情况是高手“看不懂”新手的代码,当然不是因为技术太精妙了,而是写得太乱了。但在松结对编程里边不存在,由于师傅徒弟天天在一起,这200行代码可谓一目十行,如果以往一直每天检查代码,那么里边存在的问题应该不会很多。
检查什么
这个是重点,整体包括:
1. 结构问题
代码最大的问题,不是一两个地方有技术缺陷,也不是业务逻辑错误,而是整个软件编写的不好。前两者都可以通过测试或使用来发现和更正,但后者就不同了。如果回想一下自己见过的各种烂摊子,是不是有同感?具体哪里有问题怎么改说不上来,就是整个软件看上去混乱无章,无从下手。
具体结构问题包括:重复拷贝代码(不封装函数,不用Template/泛型……),函数过长(超过一屏幕就叫过长),错误封装(不恰当的public/不用Interface/不内聚/强耦合/在类中封装了无关方法……),内容错误(多个无关类置于一个文件/不恰当的命名……)等等。
改正结构问题,是从编写可靠软件向编写精美软件迈进的重要方法。
(笔者博客中已经写了几个“编码简单性”的文章可供参考)
2. 业务逻辑问题
就是软件是否与需求的要求符合的问题。师傅和徒弟经常对业务需求的理解有差异,借此机会同步一下,必要时引入PO(产品经理/策划人员……)。
有人会说业务逻辑问题不是一测试就知道了吗?可是测试一般发生在很久以后,有些逻辑测试还需要一定的触发条件,而且测试只会发现失效(failure, 与预期不符)而不能发现缺陷(defect, 具体哪里出了错),等积累长了,谁也找不到原因了。
3. 编程素养问题
很多问题属于那种“这样也行那样也行”的状态,比如命名/初始值/缩进/断行……但是高手的做法总是比新手好一些。
比如bool result = true; 这句话就有问题,刚初始化就先宣布成功,必有隐患。这是一个真实案例,而下面也的确有一个分支错误地返回了这个true(实际案例是个HRESULT)。而发现这个问题,不是测试而是代码检查。实际上测试几乎发现不了这些问题,比如上面那段代码会在某文件打不开的时候错误地返回这个true,而在测试中几乎不会故事破坏那个文件来测试其结果。
实际使用时,不用拉太长的清单,师傅能想到的看到的告诉徒弟就行。
徒弟不需要学到天上去,只要能学到师傅那么好就可以了。之前在做CMMI咨询的时候我弄过一些检查表,推广均以失败而告终。那些表都是为了顶级安全性的软件考虑的,在普通项目里边使用是个灾难。
几个问题
1. 师傅天天检查,会不会很累?
检查不全是为了发现缺陷,而是为了提高成长。如果总是发现重复问题,此徒不可教。好学的徒弟有半年时间就能接近师傅了,考虑到师傅一般比徒弟多工作2年,我们因此让一个人加速1.5年。
2. 不会饿死师傅吗?
会,也不会。如果师傅止步不前,即使他不教别人,也迟早被人超越;师傅也是需要学习的。事实是会教徒弟的师傅才会学习,而会学习的师傅才会教徒弟。
3. 师傅跟谁学?
师徒制度是最底层团队制度(1个师傅+1~3个徒弟左右),其上还有更大的结构和更高的高手。我们之前曾把人员层次设为需指导的(徒弟)/可免于指导的(也是徒弟)/可提供指导的(师傅)/可培训的(团队最高级别的高手),最后一级需要定期与大家分享内容。
师傅作为高级技术人员,还享有机会外出培训/采购图书等待遇。
师傅自学也很重要,经验更是不可取代的。前事不忘后事之师,要把自己的经历和别人的经历都当作经验来看待。
4. 师傅努力编好自己的软件不久已经有很大贡献了,为何要帮助徒弟?
软件整体是一个串联系统,一个环节出了问题整个软件崩溃(Web软件好一些)。因此软件质量取决于最差的部分,而不是最好的部分。
代码审查的确会占用时间导致最好的部分变差,但却使最差的地方变得好得多,整体质量因此而得以提高。
------------------------------------------------------------
从工作层面讲,代码检查使得代码的质量尤其是结构质量,整体上保持在师傅可能达到的水平,从而保证了项目的成功。
从学习层面讲,代码检查使得徒弟可以不断/渐进地学习,从而花费远远低于师傅的时间成本达到更高层次。
心态是其中的关键。徒弟不能因此而觉得有一个后盾了可以放任存在问题等师傅发现,要珍惜师傅的时间,也要利用师傅的时间每次都学不同的内容;师傅也不能觉得徒弟学会了对自己是个威胁,威胁时刻都在,不来自于自己的徒弟,也会来自于别人的徒弟,唯有自我提高。
至此所有实践层面的内容基本上都写完了,下一篇将提到一些“139团队”的问题,所谓“139团队”就是一个使用松结对编程工作方式的大型团队。
ref:http://blog.csdn.net/cheny_com/article/details/6594507
代码检查(也称代码审查Code Inspection)是一种由来已久但是很神秘的东西,最初引入是在一些生命攸关、重大财产相关的软件开发中,典型的就是SSOS(美国航天飞机的软件),其每段代码都交由6个人审阅,方可入库。成果就是在1989年之前(之后笔者没有数据),SSOS在太空中失效次数只有一次。笔者亲身参与的代码审查活动包括某数字电视CA系统的代码审查(25个程序员只有1个测试,已用于CCTV)、某电信计费系统的代码审查(一周发现2400个缺陷)、某电信运维系统的审查(2天发现200个重要缺陷,其中1个已困扰团队5年)、某航空无损检测系统的代码审查(交付后一年内客户只发生一次失效)。
代码检查的基本原理就是相信人脑(而非人眼)是判断代码好坏的最好工具,比如如果代码中有一行:if (i == 1001) return die()的错误或非法代码,几乎无法经由测试包括自动测试发现,但肉眼却一目了然。
笔者曾编写过一个“复杂而彻底”的代码检查培训教材,但后来发现过于复杂而且还不彻底,所以作罢。下面将要介绍的是一种业余但却有效的代码审查方法。
-----------------------------------------------------------------------
程序员的质量观
有人曾把程序员分为四级:编写可用软件(大致是大学在校生的状态),编写可靠软件(大致是好一些的职业程序员的状态),编写精美软件(在简单性/可维护性/可复用性上有所突破),编写思想深邃软件(设计模式、MVC、JQuery及早期OLE、RPC等创始者所做的事情)。
但在现实中,却往往发现很多程序员停留在第一层次:“你测吧,测出缺陷来我改”“这个不用改也能运行”“这么编就是难读点而已”,师徒间的代码检查,就是把程序员从第一级别向上提高的过程。
第一段提到的25个程序员+1个测试人员的团队是01年我们所在的团队,当时保持了良好的质量风气。尤其由于大家知道没有测试人员擦屁股,留下缺陷相当于给自己找麻烦,所以大家不得不习惯自己动手防患于未然。这个产品后来发展势头很好,07年曾占据市场60%(之后不详)。
怎样检查
“高手本来自己就要开发很多代码,还要替新手检查代码,多花费时间啊……”这是一个常见问题,答案是:“每天,在后检查点,花费不超过15分钟时间,能看出什么来就说什么,时间到了就停。”
一般而言,大致每天高手能编写100多行有效代码(按分号计数),新手会多一些但也不超过200(他们编写代码比较费),也就是10个屏幕以内。有经验的人一定知道:高手看新手的软件,5秒钟就能发现问题。
常存在的一种情况是高手“看不懂”新手的代码,当然不是因为技术太精妙了,而是写得太乱了。但在松结对编程里边不存在,由于师傅徒弟天天在一起,这200行代码可谓一目十行,如果以往一直每天检查代码,那么里边存在的问题应该不会很多。
检查什么
这个是重点,整体包括:
1. 结构问题
代码最大的问题,不是一两个地方有技术缺陷,也不是业务逻辑错误,而是整个软件编写的不好。前两者都可以通过测试或使用来发现和更正,但后者就不同了。如果回想一下自己见过的各种烂摊子,是不是有同感?具体哪里有问题怎么改说不上来,就是整个软件看上去混乱无章,无从下手。
具体结构问题包括:重复拷贝代码(不封装函数,不用Template/泛型……),函数过长(超过一屏幕就叫过长),错误封装(不恰当的public/不用Interface/不内聚/强耦合/在类中封装了无关方法……),内容错误(多个无关类置于一个文件/不恰当的命名……)等等。
改正结构问题,是从编写可靠软件向编写精美软件迈进的重要方法。
(笔者博客中已经写了几个“编码简单性”的文章可供参考)
2. 业务逻辑问题
就是软件是否与需求的要求符合的问题。师傅和徒弟经常对业务需求的理解有差异,借此机会同步一下,必要时引入PO(产品经理/策划人员……)。
有人会说业务逻辑问题不是一测试就知道了吗?可是测试一般发生在很久以后,有些逻辑测试还需要一定的触发条件,而且测试只会发现失效(failure, 与预期不符)而不能发现缺陷(defect, 具体哪里出了错),等积累长了,谁也找不到原因了。
3. 编程素养问题
很多问题属于那种“这样也行那样也行”的状态,比如命名/初始值/缩进/断行……但是高手的做法总是比新手好一些。
比如bool result = true; 这句话就有问题,刚初始化就先宣布成功,必有隐患。这是一个真实案例,而下面也的确有一个分支错误地返回了这个true(实际案例是个HRESULT)。而发现这个问题,不是测试而是代码检查。实际上测试几乎发现不了这些问题,比如上面那段代码会在某文件打不开的时候错误地返回这个true,而在测试中几乎不会故事破坏那个文件来测试其结果。
实际使用时,不用拉太长的清单,师傅能想到的看到的告诉徒弟就行。
徒弟不需要学到天上去,只要能学到师傅那么好就可以了。之前在做CMMI咨询的时候我弄过一些检查表,推广均以失败而告终。那些表都是为了顶级安全性的软件考虑的,在普通项目里边使用是个灾难。
几个问题
1. 师傅天天检查,会不会很累?
检查不全是为了发现缺陷,而是为了提高成长。如果总是发现重复问题,此徒不可教。好学的徒弟有半年时间就能接近师傅了,考虑到师傅一般比徒弟多工作2年,我们因此让一个人加速1.5年。
2. 不会饿死师傅吗?
会,也不会。如果师傅止步不前,即使他不教别人,也迟早被人超越;师傅也是需要学习的。事实是会教徒弟的师傅才会学习,而会学习的师傅才会教徒弟。
3. 师傅跟谁学?
师徒制度是最底层团队制度(1个师傅+1~3个徒弟左右),其上还有更大的结构和更高的高手。我们之前曾把人员层次设为需指导的(徒弟)/可免于指导的(也是徒弟)/可提供指导的(师傅)/可培训的(团队最高级别的高手),最后一级需要定期与大家分享内容。
师傅作为高级技术人员,还享有机会外出培训/采购图书等待遇。
师傅自学也很重要,经验更是不可取代的。前事不忘后事之师,要把自己的经历和别人的经历都当作经验来看待。
4. 师傅努力编好自己的软件不久已经有很大贡献了,为何要帮助徒弟?
软件整体是一个串联系统,一个环节出了问题整个软件崩溃(Web软件好一些)。因此软件质量取决于最差的部分,而不是最好的部分。
代码审查的确会占用时间导致最好的部分变差,但却使最差的地方变得好得多,整体质量因此而得以提高。
------------------------------------------------------------
从工作层面讲,代码检查使得代码的质量尤其是结构质量,整体上保持在师傅可能达到的水平,从而保证了项目的成功。
从学习层面讲,代码检查使得徒弟可以不断/渐进地学习,从而花费远远低于师傅的时间成本达到更高层次。
心态是其中的关键。徒弟不能因此而觉得有一个后盾了可以放任存在问题等师傅发现,要珍惜师傅的时间,也要利用师傅的时间每次都学不同的内容;师傅也不能觉得徒弟学会了对自己是个威胁,威胁时刻都在,不来自于自己的徒弟,也会来自于别人的徒弟,唯有自我提高。
至此所有实践层面的内容基本上都写完了,下一篇将提到一些“139团队”的问题,所谓“139团队”就是一个使用松结对编程工作方式的大型团队。
ref:http://blog.csdn.net/cheny_com/article/details/6594507
发表评论
-
测试驱动开发
2012-11-11 14:21 0测试驱动开发的一般流 ... -
Kent Beck : 领导的敏捷潮
2012-10-15 10:29 923Beck全家似乎都弥漫着技术的味道。生长在硅谷, 有着一个对无 ... -
什么是敏捷(下)(无住,不住于空,破空执,非法,非非法)
2012-10-09 14:23 903破除法执之后,很容易 ... -
什么是敏捷(上)(无住,不住于法,破法执)
2012-10-09 14:20 993所谓无住,包括两个含义:不住于法,不住于空。前者比较好理解, ... -
敏捷开发与本能反应
2012-10-09 14:12 743经常听到有人提到敏捷开发与“本能反应”非常近似,比如凡事都需 ... -
敏捷的未来会怎样?
2012-10-09 13:49 343正法,像法,末法 任 ... -
敏捷开发之大型团队切分
2012-10-09 11:00 1036大型团队的切分 如果 ... -
敏捷开发加班吗?
2012-10-08 17:43 1666问题 敏捷开发加班吗? 楼下有人问到“敏捷和加班有什么关系 ... -
敏捷适合什么类型项目?
2012-10-08 16:44 1409问题 原来问题是这么写的:“一家企业既要过CMMI,又要过I ... -
敏捷开发智慧之:定不定流程和模板?
2012-10-08 15:45 892缘起 (立项时) 甲:“你们的设计文档打算怎么写?” 乙 ... -
敏捷开发智慧之写不写文档?
2012-10-08 15:17 677缘起 “我们产品已经做完了,客户说要补上需求文档,可我们只有 ... -
敏捷开发松结对编程之七问题集锦
2012-10-05 19:06 831人员与结构 在团队中使用层级结构,是否阻碍了个体与外界的沟通 ... -
敏捷开发松结对编程之四日常管理
2012-10-05 18:16 735团队中常见的一种情况 ... -
敏捷开发松结对编程之三共同估算
2012-10-05 14:58 787估算是经久不衰的管理 ... -
敏捷开发松结对编程之二计划设计
2012-10-03 22:30 720新人其实很少偷懒,因 ... -
敏捷开发松结对编程之一人员结构
2012-10-03 12:11 781传说中的结对编程,大致结构是两个人共用一台电脑,一个开发,一 ... -
敏捷开发心法之共振
2012-10-03 11:42 669共振 共振是以无我、 ... -
敏捷开发心法之无住
2012-10-03 11:33 804无住 在般若敏捷系列 ... -
敏捷开发心法之无我
2012-10-02 21:54 636做敏捷开发时间长了, ... -
敏捷开发松结对编程之六大型团队
2012-09-28 16:49 757松结对编程是小型团队 ...
相关推荐
结对编程——敏捷开发.pdf
2011-10-12在微软tech ed大会上的讲稿
结对编程开发人员之间若干关系问题的探讨,王鹏生,,本文介绍了敏捷软件开发方法XP中关键实践之结对编程在实践中的应用,并指出了结对双方在人员关系问题上的若干问题,给出处理的参�
这本综合性、实用性的敏捷开发和极限编程方面的指南,是由敏捷开发的创始人之一所撰写的。 ·讲述在预算和实践要求下,软件开发人员和项目经理如何使用敏捷开发完成项目。 ·使用真实案例讲解如何用极限编程来...
交换编程-结对编程的延伸实践 交换编程-结对编程的延伸实践
介绍分布式结对编程技术和组织策略、存在问题和实验研究
, 本书为敏捷的计划、开发、交付和管理提供了严谨的建议,这些建议来自于作者多年的极限编程(Extreme Programming,XP)经验。你将看到敏捷开发过程的全景图,包括为非技术类读者准备的全面指导,以及为开发者和测试...
是软件工程中结对编程与应用的描述与实现方法
2020级计算机系软件工程第二次结对编程作业.zip 2020级计算机系软件工程第二次结对编程作业.zip 2020级计算机系软件工程第二次结对编程作业.zip 2020级计算机系软件工程第二次结对编程作业.zip 2020级计算机系软件...
在开发软件项目时,不仅写出相应功能的模块很重要;确保写出的模块的易维护性(bug 修复,代码重构)也同样重要。 主打互联网技术和门户...为了避免这种情况发生,他们决定在开发复杂模块时试验性地使用结对编程。
原则模式与实践》是综合性、实用性的敏捷开发和极限编程方面的指南,讲述了在预算和时间要求下软件开发人员和项目经理如何使用敏捷开发完成项目:使用真实案例讲解如何用极限编程来设计、测试、重构和结对编程;...
这本综合性、实用性的敏捷开发和极限编程方面的指南,是由敏捷开发的创始人之一所撰写的。 [b][font color="#ff6600"]特色内容: ●讲述在预算和时间要求下,软件开发人员和项目经理如何使用敏捷开发完成项目。 ●...
这本综合性、实用性的敏捷开发和极限编程方面的指南,是由敏捷开发的创始人之一所撰写的。1.讲述在预算和实践要求下,软件开发人员和项目经理如何使用敏捷开发完成项目;2.使用真实案例讲解如何用极限编程来设计、...
XP实践demo for http://blog.csdn.net/nomad2
这本综合性、实用性的敏捷开发和极限编程方面的指南,是由敏捷开发的创始人之一所撰写的。 ·讲述在预算和实践要求下,软件开发人员和项目经理如何使用敏捷开发完成项目。 ·使用真实案例讲解如何用极限编程...
我的第一次Pair(PairProgramming的简称,即结对编程。后面都是用Pair代替)是在ThoughtWorks公司面试进行的。那次,他们来自英国的项目经理Andy面试我,和我一起进行Pair。Andy问我以前是否Pair过,我说:“没有,...
结对编程
这本综合性、实用性的敏捷开发和极限编程方面的指南,是由敏捷开发的创始人之一所撰写的。1.讲述在预算和实践要求下,软件开发人员和项目经理如何使用敏捷开发完成项目;2.使用真实案例讲解如何用极限编程来设计、...
这本综合性、实用性的敏捷开发和极限编程方面的指南,是由敏捷开发的创始人之一所撰写的。 讲述在预算和时间要求下,软件开发人员和项目经理如何使用敏捷开发完成项目; 使用真实案例讲解如何用极限编程来设计、测试...