敏捷咨询工具箱(钱安川)

《敏捷咨询工具箱(钱安川)》由会员分享，可在线阅读，更多相关《敏捷咨询工具箱(钱安川)（13页珍藏版）》请在金锄头文库上搜索。

1、目录一作者简介二敏捷咨询工具箱（一）读书写代码活动三敏捷咨询工具箱（二）目录一作者简介二敏捷咨询工具箱（一）读书写代码活动三敏捷咨询工具箱（二）OO训练营四敏捷咨询工具箱（三）结对辅导说明：训练营四敏捷咨询工具箱（三）结对辅导说明：本文是对发于 InfoQ 中文站的敏捷工具箱的一个总结及整理 ，版权 InfoQ 中文站所有，如需转载，请务必附带本声明，谢谢。InfoQ 中文站 是一个面向中高端技术人员的在线独立社区，为 Java、.NET、Ruby、SOA、敏捷、架构等领域提供及时而有深度的资讯、高端技术大会如 QCon 、免费迷你书下载如架构师 等。作者简介：作者简介：钱安川，Thought

2、Works 公司高级软件咨询师、敏捷过程教练、资深讲师、TeamLeader、开发者、 BeiJing Open Party 组织者和主持人。个人博客：敏捷开发训练：http:/ 遇到一些开发技术很薄弱的团队， 大部分人只会通过复制和粘贴的方式写代码，然后花费大量的时间进行修改和调试。有些开发人员还只是刚刚从学校毕业，几乎没有什么开发经验。 面对这样的团队， 如何教他们使用敏捷开发方法？如何教他们测试驱动开发？如何教他们简单设计呢？如果连一门语言还没有完全吃透，还如何谈测试驱动开发和简单设计呢？这是一个很大的挑战。我回想起自己学习新语言的方法。前些时间我自学了 SCALA 语言，看完了Scal

3、a 程序设计：Java 虚拟机多核编程实战 ，但还是觉得很多概念没有吃透，然后我就把书合上，然后把书上所有的例子独立写了一遍， 这时才能感觉自己是学了一门语言。 于是我用同样的方法来训练这个团队：一、找一本合适的书。一、找一本合适的书。如果要快速吃透一门语言，最快的方法就是找一本好书，系统的把一门语言学习一遍，扫除语言的盲点。我们如何选择一本合适的书呢，我总结了三个条件：选择国外大师的权威著作，这些大师应该有深厚的开发经验，这样可以从书上学到很多编程和设计的最佳实践。书不能太厚，最好在200-300页左右，足够介绍完一门语言的常用特性和最佳实践。 那些面面俱到的的厚砖头一般适合做参考手册。书上

4、的例子一定要经典，这样比较适合练习。因为团队主要使用 C 语言， 我就在 Google 上搜索了一下“C 书籍推荐”， 找到了很多网友推荐的Top C 语言书籍。通过我几天的阅读和筛选比较之后，最后我为大家选择了C 程序设计语言这本书，完全符合上面的三个条件。如果你是使用的其它编程语言，可以参考下面的读书列表：如果你用的是 C+,我推荐Essential C+中文版如果你用的是 Ruby，我推荐Everyday Scripting with Ruby 中文版如果你用的是 Java，我推荐Agile Java 中文版：测试驱动开发的编程技术如果你用的是 SCALA，我推荐Scala 程序设计：J

5、ava 虚拟机多核编程实战二、具体的读书计划二、具体的读书计划选择书之后，就要有一个具体可行的读书计划，这样大家能有节奏的一步一步把书读完。因为大家都有一些语言基础，所以我们把读书活动安排为每天的家庭作业，每周读完章。我们的验收标准是：在不看书的情况下用 TDD 实现每章全部的例题（这个后面会有详细的介绍） 。下面是我给大家制定的读书计划：时间内容第一周第1章 导言第2章 类型、运算符与表达式第二周第3章 控制流第4章 函数与程序结构第三周第5章 指针与数组第6章 结构第四周第7章 输入与输出第8章 unix 系统接口三、光看不练假把式三、光看不练假把式有了书，有了读书计划，当然这个还不够。这

