Uncle Bob谈软件开发的职业素养之一:敏捷
2009-05-08 19:47
169 查看
Uncle Bob谈软件开发的职业素养之一:敏捷
2009-05-06 来自:java060515 [收藏到我的网摘]
前不久,Uncle Bob 在JAOO上做了一个演讲软件开发的技艺与道德。他在其中提出多项开发软件时应该具备的职业素养(discipline)。 演讲开始,Uncle Bob开宗明义提出:我们这些软件开发人员有一份工作(job:用以谋生),但是却很难称之为职业(Profession:需要特定的教育、培训或技能)。然而,自2000年敏捷运动开展之后,有些职业素养逐渐涌现出来(our craft is defined),使得我们的工作有可能成为一份职业,我们也拥有了变为专业人士的机会。(The Agile approaches depend on discipline, not on documented process。这也与我最近的思考有关,职业素养、纪律和承诺是敏捷潜在的核心,Agile的诸多实践都体现了这一点。改日另文述之。) 下面我将分几个部分来介绍其中提到的discipline。 Short iterations短迭代。敏捷相关的经验告诉我们:软件无法通过long period实现,而是应通过一系列的短迭代开发。Uncle Bob最中意为期一周的迭代,两周也可以接受。4周太长了,会产生很多错误。在迭代结束时,应该交付deployable的软件,而不是deployed的软件,部署与否要由业务来决定。从职业精神(professionalism)的角度来看,交付可以部署的软件,这才是软件开发人员应该做到的事情。Uncle Bob总结:短迭代是构建优秀、牢靠的software profession的basic discipline。 Don't wait for Definition不要等待明确的定义。Uncle Bob指出:也许近几十年来,阻挡我们前进的最大障碍,就是我们总觉得:没有定义,我们就无法向前行进。他问观众:谁曾经让客户在确定的需求上签下带血的签名(sign in blood )?这一点都不公平!!客户一开始并不知道他们到底要什么我们不能等待明确的定义,而是要以编写代码的方式,参与到定义的过程之中。通过best guess来编写软件,再与客户的真实想法进行确认,要想建立靠谱的软件需求,没有比这更好的方式了。产品定义的演化,是随着开发人员与客户一起积极参与需求制定过程完成的。 Abstract away volatility通过抽象隔离变化。这与软件设计和行为相关。隔离变化与不变,并分别置于软件的不同部分,使其互不干扰。比如UI与业务逻辑代码绝对不应放在一起,比如JavaScript。 CommissionOmission动起来,都给我动起来。动手去尝试一些事情,总是胜过坐等现成。如果A组依赖于B组完成某些东西,那么A组不要消极等待,而是应该积极定义B组要提供的东西。Commit!Do not omit. Decouple from others与他人解耦。假设有多个team并行开发,如果你需要等待某个team完成他们的模块,你不要空等他们搞定手上的代码,而是应该将你自己从他们的工作中解耦出来。具体方式:写stub,写mock,写模拟代码。写很多不需要对方就可以运行的代码。这样一来,两个模块之间的接口也就定义好了。通过stub、mock、模拟代码,将自己从软件的层面与他人解耦,而不要被挡在路上(blocked)。 Never be Blocked不要让自己的路被堵死。Uncle Bob称之为最高指导原则(prime directive)。不要让自己的路被堵死,总是应该找到一些方式来让工作取得进展。他曾为某个团队提供咨询服务,那个团队的QA无法执行测试,因为QA的电脑环境没有配置好。可是开发人员的机器都已经配置完成了。Bob大叔告诉QA人员,让他们先用开发人员的某台机器测试,先运行测试用例,即使QA环境没有完全配置好,总是有些测试是可以运行的。 "Never allow yourself get stuck and wait, always find some way out! 该视频在InfoQ上发表,地址是:http://www.infoq.com/presentations/craftmanship-ethics。其他后续部分会根据可用时间慢慢整理。
2009-05-06 来自:java060515 [收藏到我的网摘]
前不久,Uncle Bob 在JAOO上做了一个演讲软件开发的技艺与道德。他在其中提出多项开发软件时应该具备的职业素养(discipline)。 演讲开始,Uncle Bob开宗明义提出:我们这些软件开发人员有一份工作(job:用以谋生),但是却很难称之为职业(Profession:需要特定的教育、培训或技能)。然而,自2000年敏捷运动开展之后,有些职业素养逐渐涌现出来(our craft is defined),使得我们的工作有可能成为一份职业,我们也拥有了变为专业人士的机会。(The Agile approaches depend on discipline, not on documented process。这也与我最近的思考有关,职业素养、纪律和承诺是敏捷潜在的核心,Agile的诸多实践都体现了这一点。改日另文述之。) 下面我将分几个部分来介绍其中提到的discipline。 Short iterations短迭代。敏捷相关的经验告诉我们:软件无法通过long period实现,而是应通过一系列的短迭代开发。Uncle Bob最中意为期一周的迭代,两周也可以接受。4周太长了,会产生很多错误。在迭代结束时,应该交付deployable的软件,而不是deployed的软件,部署与否要由业务来决定。从职业精神(professionalism)的角度来看,交付可以部署的软件,这才是软件开发人员应该做到的事情。Uncle Bob总结:短迭代是构建优秀、牢靠的software profession的basic discipline。 Don't wait for Definition不要等待明确的定义。Uncle Bob指出:也许近几十年来,阻挡我们前进的最大障碍,就是我们总觉得:没有定义,我们就无法向前行进。他问观众:谁曾经让客户在确定的需求上签下带血的签名(sign in blood )?这一点都不公平!!客户一开始并不知道他们到底要什么我们不能等待明确的定义,而是要以编写代码的方式,参与到定义的过程之中。通过best guess来编写软件,再与客户的真实想法进行确认,要想建立靠谱的软件需求,没有比这更好的方式了。产品定义的演化,是随着开发人员与客户一起积极参与需求制定过程完成的。 Abstract away volatility通过抽象隔离变化。这与软件设计和行为相关。隔离变化与不变,并分别置于软件的不同部分,使其互不干扰。比如UI与业务逻辑代码绝对不应放在一起,比如JavaScript。 CommissionOmission动起来,都给我动起来。动手去尝试一些事情,总是胜过坐等现成。如果A组依赖于B组完成某些东西,那么A组不要消极等待,而是应该积极定义B组要提供的东西。Commit!Do not omit. Decouple from others与他人解耦。假设有多个team并行开发,如果你需要等待某个team完成他们的模块,你不要空等他们搞定手上的代码,而是应该将你自己从他们的工作中解耦出来。具体方式:写stub,写mock,写模拟代码。写很多不需要对方就可以运行的代码。这样一来,两个模块之间的接口也就定义好了。通过stub、mock、模拟代码,将自己从软件的层面与他人解耦,而不要被挡在路上(blocked)。 Never be Blocked不要让自己的路被堵死。Uncle Bob称之为最高指导原则(prime directive)。不要让自己的路被堵死,总是应该找到一些方式来让工作取得进展。他曾为某个团队提供咨询服务,那个团队的QA无法执行测试,因为QA的电脑环境没有配置好。可是开发人员的机器都已经配置完成了。Bob大叔告诉QA人员,让他们先用开发人员的某台机器测试,先运行测试用例,即使QA环境没有完全配置好,总是有些测试是可以运行的。 "Never allow yourself get stuck and wait, always find some way out! 该视频在InfoQ上发表,地址是:http://www.infoq.com/presentations/craftmanship-ethics。其他后续部分会根据可用时间慢慢整理。
相关文章推荐
- Uncle Bob谈软件开发的职业素养之一:敏捷
- Uncle Bob谈软件开发的职业素养之一
- 程序员的职业素养(世界级软件开发大师Robert C. Martin谈职业素养)
- 好用的敏捷开发软件推荐
- 软件开发模式对比(瀑布、迭代、螺旋、敏捷)
- Visual Studio Team Architect 团队的敏捷软件开发(第一部分)
- 以亲身经历解读敏捷软件开发(一)什么是敏捷软件开发
- 敏捷开发总结(1)软件研发过程
- 对软件开发有利的5个敏捷编程方法
- 单一职责原则(SRP)------《敏捷软件开发:原则、模式与实践》 (二)
- 敏捷软件开发(1)--- STATE 模式
- 软件开发过程纵横谈(2):敏捷过程课程小记
- 软件开发模式对比(瀑布、迭代、螺旋、敏捷)
- [原创] 敏捷软件开发管理实践 (一) ——让人的资源多起来
- 对敏捷软件开发方法的一些体会(转贴)
- 敏捷软件开发宣言和原则
- 敏捷软件开发图书概览
- 敏捷软件开发宣言及原则
- 推荐书籍系列(2):敏捷软件开发――原则、模式与实践
- 软件开发方法--敏捷软件开发