作为你的 CTO，我对生产力有一些期望。
永不交付S**T
（ S**T 是英文单词shit 的避讳形式， 指代极糟糕的东西。为保留原文风格，此处不做翻译。—译者注）
作为你的新 CTO，我希望我们不交付 S**T。
我相信你知道 S**T 代表什么。作为你的新 CTO，我希望我们不交付 S**T。
你有没有交付过 S**T？我们大多数人都交付过。我也交付过。这感觉并不好。我不喜欢， 用 户不喜欢，经理不喜欢， 没有人喜欢。
那么，我们为什么要这样做？为什么我们会交付 S**T？
出于各种原因，我们以为自己没得选。也许因为我们得赶上最后期限。也许因为我们羞于 做悲观预估。也许只是纯粹因为马虎或粗心。也许因为有来自管理层的压力。也许是有关自我 价值。
无论何种原因， 都不该交付 S**T。不交付 S**T 是最低标准的要求。
什么是 S**T？我确信你早已知道， 但还是一起来看看。
你写出的每个缺陷都是 S**T。
你没测试过的每个函数都是 S**T。
你没有好好写的每个函数都是 S**T。
对细节的每个依赖都是 S**T。
每个不必要的耦合都是 S**T。
在 GUI 里出现的 SQL 语句是 S**T。
业务规则里面出现的数据库 Schema 是 S**T。
还可以继续罗列。简言之，当违反前面章节中所列纪律时，都有交付 S**T 的风险。这并不意味着必须在任何时候都遵守每条纪律。
我们是工程师。工程师要做权衡。但工程上的权衡不是纵容粗心大意或马马虎虎。如果不 得不违反一条纪律，最好有像样的理由。
更重要的是，最好有像样的缓解措施。
比如， 你在编写级联样式表（CSS）代码。先为 CSS 写出自动化测试几乎总是不切实际的。在屏幕上看到 CSS 之前，你并不知道它将如何呈现。
那么，我们如何面对 CSS 破坏了 TDD 测试纪律的事实呢？
我们将不得不用肉眼测试 CSS。我们还必须在客户可能使用的所有浏览器中进行测试。因 此，最好对我们想在屏幕上看到的东西有标准描述，以及搞清楚我们能容忍多大变动。更重要 的是，我们最好想出技术解决方案，使 CSS 易于手动测试，因为我们，而不是 QA，要在发布 之前测试它。
换言之， 这就叫作：干好工作。
这就是每个人真正期望的。所有经理， 所有用户， 所有我们曾经接触过或被我们的软件接触过的人，都期望我们能做得好。我们绝不能让他们失望。我希望， 我们永远不交付 S**T。
成本低廉的变更适应能力
Software 是个复合词， 意思是 “灵活的产品”。软件存在的全部理由是为了让我们能够快速 和容易地改变机器行为。如果我们制造的软件难以改变，我们就会破坏软件存在的根本理由。
然而， 软件不够灵活仍然是我们这个行业的巨大问题。我们如此关注设计和架构的原因本 就是为了提高系统的灵活性和可维护性。
为什么软件会变得僵化、不灵活和脆弱？同样，这是因为软件团队没有遵守保证灵活性及 可维护性的测试和重构纪律。在某些情况下， 这些团队可能只依赖于最初的设计和架构。在其 他情况下，他们可能依赖于那些“拍脑袋”式的决定。
但是， 无论你创建了多少个微服务，无论你为最初的设计和架构设想了多好的结构， 如果 不遵守测试和重构纪律，代码就会迅速退化，系统将变得越来越难以维护。
我并不希望发生这种情况。我希望当客户要求变更时， 开发团队能够明确回应， 给出策略， 说明变更范围与所需费用的比例关系。
客户可能不了解系统的内部结构， 但他们对自己要求的变更范围有良好认识。他们明白， 一处变更可能会影响许多功能。他们希望变更的成本与影响范围相对应。
不幸的是， 随着时间的推移，太多的系统变得如此不灵活，以至于变更的成本上升到了客 户和经理无法根据变更范围来合理规划的程度。更糟糕的是， 开发人员以系统架构不支持为由， 反对某些类型的变更， 这种情况并不罕见。
抵制客户改变要求的架构是与软件的意义和意图对立的架构。这样的架构必须修改， 以适 应客户将会做出的变动。经过良好重构的系统和让人足够信任的测试集，没有什么能比它们更 容易实现这样的变动了。
我希望系统的设计和架构能够随着需求的变更而变化。我希望当客户要求变更时， 这些变更不会被现存架构或现有系统的僵化和脆弱所阻碍。
（ps： 这个功能在新链路有，老链路不支持）
这个，嗯嗯，架构上不支持。
我希望得到成本低廉的需求变更适应能力。
时刻准备着
作为你的新 CTO，我希望我们时刻准备着。
早在敏捷流行之前，大多数软件专家就已明白，运行良好的项目会经历有规律的部署和发 布节奏。在早期，这种节奏往往是快速的：每周， 甚至是每天。然而， 从 20 世纪 70 年代开始 的瀑布运动大大减缓了这种节奏。周期变成了几个月， 有时甚至是几年。
在千年之交， 敏捷的出现再次证明了对快速节奏的需求。Scrum 建议冲刺时间为 30 天。XP 建议迭代时间为三周。两者都迅速将节奏加快到以两周为单位。如今，每天部署多次的情况并不少见， 开发团队有效地将开发周期减少到接近零。
我希望节奏够快， 不要超过一到两周的时间。在每个冲刺结束时， 我希望软件在技术上已 经准备完毕，随时可以发布。
技术上准备好发布，并不意味着企业已想要发布。虽然软件在技术上已做好准备，但可能 还没覆盖企业认可的完整或适合其客户和用户的功能集。技术上做好准备，仅仅意味着如果企 业决定发布它，开发团队，包括 QA，都不会有异议。该软件可以工作， 已经过测试，文档齐 备，并且已经准备好部署。
这就是 “时刻准备着”的意思。我不希望开发团队通知业务部门还要等待。我不希望有很长的磨合期或所谓的稳定期。Alpha 和 Beta 测试可能适宜用来确定与用户的功能兼容性，但不 应该用来消除编码缺陷。
很久以前， 我的公司为某个给法律界制造文字处理器的团队提供咨询。我们教他们极限编程。他们最终达到这样的程度：团队每周都会刻录一张新的光盘。他们会把光盘放在开发商实验室里保存的一堆每周发布的光盘的最上面。销售人员在为潜在客户做演示前，会顺路走进实验室， 取走这堆光盘中最上面的那张。这就是开发团队的准备程度。这也是我希望我们能做好的准备。
像这样频繁的准备， 需要遵守非常严格的计划纪律、测试纪律、沟通纪律和时间管理纪律。当然， 这些都是敏捷纪律。利益相关者和开发人员必须经常参与估算和选择最高价值的开发故 事（Development Stories）。QA 必须深入参与提供自动验收测试， 定义“完成”的概念。开发人 员必须紧密合作，遵守密集测试、代码审查和重构纪律，以便在短时间内取得进展。
但“时刻准备着”不仅仅是遵循敏捷的教条和仪轨。时刻准备着是一种态度， 一种生活方式。它是一种不断提供增量价值的承诺。我希望我们能够永远做好准备。
我希望我们时刻准备着。
稳定的生产力
软件项目经常会出现生产力随时间下降的情况。这是一种严重机制失调的表征。它由忽视测试纪律和重构纪律造成。这种忽视导致了纠缠不清、脆弱和僵化的代码不断增加。
这是一种失控效应。系统中的代码越是脆弱和僵硬， 保持代码整洁就越困难。随着代码脆 弱性增加， 人们对变化的恐惧也在增加。开发人员变得越来越不愿意清理混乱的代码，因为他 们担心这么做会导致更多缺陷产生。
这个过程在几个月内导致生产力加速损失。在接下来的每个月，团队的生产力似乎都在渐 渐向零靠拢。
经理们经常试图通过为项目增加人力来对抗生产力下降。但这种策略往往会失败，因为新加入团队的程序员对变化的恐惧并不比一直在那里的程序员少。他们很快就学会仿效老成员的行为，于是问题将长期存在。
当被问及生产力的损失时，开发人员通常会抱怨代码有多糟糕，他们甚至开始主张重新设 计系统。一旦开始，这种抱怨就会越来越多，直到管理者无法忽视。
开发者提出的论点是，如果他们从头开始重新设计系统，就可以提高生产力。他们一再 保证， 他们已经知道所犯的错误， 而且不会重复这些错误。管理人员当然不相信这种说法。但经理们对任何能提高生产力的东西都很渴望。最后，尽管有成本和风险， 许多经理还是同 意了程序员的要求。
我希望这种情况不会发生。我希望开发团队能够持续保有高生产力。我希望开发团队能够 不打折扣地遵守保持软件结构不退化的纪律。
我希望得到稳定的生产力。
作者简介
罗伯特 C. 马丁（鲍勃大叔），软件开发行业领军人物，曾任C++ Report杂志主编、敏捷联盟首任主席、Object Mentor公司总裁，面向对象设计、模式、UML、敏捷方法学和极限编程领域的资深顾问。
1964年，年仅12岁的就已写下他的第一行代码。他自1970年起从事程序员职业。他与人合办了cleancoders.com网站，为软件开发者提供在线视频培训服务。他还创办了Uncle Bob咨询有限公司，为分布于世界各地的大公司提供软件咨询、培训和技能培养服务。同时，他也供职于芝加哥的软件咨询企业8th Light，任大匠（Master Craftsman）一职。
马丁先生在多本行业杂志上发表过数十篇文章，是各种国际性会议和行业活动讲坛上的常客。他也是cleancoders.com网站上广受赞誉的多个系列视频的创作者，也是Designing Object-Oriented C++ Applications Using the Booch Method 以及 Jolt 获奖图书 Agile Software Development, Principles, Palterns,and Practices，Clean Code 等畅销书作者。
译者简介
韩磊，IT产品与运营专家、IT图书专业译者，译有《代码整洁之道》《梦断代码》《C#编程风格》等多部计算机图书。曾担任CSDN副总经理、《程序员》总编辑、广东二十一世纪传媒股份有限公司新媒体事业部总经理等职，现任AR初创企业亮风台广州公司总经理。
中外匠师如此评价
感谢鲍勃大叔，也感谢本书的译者韩磊，感谢你们给中国的软件工程师带来这么好的一本书！
——章淼 BFE开源项目发起人、《代码的艺术》作者
向每一个工程师、每一个技术管理者郑重推荐《匠艺整洁之道》，希望你能有收获，也和每一个致力于提升研发效率与质量的技术人，一起共勉！
——沈剑 公众号“架构师之路”作者
鲍勃大叔给我们带来了软件开发领域几十年的匠艺追求，这份净心，对于尚处于青春期的技术行业，是每一位从业者必要的修炼。只有不停磨炼匠艺，纠正“35岁转管理”这样的行业浮躁心态，从而走向真正的工匠精神之路。
——肖然 Thoughtworks全球数字化转型专家、中国敏捷教练企业联盟秘书长
这本新书一如既往地精彩，它通俗易懂又发人深省，如果你是一位对于写出好的程序有更高要求的程序员：不仅仅当成一个朝九晚五的工作，而是一门手艺，甚至一门艺术，你会喜欢这本书的。
——黄东旭 PingCAP联合创始人兼CTO
我们这一代工程师是幸福的，因为有鲍勃大叔这样的大师一直引领着我们，如果你现在正在匠师之路上，那就赶紧打开《匠艺整洁之道》吧！
——孙玄 奈学科技创始人兼CEO、58集团前技术委员会主席
如之前的Clean系列图书一样，当我遇到困惑的时候，也会再翻出来寻找一些前人的启发。如果你跟我一样，打算在软件行业奋斗一生，那么这样的书，推荐你也拥有一本。
——翟永超 公众号“程序员DD”主理人、《Spring Cloud微服务实战》作者
它是一本类似于24条军规的书，重申现代世界实际构建者—也就是我们，我们这些工程师应该遵守的职业纪律，它帮助我们面对这份职业的责任，同时帮助我们提高作为工程师或者管理者的上限。
读读此书吧，软件工程已经不仅仅是编码就足够了，而它将会帮到你。
——彭哲夫（CMGS） Garena高级软件工程师
开发者与其追逐技术热点，不如修炼内功、提升技艺水平。而决定技艺水平下限的正是纪律、标准、原则和职业操守这些软实力。鲍勃大叔的新书《匠艺整洁之道》是这样一本好书，帮助开发者提高能力基线和专业精神，产出健壮、高容错和高效率的软件，更好地服务社会，为社会创造更多价值。
——丁宇 阿里云云原生应用平台总经理
我们日常对着需求文档来完成项目，也许并不困难，但真正难的是软件设计、代码细节，以及写出充满工程理念、可靠、健壮的应用。工作10余年的我，现在仍然会对软件工程感兴趣，我坚信它是提升整体工业水平的基础。让我们再次畅快感受这本书吧！
——毛剑 Bilibili基础架构负责人
写代码是件容易的事情，但是写出好代码却是件非常难的事情，它需要编写者具备大量的实践经验，以及得到良好的指导。鲍勃大叔把自己几十年的经验“抽象”为程序员要学会的编程纪律、标准和职业操守，指导程序员成为真正的“匠人”—写出优秀的代码、创建出色的系统，更重要的是，为自己的工作感到骄傲和自豪！
——刘欣 IBM前架构师、公众号“码农翻身”作者
这本书深入浅出剖析测试驱动开发（TDD）、敏捷技术应用实践、协同编程、架构至简设计等技术整洁方法论，让读者能真正掌握架构整洁设计的哲学本质，从而在面向不同业务场景时，都能够给出优雅的架构整洁解决方案，使得企业真正降本增效。本书是架构整洁设计实践类好书，特推荐之。
——孙玄 奈学科技创始人兼CEO、58集团前技术委员会主席
你看过《代码整洁之道》吗？它的作者是鲍勃大叔，这本《匠艺整洁之道》是他的封山之作，我看完之后被深深地吸引。特别力荐给那些追求代码优美、高质量和高效率的程序员朋友们。
——程军 饿了么前技术总监、公众号“军哥手记”主理人
如果喜欢本文
欢迎 在看丨留言丨分享至朋友圈 三连加入读者群，请在公众号后台回复：读者群
往期推荐：
资料获取
1. 识别并关注下方公众号；
2. 在下面公众号后台回复关键字「设计模式」即可下载。
5990
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