6、个活动的重点就是要写代码。这是读书写代码活动的验收条件。要求每个人在不看书的情况下，把书上的例题改造成测试驱动的代码。一章所有例题都改造完了，才算是把这章读完。比如：Hello World 的例子#includemain()printf(“hello, worldn“);要求把这个例子改造成测试驱动的代码。改造之后代码分别为：测试代码：TEST(test_case_name, test_greetings) EXPECT_EQ(“hello, world“, greetings();业务代码：char greetings()return (“hello, world“);通过这样的训练，每个人

7、不但可以系统的学习一遍 C 语言的知识，并且可以锻炼如何用 TDD 进行开发。四、闭环四、闭环代码展示代码展示如何保证每个人可以完成写代码活动并且达到预期的效果呢？我们搭建了一个 Subversion，让每人把自己的代码提交上去。我们每天早上会有一个代码展示活动。准备一个投影仪，每个人花3-5分钟展示和讲解自己的代码，然后集体鼓掌表示认可，然后其他的同事提出问题和改进建议。这样有三个好处：让每人分享自己的代码和经验，这是对每人的认可和鼓励一个互相学习的氛围; 通过展示可以学习一下其他同事是怎么写代码，怎么写测试互相督促，如果没有完成代码，这时候就没有任何东西可以展示了我们坚持了一个月之后，这个

8、活动结束了。每个人都感觉很好，系统的把 C 语言掌握了一遍。一些有经验的一个开发人员也觉得，系统的学习之后消除了 C 语言的很多盲点。现在对 C 语言编程更有信心了，并且还学会了如何做 TDD 开发。补充：一些评论不错不错2010年12月22日 下午5时11分 发表人 JinianJinian XieXie我们也在尝试类似的活动，接下来会跟着作者的方法再细化一下。授人以渔授人以渔2010年12月22日 下午9时12分 发表人 曹曹 云飞云飞授人以鱼，不如授人以渔。谢谢作者授人以渔，受益匪浅。有利有弊有利有弊2010年12月25日 上午8时11分 发表人 WhiteWhite PelePele如

9、果上面的方法是一个至少有过一两门实战开发经验的中高级程序员，的确是个快速掌握新语言的办法。但是，对于刚毕业的新手，容易出现类似从书里或者网上 copy paste 来做课后例题的事情。即使他们是认真做了这些题目，也只会对语言一知半解，会觉得一门程序语言，写代码不过如此。曾经我见过一个刚毕业不久的同学，告诉他需要对数据库处理添加事务。okey，半天后说加好了，一看，每条数据库操作前后都加上了 transaction，呵呵。学习之方法学习之方法2010年12月29日 上午4时27分 发表人 jiangjiang yanyan在学校就没有学好如何学习的人，入职后要重新学习。如果能主动的学习，又何必要

10、被人逼着来读书写代码呢。敏捷咨询工具箱（二）敏捷咨询工具箱（二）OO训练营犯错误是最好的学习方式训练营犯错误是最好的学习方式莎伦莎伦德雷珀德雷珀背景背景我们为客户提供咨询，刚开始做了很多敏捷的实践，包括：持续集成、测试驱动、用户故事需求分析、迭代开发等等之后，发现如果再想深入下去，就会面临一些“硬骨头”：遗留系统和开发设计能力的问题。在一些客户那里，他们产品有10多年了，但是很少有人新加程序文件，写代码习惯于复制粘贴，都是在已有的类和函数上修修补补。团队缺少追求好代码的品质和能力，到处是大函数，上帝类（超大类，任何功能变化都要修改此类） ，重复代码，混乱逻辑，开发和维护成本太高。作为一个顾问，

11、如何才能从根本解决这样的开发设计能力问题呢？在 ThoughtWorks ， 如 果招 聘 了一 个 没有 经 验的 开 发人 员 ，会 把 他们 送 到印 度 的TWU(ThoughtWorks University)培养2-6个月，OO 训练营是开发人员的主要课程之一。它专门用来训练开发人员如何使用面向对象，如何进行测试驱动开发。通过这样的训练之后， 开发人员可以很快的掌握面向对象开发和简单设计能力，养成追求好代码的品质。所以，我们也为客户的团队引入了 TWU 的 OO 训练营活动。活动方式活动方式OO 训练营的培训方式和我们传统的“填鸭式”教育完全相反。它采用的是苏格拉底式教学法，顾问不

