标签：++ 基础上 一起 引导 修复 写代码 反馈 text 并且
Robert C. Martin（ 罗伯特·C·马丁），作为世界级软件开发大师、设计模式和敏捷开发先驱、C++ Report杂志前主编，也是敏捷联盟（Agile Alliance）的第一任主席，我们尊称他为“ Bob 大叔（Uncle Bob）”。
如今，年逾六十的 Bob 大叔过着典型的“斜杠”生活，他不仅是优秀的程序员、畅销书作家、演讲家，以及视频制作者，还是一名柔术爱好者。 多年学习柔术的经历，带给他的除了强健的身体之外，还有从中受到的有关“匠艺”的熏陶。他经常受邀去各地进行演讲，向当下年轻一代的程序员们分享他所理解的敏捷。现在，Bob 大叔也常常在 Twitter 的账号（@Uncle Bob Martin）以及个人网站（cleancoder.com）上发表自己的观点、文章。
Bob 大叔认为， 敏捷不是项目管理方法，而是一套价值观和纪律，可以帮助相对较小的团队构建中小型产品。这一观点的提出源于他无数次的亲身项目实践。
1970年，18岁的 Bob 在一家名为 A.S.C.Tabulating 公司做程序员，起初写代码的时候，Bob 及其团队度过了一段艰难的日子。当时的工作是划分白班和夜班的，白班时，程序员先用铅笔把代码写在编码表格上，然后用打孔机在卡片上打孔，把仔细检查过的卡片交给计算机操作员，操作员则在夜班时进行编译和测试。但这一番操作下来，通常会花费几天的时间，且之后的每一轮修改都会花费大约一天的时间，团队就在日复一日地编码、编译、测试、修复 Bug。这种开发模式在当时尤为普遍，因此生产效率低下的问题亟待解决。
为了缩短开发过程中反馈的时间，瀑布模型应运而生。该模型很好地解决了生产效率问题，并在70、80年代间迅速地占据了软件开发的大半江山，Bob 及其团队也开始了“瀑布开发”之旅。
但是想象中精细的计划、完美的策略所打造的卓越成果并没有出现，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 想围绕代码整洁和极限编程创建一个非营利组织，但这一想法在当时并未得到大多数人的认可。于是到2000年秋天，Bob 又提出了一个想法： 让相互竞争的轻量级流程倡导者聚集在一起，形成一个统一的宣言。这个想法得到了 Martin Fowler 的大力支持，两人一拍即合，着手准备会议的前期筹备工作。在筹备的后期，又加入了一名意向者——Alistair Cockburn，Alistair 的加入使这次的会议准备更加完备，并将会议地点定在雪鸟滑雪场，这样，雪鸟会议就被安排好了。
这次的雪鸟会议历时两天，十七位不同流派的敏捷大师在阿斯彭会议室里进行了长达两天的讨论，意在寻求所有轻量级过程和软件开发的共同点，最终他们从 交互、 软件、 协作、 变化等四个角度搭建出了敏捷价值观及十二原则。但令人遗憾的是，为了求同存异，这次会议所签署的《敏捷宣言》 并未对“如何编程”这一部分作过多的解释，同样没有将 Bob 一直提倡的代码整洁纳入。
但这并不意味着 Bob 放弃了“代码整洁”。2010年，Bob 出版了《代码整洁之道》一书，他在书中正式提出“ 代码质量与其整洁度成正比”的观点。这本书一经面世，就在软件开发行业掀起了轩然大波 。“代码整洁”认为，整洁的代码是自解释的，阅读代码应该如同阅读一篇优秀的文章，见字知意，能够一下子明白大概的代码功能。代码首先要能读懂，其次才去要求功能实现，这一理念得到了数百万程序员的追捧。Bob 大叔坚信，工作保证速度与质量的唯一方法：尽可能地保持代码整洁。很快，这个唯一的方法就不那么灵验了。
人们好像又陷入了一种误区：只要实施敏捷、做好代码规范就一定能给软件项目带来明显改善。在这一误区里，人们离真正的敏捷越来越远。2016年，Bob 出版《代码整洁之道：程序员的职业修养》一书，引导读者认识到专业程序员肩负的责任重大，阐述了什么才是程序员的职业素养。此外，Bob 将“代码整洁”在原有基础上扩充了一番：整整30年，大家一直受困于“用大团队干大事”的观念，根本不知道成功的秘诀其实在于用很多小团队解决很多小问题，而这就需要每个程序员具备“匠艺精神”，从而引导开发人员回归真正的敏捷。
“匠艺精神”是指开发人员不再把工作当作简单的上班打卡，而是基于把事情做好的渴望，来提供专业的服务。Bob 提出的“匠艺精神”将关注点聚焦到了开发人员身上，并得到了很多开发人员的支持。为了提高软件开发的水准，并重新明确敏捷最初的目标，一群开发人员于2008年11月聚集到芝加哥，发起了一个新的运动： 软件匠艺（Software Craftsmanship），并形成了一套核心价值观。
许多开发人员对敏捷未来的发展方向感到失望，这是催生软件匠艺运动的诱因之一。一部分人觉得敏捷太过于业务，而另一部分人觉得匠艺太关注工程，因此认为敏捷与匠艺水火不容，但 Bob 大叔对此持相反观点。不论是敏捷还是匠艺，本质都是为了交付高质量、有价值的工作，两者缺一不可，68岁的 Bob 大叔如是说。2020年，为了引导新一代软件开发者刚起步就把敏捷用对，他推出新作《敏捷整洁之道：回归本源》，帮助读者理解敏捷价值观与匠艺精神在敏捷团队中的重要意义。
如今，我们的 Bob 大叔——Robert C. Martin，作为2001年在犹他州雪鸟小屋中推动雪球的十七人之一，他身体力行地维护着代码整洁。对编程拥有无尽热情的他，也 开始尝试推动敏捷和匠艺的携手并进，从而修复业务与开发之间的鸿沟。他的故事仍在继续。
敏捷史话（六）：也许这个人能拯救你的代码 —— Robert C. Martin
标签：++ 基础上 一起 引导 修复 写代码 反馈 text 并且
原文地址：https://www.cnblogs.com/minjieagile/p/14394943.html
