Uncle Bob谈软件开发的职业素养之一

转载自：http://news.csdn.net/a/20090505/210881.html

 

前不久，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。

1. Short iterations短迭代。 敏捷相关的经验告诉我们：软件无法通过long period实现，而是应通过一系列的短迭代开发。Uncle Bob最中意为期一周的迭代，两周也可以接受。4周太长了，会产生很多错误。在迭代结束时，应该交付deployable的软件，而不是deployed 的软件，部署与否要由业务来决定。从职业精神（professionalism）的角度来看，交付可以部署的软件，这才是软件开发人员应该做到的事情。 Uncle Bob总结：短迭代是构建优秀、牢靠的software profession的basic discipline。
2. Don't wait for Definition不要等待明确的定义。 Uncle Bob指出：也许近几十年来，阻挡我们前进的最大障碍，就是我们总觉得：没有定义，我们就无法向前行进。他问观众：谁曾经让客户在确定的需求上签下带血的 签名（sign in blood ）？这一点都不公平！！客户一开始并不知道他们到底要什么我们不能等待明确的定义，而是要以编写代码的方式，参与到定义的过程之中。通过best guess来编写软件，再与客户的真实想法进行确认，要想建立靠谱的软件需求，没有比这更好的方式了。产品定义的演化，是随着开发人员与客户一起积极参与 需求制定过程完成的。
3. Abstract away volatility通过抽象隔离变化。 这与软件设计和行为相关。隔离变化与不变，并分别置于软件的不同部分，使其互不干扰。比如UI与业务逻辑代码绝对不应放在一起，比如JavaScript。
4. CommissionOmission动起来，都给我动起来。 动手去尝试一些事情，总是胜过坐等现成。如果A组依赖于B组完成某些东西，那么A组不要消极等待，而是应该积极定义B组要提供的东西。Commit！Do not omit.
5. Decouple from others与他人解耦。 假设有多个team并行开发，如果你需要等待某个 team完成他们的模块，你不要空等他们搞定手上的代码，而是应该将你自己从他们的工作中解耦出来。具体方式：写stub，写mock，写模拟代码。写很 多不需要对方就可以运行的代码。这样一来，两个模块之间的接口也就定义好了。通过stub、mock、模拟代码，将自己从软件的层面与他人解耦，而不要被 挡在路上（blocked）。
6. 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 。其他后续部分会根据可用时间慢慢整理。