12、会给你任何标准答案，而是通过问题的引导，让学员自己一步一步找到最佳的解决方案。 我的 OO 训练营的组织方式一般是：一、顾问提出需求一、顾问提出需求顾问在训练营活动会扮演着客户的角色。活动一开始的时候，会以客户的身份提出一个需求， 让大家去完成。例如：要求建模一个长方形。二、简单设计二、简单设计以分组讨论方式做一个简单设计，一般从如下三个方面进行设计。类名是什么？类的职责是什么？对于复杂需求，可能会要求画一个简洁的 UML 对象关系图。类的测试用例会有哪些，并且找到第一个测试用例讨论结束之后，每组介绍一下各自的讨论结果。通过分组讨论和顾问的引导，对建模一个长方形需求一般会得到如下的设计结果：类

13、名是: Rectangle类的职责是计算周长和面积计算周长的测试用例：oa. 正常场景。如果长是2，宽是3，那么周长是10ob. 异常场景，宽为0的情况。如果长是2，宽是0，那么应该抛出异常oc. 异常场景，宽为负数的情况。如果长是2，宽是-3，那么应该抛出异常这些测试用例完全是由学员自己设计出来的，没有标准答案。作为顾问只是引导大家，让每组的测试用例更具体和全面。 假设没有一组学员没有考虑到异常情况的测试用例， 这时也也不用指出来，等后面代码展示的时候，再指出这个问题，因为犯错是最好的学习方式。三、测试驱动（TDD）开发三、测试驱动（TDD）开发学员根据设计和讨论的结果，用测试驱动的方式进行

14、结对编码开发。要求先写单元测试，写完一个单元测试之后，运行测试失败，然后再去写业务代码。如果没有失败的测试，不允许写一行业务代码。这样严格的要求，让大家养成测试驱动开发的好习惯。两个人一组使用结对方式进行开发，要求使用乒乓式的结对方法。假设是 A 和 B 进行结对开发，A 先写一个测试用例，编译通过但是测试失败。然后把键盘和鼠标交给 B，B 写业务代码，让测试通过，然后为 A 再写一个失败的测试。通过这种乒乓的方式，一个人写测试用例，一个人实现业务代码，并且不停的变换角色。这样两个人可以很好的进行配合，互相给对方出“难题”， 一个人在写实现的时候，另一个人会思考下一个测试用例会是什么。有的时候

15、，我们会对团队提出一些更高的要求。比如编程过程中不允许使用鼠标，一切都是快捷键操作，这样能提高开发的效率。编程过程中不允许使用复制和粘贴功能，如果是相同的功能或者代码，第一应该考虑到的是如何进行功能重用，而不是复制一遍，这样可以杜绝这样错误的编程习惯。四、代码展示和顾问点评四、代码展示和顾问点评写完代码之后， 每个人开始展示自己的代码。 这时， 顾问就开始从代码里面寻找代码坏味道(Badsmell)，告诉大家什么样的是好代码，什么样的是坏代码。坏代码会有哪些危害，让后让大家重构。例如：在实现长方形周长的时候，有人实现了 getLength 了 getWidth 方法，把长方形的长和宽的数据暴露

16、出来了。那么这就是一个代码坏味道（Bad smell） ，顾问会指出这个问题， 告诉大家面向对象最重要的一个特征是封装， 不应该把数据直接暴露出来。 因为数据暴露出来之后，一方面造成数据的依赖和耦合， 另一方面其它代码在调用长方形这个对象的时候， 也许会拿到长和宽的数据自己进行运算，这样就破坏了封装，对象之间耦合增大，并且容易产生重复的代码。然后提问大家，正确的做法应该是什么？答案应该会是长方形不应该把长和宽的数据暴露出来， 所有长方形相关的运算和逻辑都应该在长方形这个领域对象里面进行。这也正是面向对象设计的一个重要原则：Tell dont ask 的体现。通过这样的引导的方式，带领大家一步一步找到正确的面向对象设计方法和原则，同时纠正那些错误的编码和设计习惯。每次活动就是类似