敏捷史话（六）：也许这个人能拯救你的代码 —— Robert C. Martin
- 2021-10-14 15:54:00
- 敏捷开发社区
- 转贴：
- 敏捷开发
- 2470
如今，年逾六十的 Bob 大叔过着典型的“斜杠”生活，他不仅是优秀的程序员、畅销书作家、演讲家，以及视频制作者，还是一名柔术爱好者。 多年学习柔术的经历，带给他的除了强健的身体之外，还有从中受到的有关“匠艺”的熏陶。他经常受邀去各地进行演讲，向当下年轻一代的程序员们分享他所理解的敏捷。现在，Bob 大叔也常常在 Twitter 的账号（@Uncle Bob Martin）以及个人网站（cleancoder.com）上发表自己的观点、文章。
Bob 大叔认为， 敏捷不是 项目管理方法，而是一套价值观和纪律，可以帮助相对较小的团队构建中小型产品。这一观点的提出源于他无数次的亲身项目实践。
瀑布开发之旅
1970年，18岁的 Bob 在一家名为 A.S.C.Tabulating 公司做程序员，起初写代码的时候，Bob 及其团队度过了一段艰难的日子。当时的工作是划分白班和夜班的，白班时，程序员先用铅笔把代码写在编码表格上，然后用打孔机在卡片上打孔，把仔细检查过的卡片交给计算机操作员，操作员则在夜班时进行编译和测试。但这一番操作下来，通常会花费几天的时间，且之后的每一轮修改都会花费大约一天的时间，团队就在日复一日地编码、编译、测试、修复 Bug。这种开发模式在当时尤为普遍，因此生产效率低下的问题亟待解决。
但是想象中精细的计划、完美的策略所打造的卓越成果并没有出现，Bob 只能重新寻找能真正符合他期许的开发流程。在寻找过程中，35岁的 Bob 与搭档 Jim Newkirk 相继加入新的公司——Clear Communication，与此同时，有家公司写了一个很流行的杀手应用，许多专业人士都买来用，这其中也包括 Bob。之后令人感到失望的是，这一应用的版本发布周期变得越来越长，Bug 开始积压，加载的时间也越来越长，系统崩溃的概率也越来越大。最终，大多数用户都选择不再使用这个程序。果不其然，不久，该公司就关门大吉了。
故事到这里还没有结束，偶然一天，Bob 见到了那家公司的员工，才从这名员工的口中得知整个事情的前因后果：当时公司为了推动产品提早发布，非但没有重视代码质量，还一味地追求速度，导致代码乱七八糟，无法进行修改或管理，最终公司经营惨淡，宣布倒闭。“千里之堤，溃于蚁穴。”从这一事件中，Bob 得出一个结论：代码的整洁是需要引起重视的。他认为， 软件质量不仅依赖软件架构及项目管理，还与代码质量紧密相关。
意识到代码整洁的重要性之后，Bob 心想，如果把瀑布模型与代码整洁结合在一起，那一定很完美。于是，在接下来很长的一段时间里，他同团队一起 试图按照“ 分析—设计—编程”的方式实现产品交付。但这行不通。事实上，即使大家对代码整洁做出了规定，并且每次对需求的分析与设计非常正确，但一旦进入开发阶段，事情就开始变得不可控了，总是会因为突如其来的需求变化而打乱之前的计划，导致产品交付不能如期进行。在一次一次的实践过程中，Bob 逐渐发现瀑布开发束缚住了自己的思想。就在他觉得连代码整洁也拯救不了这混乱流程的时候，敏捷开发初见苗头。
敏捷开发的萌芽
20世纪90年代初，敏捷先驱们陆续发布了关于 Scrum 的文章。Bob 接收到这一变革的信号后，突然有种预感： 团队可以尝试一种新方式了。这一预感在他偶然接触到 Kent Beck 关于极限编程的著作之后成真了。Bob 先后几次拜访 Kent，从他那里深入了解了极限编程（XP），并对测试驱动开发（Test-Dreven Development，TDD）进行了尝试。这时的 Bob 才发现，原来在面向对象的环境中可以应用这样的流程，原来一套可以信任的测试能够使代码修改变得异常简单。当他觉得团队完全可以在开发流程中，简单并安全地修整代码的时候，就无法再接受烂代码了。
这次的雪鸟会议历时两天，十七位不同流派的敏捷大师在阿斯彭会议室里进行了长达两天的讨论，意在寻求所有轻量级过程和软件开发的共同点，最终他们从 交互、 软件、 协作、 变化等四个角度搭建出了敏捷价值观及十二原则。但令人遗憾的是，为了求同存异，这次会议所签署的《敏捷宣言》 并未对“如何编程”这一部分作过多的解释，同样没有将 Bob 一直提倡的代码整洁纳入。
但这并不意味着 Bob 放弃了“代码整洁”。2010年，Bob 出版了《代码整洁之道》一书，他在书中正式提出“ 代码质量与其整洁度成正比”的观点。这本书一经面世，就在软件开发行业掀起了轩然大波 。“代码整洁”认为，整洁的代码是自解释的，阅读代码应该如同阅读一篇优秀的文章，见字知意，能够一下子明白大概的代码功能。“ 代码首先要能读懂，其次才去要求功能实现”的理念得到了数百万程序员的追捧。Bob 大叔坚信，工作保证速度与质量的唯一方法就是尽可能地保持代码整洁。很快，这个唯一的方法就不那么灵验了。
贯彻“匠艺精神”
人们好像又陷入了一种误区：只要实施敏捷、做好代码规范就一定能给软件项目带来明显改善。在这一误区里，人们离真正的敏捷越来越远。2016年，Bob 出版《代码整洁之道：程序员的职业修养》一书，引导读者认识到专业程序员肩负的责任重大，以及什么才是程序员的职业素养。此外，Bob 将“代码整洁”在原有基础上进行扩充：整整30年，大家一直受困于“用大团队干大事”的观念，根本不知道成功的秘诀其实在于用很多小团队解决很多小问题，而这就需要每个程序员具备“匠艺精神”，从而引导开发人员回归真正的敏捷。
“匠艺精神”是指开发人员不再把工作当作简单的上班打卡，而是基于把事情做好的渴望，来提供专业的服务。Bob 提出的“匠艺精神”将关注点聚焦到了开发人员身上，并得到了很多开发人员的支持。为了提高软件开发的水准，并重新明确敏捷最初的目标，一群开发人员于2008年11月聚集到芝加哥，发起了新的运动： 软件匠艺（Software Craftsmanship），并形成了一套核心价值观。
如今，我们的 Bob 大叔——Robert C. Martin，作为2001年在犹他州雪鸟小屋中推动雪球的十七人之一，他身体力行地维护着代码整洁。对编程拥有无尽热情的他，也 开始尝试推动敏捷和匠艺的携手并进，从而修复业务与开发之间的鸿沟。他的故事仍在继续。
| 联系人： | 田老师 |
|---|---|
| 电话： | +86 135 5227 9573 |
| Email： | clientservice@hardenx.cn |
| 地址： | 北京市朝阳区福码大厦B座17层1705 |
加微领1G资料
