匠艺整洁之道：程序员的职业修养

推荐序一

近几周一直在看《匠艺整洁之道》的样稿，这是近半年来我看得认真的有关软件工程方面的一本书，也是收获的一本书。

初识作者鲍勃大叔源于他的《代码整洁之道》（Clean Code），书里不厌其烦地描述如何能够写出高可读性代码的各种注意事项。写这样的书，我没有这样的水平，也没有这样的耐心，于是在《代码的艺术》一书和课件中，我会推荐学员和读者去看。对于一个想要写出好代码的软件工程师来说，是要好好了解这些细节的。

仅凭《代码整洁之道》，我对鲍勃大叔还没有那么崇拜。我一直认为，“写好代码”对于一个优秀的软件工程师还只是基本的要求，而“写好文档”“做好项目管理”“不断提高自我”“拥有正确的人生目标和价值观”，这些才是更重要的。

很有幸，之后我又看到了鲍勃大叔的其他作品，包括《架构整洁之道》（Clean Architecture）、《代码整洁之道：程序员的职业素养》（The Clean Coder）。这些书让我改变了对鲍勃大叔的“错误”印象。尤其在本次阅读《匠艺整洁之道》的过程中，鲍勃大叔让我肃然起敬，书中诸多观点也让我感受到了强烈的共鸣。

在《代码的艺术》一书中，我提到“代码是人类智慧的结晶”“伟大的系统和产品一定来自优秀的人和团队”。关于优秀软件工程师的修炼之道，我总结为“学习—思考—实践”“知识—方法—精神”“基础乃治学之根本”。而在《匠艺整洁之道》中，鲍勃大叔提出“软件开发人员的职业操守”，总结为“我不写有害的代码”“我生产的代码将永远是我好的作品”“我永远不会停止学习和改进我的技艺”等10条誓言。这些誓言真的是振聋发聩，值得所有的软件工程师好好学习和思考。在目前这个整体浮躁和迷茫的行业环境中，这些职业操守可以帮人成长，让人沉静，进而做出伟大的产品和系统！

书中关于“极限编程”的总结和描述也是高屋建瓴。关于TDD、重构、简单设计、协同编程这四点所构成的“生命之环”的描述，让人茅塞顿开。大量的软件工程师对“敏捷”有各种错误的认识。而在关于“纪律”的描述中，鲍勃大叔告诉我们，TDD是关键纪律，TDD和重构不可分割，简单设计依赖于重构，协同编程是软件团队共同工作的纪律和艺术。这些总结和论述真是太精辟了！

后要提醒读者的是，阅读本书确实需要很好的耐心和很强的“向善之心”。大量读者喜欢“××语言从入门到精通”这种快餐类型的书，这样的书虽然可以“吃”得很快，但是“营养”有限。本书显然不是这种快餐类型的图书，书中的不少内容都是基于鲍勃大叔多年经验的总结，要理解、领会这样的内容，是需要阅历、思考和时间的。好的食物需要细细品味，好书也是如此。

感谢鲍勃大叔，也感谢本书的译者韩磊，感谢你们给中国的软件工程师带来这么好的一本书！

——章淼　BFE开源项目发起人、《代码的艺术》作者

推荐序二

很多公司的业务，是由产品或者运营来驱动的。对于一个非技术驱动的公司而言，技术团队的核心工作与核心职责都聚焦在产品与系统的交付上。如何提升产品与系统的交付效率与交付质量，是每一个技术人、每一个技术管理者日思夜想的问题。

我管理技术团队很多年，在带领技术团队作战的过程中，曾经有过这样的困惑与疑虑：

? 是什么决定了技术团队交付效率与交付质量的底线？

? 如何有效地为交付设定效率标准与质量标准，并持续迭代与改进？

? 作为一个技术人，其核心职业操守与道德准则是什么？

鲍勃大叔的Clean Craftsmanship从纪律、标准和职业操守三个方面给了我部分答案，很后悔没有能够早一点读到它。近期，其中文版《匠艺整洁之道》如期而至，作为一个技术人，又或者是一个技术管理者，如果你也遇到过和我类似的困惑与疑虑，建议你读读这本书。

一、关于纪律

不同的公司，研发效率与质量各异，究竟是什么决定了技术团队交付效率与交付质量的底线呢？

举一个很小的例子，有一次我们发布了一个系统，发现用户在访问时大约有1/8的概率出现了异常，这令我们百思不得其解。跟踪下来我们发现，这是因为在进行系统发布的时候，集群中的7个节点二进制发布成功，而1个节点二进制发布失败所导致的。

事后我们复盘，如何避免此类情况的发生呢？答案是“清单革命”。在发布流程里增加一项纪律，必须校验集群所有发布二进制的MD5。从今以后，不管是刚入职的应届生，还是资深的工程师，都不会再犯类似的错误，这就是纪律的威力。

系统发布有纪律、高效率和高质量的系统交付同样存在着有迹可循的纪律准则：测试驱动、系统设计、系统重构、结对编程和验收测试等。正是纪律，决定了技术团队交付效率与交付质量的底线。

二、关于标准

作为技术团队的负责人，如何有效地为交付设定效率标准与质量标准，并持续迭代与改进呢？

研发质量，要有标准：冒烟测试通过率是多少？千行缺陷率是多少？平均需求缺陷数是多少？……

测试质量，要有标准：测试环境自动化搭建程度是多少？用例复用率是多少？全量用例回归时间是多少？……

研发效率，要有标准：项目并行度是多少？故障定位与修复时间是多长？APP版本迭代周期是多长？……

关于标准，鲍勃大叔和我们谈了技术生产力，谈了持续改进，谈了自动化测试，谈了极致质量……

俗话说，没有度量标准，就没有办法评估；没有办法评估，就没有办法改进。正是“度量标准”，在指导着研发的效率与质量不断进步。

三、关于职业操守

不少技术人是有傲气的，包括我自己。我们改变着世界，用代码编写着规则，掌控着互联网运行的规律，那么什么是我们必须遵守的职业操守与道德准则呢？

每当我们写下一行代码，实现一个函数，提供一个接口时，这些意味着什么呢？我们有责任全力保证代码的正确性，有责任让所有继承它的人了解所写函数的作用，有责任保证接口好用、易用、难于误用。因为稍有失误，可能就意味着一次登录的失败、一笔资金的丢失、一次刹车的失效，甚至是以一条生命作为代价。

关于职业操守，鲍勃大叔和我们谈了正确性证明，谈了结构化编程，谈了TDD，谈了突变测试，谈了团队协作，等等。注释，文档，思考，交流，承诺，协作，自动控制，每一行代码里，无一不体现着我们技术人的职业操守。

后，再次向每一个工程师、每一个技术管理者郑重推荐《匠艺整洁之道》，希望你能有收获，也和每一个致力于提升研发效率与质量的技术人，一起共勉！

——沈剑　公众号“架构师之路”作者

推荐序三：小处见大、以微知著

《匠艺整洁之道》已经是敏捷宣言签署者Robert C. Martin（鲍勃大叔）Clean系列的第五本书。程序员的“匠艺”（Craftsmanship）始终是鲍勃大叔的核心命题，本次从实践、纪律到职业操守，无不在谈这件事情。追求匠艺，就像书中实践部分的TDD一样，是一件知易行难之事。

与很多软件开发的理念和方法一样，对于Clean系列的评价并非众口同声，《敏捷整洁之道》（Clean Agile）前两年就在业内出现了一些批评的声音。有人指出鲍勃大叔过于聚焦局部细节，而忽略了现代软件开发的规模化问题。数字化时代毫无疑问是在持续增加软件系统的复杂度，甚至正在通过软件构建一个元宇宙，而应对这样的复杂度是每家企业、每个组织不得不面对的挑战。

从二十多年前的敏捷宣言开始，我们已经意识到在软件开发方法上是没有一枚银弹的，不同的程序员具有不同的倾向性，也是这个行业的常态。鲍勃大叔值得我们学习的，并非是他系列著作中的具体方法，而是他持续思考如何将如此复杂的软件开发过程标准化，以提高软件质量的思维方式。这种思考的元模型一旦融会贯通，很多复杂问题都能够“递归”而解。所以Clean系列具有小处见大的特点，读书的关键在于理解鲍勃大叔从个体到集体的匠艺思考。

在硅谷曾有幸听过鲍勃大叔的一场演讲，他在现场激情四射，将几十年的实战所得娓娓道来。这样的感受也可以从本书的字里行间感受到。鲍勃大叔在这个年纪，仍然在持续学习和改进，从开始的《代码整洁之道》（Clean Code）关注“好代码”，到现在《匠艺整洁之道》关注“好匠艺”，应该说是十年磨一剑的升华。从细微的程序员个人实践开始，以微知著，建立面向高质量、可持续发展的团队纪律和组织能力。

弘扬科学精神和工匠精神，已经是我们面向数字化时代的国策基石，鲍勃大叔给我们带来了软件开发领域几十年的匠艺追求，这份净心，对于尚处于青春期的技术行业，是每一位从业者必要的修炼。只有不停磨炼匠艺，纠正“35岁转管理”这样的行业浮躁心态，从而走向真正的工匠精神之路。

——肖然　Thoughtworks全球数字化转型专家、中国敏捷教练企业联盟秘书长

推荐序四：改变认知的一本书

软件工程师是我们这个时代接近工匠的一个职业，在我眼中甚至有点儿接近文学和音乐。虽然这个名称里面带着“工程”两个字，但是对比其他的行业或者传统意义上的工程，软件工程的工业化程度还处于比较低的状态，这就意味着对人的要求会更高。我相信很多朋友都听说过一句话：“代码是写给人看的，不是写给机器看的，只是顺便计算机可以执行而已。”但是又有多少工程师有这样的认知呢？

我认为，一个好的工程师的标准正是对待代码的态度，是不是有比能把“代码运行起来”这件事情更高的要求。回想我自己，我觉得我个人的转变是从看鲍勃大叔的《代码整洁之道》开始的。在那之前，作为软件工程师，我关注的重点在于技巧和很多具体的技术细节上。而对于鲍勃大叔的书，大家可能会发现他很少讲技巧，而是告诉大家在代码之外的更多东西，比如如何对待测试，如何对待软件工程，如何用一颗工匠般的心看待自己写出的代码，我认为这样的认知转变是一个优秀软件工程师成长的必经之路。

这本新书也一如既往地精彩，它通俗易懂又发人深省，如果你是一位对于写出好的程序有更高要求的程序员：不仅仅当成一个朝九晚五的工作，而是一门手艺，甚至一门艺术，你会喜欢这本书的。

——黄东旭　PingCAP联合创始人兼CTO

推荐序五

非常荣幸为鲍勃大叔的封山之作中文版写序，我从事软件架构设计及开发十余年，在个人成长以及带技术团队过程中，我都极力推荐鲍勃大叔的 Clean 理念，同时我也是鲍勃大叔Clean理念的受益人，感谢这位的编程大师。

老朋友侠少这次极力邀请我为中文版写序，大抵是因为近两年我的创业目标和鲍勃大叔殊途同归，我们都致力于提升IT工程师的软件开发水平，鲍勃大叔采用的是不断写书的方式，而我成立了一家奈学科技公司，通过案例剖析和场景实战的创始模式不断提升IT工程师的技术能力，从而为数字经济添砖加瓦，期望能像鲍勃大叔一样影响全世界！

鲍勃大叔Clean系列的每一本书我都详细拜读过，这次新书的电子版刚出来后，我也是以快的速度拜读了这部封山之作。书中的插画一如既往地精彩，这本书更是之前Clean系列的集大成者。之前的系列更多关注于“技术”本身，这本书更多关注在使用技术的“人”身上。之前的每本书中鲍勃大叔都有很多精彩的思路和经验分享，而这本书中鲍勃大叔把之前的很多思路和经验抽象为方法论呈现给读者，让读者有章可循。

本书一共分为三个部分，即纪律、标准和操守。在部分中，作者用实例阐释TDD在敏捷软件中的运用，以及验收测试、协同编程等常被忽视的敏捷侧面与具体策略，同时这部分深刻地阐述了纪律的重要性；如果你是技术团队的管理者，或者是即将成为技术团队的管理者，我极力推荐你反复研读第二部分和第三部分，这两部分言简意赅地阐述了标准和操守对于“人”做软件开发的重要性。

我们这一代工程师是幸福的，因为有鲍勃大叔这样的大师一直引领着我们，如果你现在正在匠师之路上，那就赶紧打开《匠艺整洁之道》吧！

——孙玄　奈学科技创始人兼CEO、58集团前技术委员会主席

推荐序六

这大概是我迄今为止完成快的一篇序，并不是因为敷衍，而是对这本新书的迫不及待。

2022年3月25日，收到博文视点张春雨老师的邀请，让我给鲍勃大叔的Clean系列新书作序。作为Clean系列的忠实读者，之前的《代码整洁之道》和《架构整洁之道》都曾给予我莫大的帮助与启发。如果当下你在软件开发的过程中有所困惑，遇到些许瓶颈，那么鲍勃大叔的Clean系列非常推荐你读一读，而且建议反复品读。

记得次接触Clean系列，是在我读研期间。说实话，次读并没有觉得这是一本多好的书。但在工作一段时间之后，由于具备了一定的实践经验，再回过头来品读一番，才顿悟书中内容之妙，这大概就是成长的必经之路吧。当我们没有经历过挫折的时候，对于前辈的指点，总是很难感同身受，甚至觉得根本不对。但当我们真正遇到相同问题的时候，才发现前人的经验确实妙不可言。

我强烈推荐大家拥有一套Clean系列，因为这个系列不仅介绍了关于软件开发过程中的各种优秀实践案例，让我们知道整洁代码、整洁架构给我们带来的好处，以及如何保持整洁的秘诀；而且对于优秀程序员应该具备何种职业素养，并指导我们做出软件的底层思维模式，更有着极佳的指导意义。也许随着社会与技术的发展，有些案例慢慢不再适用，但职业素养和思维模式会伴随我们一生，这些底层逻辑将一直指导我们未来的每一处设计与实践。

介绍了那么多过去的内容，再来谈谈这本新书《匠艺整洁之道》。在刚看到书名的时候，一时半会儿还真猜不出这本书会讲什么，所以在拿到样章那一刻，我就直奔书中主题，一探究竟！这本书的章名为“匠艺”，作者认为要做好某件事的本质是需要良好的指导与大量的经验。但是，在如今的软件行业中，有很多程序员并不会做太久，所以他们缺少足够的实践体验和经验沉淀。同时，每隔5年程序员的数量就会翻一番，所以优秀程序员的比例会持续走低。当优秀程序员越来越少，保障软件产品的质量就会越来越难。所以，作者在接下来的章节中分别阐述了决定技艺水平的三个要素：纪律、标准和职业操守，以帮助开发者与管理者改变与提高团队的工作方式，限度地生产出高质量的软件产品。从这三部分的内容划分来看，这本书不仅仅适用于一线的开发者，对于管理者也是非常有帮助的。如果你对于目前的开发任务或团队的工作方式不太满意，或许可以通过这本书获取一些新的启发。

听说这本书将是鲍勃大叔的封山之作，所以期待这本书的上市，我一定会将这本书收入囊中，集齐Clean系列。虽然无法召唤神龙，但如之前的Clean系列图书一样，当我遇到困惑的时候，也会再翻出来寻找一些前人的启发。如果你跟我一样，打算在软件行业奋斗一生，那么这样的书，推荐你也拥有一本。

——翟永超　公众号“程序员DD”主理人、《Spring Cloud微服务实战》作者

推荐序七

2022年3月，我从工作了几年的公司离职，准备休息一段时间，老朋友张春雨（侠少）听闻我离职后在微信上跟我说，Robert C. Martin写了本新书，你有兴趣写篇序吗。侠少这几年一直邀我写书，可之前公司发展迅速，我也一直没有时间，恰好近节奏也算慢了下来，于是就接下了这份活儿。

我知道Robert C. Martin还得从刚毕业去金山工作时说起，当时快盘的工作非常繁重，而我又是一个刚入行的新人，对代码和项目中很多细节都不是特别了解。记忆深的是，当时的mentor花了一晚上重构了我的代码，跟我说好的工程师应该经常重构保持代码整洁，于是他推荐了几本书给我，其中就有《代码整洁之道》。

我花了一周时间读完这本书，不能说像打开了任督二脉从此走向人生，但至少明白了工程界有工程界的标准和要求，“整洁”二字说起来简单，但做起来却没那么简单。从个人的素养、软件架构、方法等到代码组织方式等，有太多可以学习和推敲的地方。随着项目本身的发展，这些“软”性的东西将决定着整个项目的能力上限。我也明白了为什么当时的mentor要经常性地重构代码，维护整个项目的“整洁”。

随着年龄的增长，我也从一线工程师开始带起了自己的团队，从几人到几十人，从创业公司到地区级独角兽，从《代码整洁之道》中学到的技巧和思路依然影响着我。从团队组建伊始我就不断强调好的代码就应该如同读一篇文章一样，也会组织定期review和重构等。老实说，这些方法确实在很大程度上帮助了我们团队运作这些项目，避免了大多数大型项目终失控的命运。

收到侠少给我的样稿后我花了点儿时间通读了一番，我觉得本书是《代码整洁之道》的升华版本，从如何做事到如何做人，这也应对了英文版Craftsmanship这个单词—工匠精神。这本书里更多的是把技术和人文结合起来，少了些技术上的技巧，多了很多工程上的方法论，并不单单只是某种技术。它像一本类似于24条军规一样的书，重申现代世界实际构建者—也就是我们，我们这些工程师应该遵守的职业纪律，它帮助我们面对这份职业的责任，同时帮助我们提高作为工程师或者管理者的上限。

读读此书吧，软件工程已经不仅仅是编码就足够了，而它将会帮到你。

——彭哲夫（CMGS）　Garena高级软件工程师

译　者　序

2021年2月，老朋友张春雨（侠少）在微博上给我发私信，问我有没有兴趣翻译Robert C. Martin（鲍勃大叔）的新书。我和侠少平时联系不多，但常常收到他安排寄来的赠书。赠书收得多了，总觉得欠着人情，想着该用什么方式还一还才好。

这个“什么方式”，也许是几顿酒饭、几杯咖啡，但不是翻译一本书。算起来，截至2020年，我已经有十年没做图书翻译工作了。去年翻译了一本小书，眼睛和腰椎、颈椎都有点儿不舒服。一定赔本但不一定赚吆喝的事，还是不干为好。

侠少对我了解甚深，他只说了一句话，就成功说服我接下任务。他说：“这是（鲍勃）大叔的封山作。本和后一本，有始有终，一段佳话！”这一下子就勾起我翻译《代码整洁之道》（Clean Code）的回忆。当时我在北京工作，个人能力提升和职业发展都遇到瓶颈，同时还需要考虑家庭常驻地问题。《代码整洁之道》不但带给我关于整洁代码的知识，还令我悟到许多做人做事的道理。对我来说，那是一本优秀技术书，更是一本关于价值观的好书。

《代码整洁之道》中文版面世十一年以来，数次修订和重印，成为很多程序员朋友接受并推崇的读本。其间，鲍勃大叔的其他数本著作也陆续出了中文版。这些著作从程序员素养、架构设计、敏捷方法等方面入手，全面阐述“整洁”概念在软件开发过程中的重要意义与实践手段，建立了一套相对自足的理论和方法体系，大概能算是Clean系列的“武功秘籍”了吧。

鲍勃大叔提出，既然现代世界运行于软件之上，软件开发者就要承担起维护世界正常运行的重大责任。这意味着软件开发者必须掌握足够多的技能，遵守足够严格的纪律，追求足够高的职业操守标准，方能达到社会对他们的期望。他提炼了前面多本著作的精髓，加以深究、凝练和升华，推出这本集大成的Clean系列封山之作。

回顾Clean系列图书的主题，可以很清楚地看到从“关注技术”到“关注人”的发展脉络。就像是老拳师写拳谱，本都是讲招式。过了一阵子，老拳师发现徒弟们招式练得挺熟，但内功没跟上，“练拳不练功，到老一场空”，于是赶紧再写一本讲内功的。又过了一阵子，老拳师发现徒弟们一上擂台就不懂如何审时度势选择攻击方案，又赶紧写一本讲架构的。如此这般勿勿十年，老拳师突然发现，拳谱传来传去，很多人练得似是而非，拳打歪了，心术也不见得很正。

如果你是这位老拳师，面对如此现状，会是什么心情？我想，大概也会像鲍勃大叔一般，既悲观又不甘吧。就我这两年参与审校或审阅的几本敏捷图书来看，恐怕既悲观又不甘的不只是鲍勃大叔一个人。敏捷软件开发成为主流之后，同时也成了有些人借以牟利和乱来的“幌子”。当所有人都在谈敏捷，而吹捧与批评都没谈到点子上时，正本清源就成了当务之急。所以，近两年面世的敏捷书，不约而同集中在一个主题：正本清源。

敏捷既是手段，也是目的。正如鲍勃大叔在本书中一再强调的：软件根本的特点就是“柔软”。好软件不但具备能够与时俱进修改和扩展的灵活性，而且更具备以较低成本修改和扩展的可能性。软件本身如果敏捷，那么实现和修改软件的方式必须也必然够敏捷。

本书第Ⅰ部分和第Ⅱ部分结合多个代码示例，展示了如何利用TDD敏捷地写出敏捷的软件，同时阐述了验收测试、协同编程等其他敏捷手段的重要性与一般实施手段。不可避免地，作者还花费相当多篇幅讨论软件设计方案问题。我很愿意重点阅读这部分。此外，一些具体的测试策略也颇具可读性。

第Ⅲ部分看似对程序员的日常工作没什么太大帮助，但这部分值得好好阅读和思考。作者提出的程序员十条承诺（或谓“誓言”）浅白易懂，却不易遵守。能谨守这些承诺的程序员，一定是我特别愿意共事的好伙伴。

中文版初稿翻译工作结束之后，我以为终于可以放松下颈椎和腰椎了。没想到，过了一段时间，侠少又发来一份英文修改稿，对初稿改动之处不在少数。还好有电子工业出版社的编辑帮我做了对照工作，将差异处一一列出。看着屏幕上的英文初稿、修改稿和修改了几遍的中文稿，我突然体会到鲍勃大叔讲解“质因数”示例时谈到的心情：对一桩事物的改进过程，活灵活现地跃然眼前。修改的过程既痛苦又快乐。而且，如果没有其他限制，可以一遍又一遍继续做下去，永无止境。

可惜，就像软件有交付截止日一样，译稿也不能一直拖下去。我清楚地知道，译稿还有很多问题。稿子交出去了，这些问题留待读者们发现和批评。如果有机会出修订版，你们的批评和建议必会被纳入，这也算是一种协同写作了吧。

韩磊 2021年10月28日

序

2003年春，在我公司各个技术团队引入Scrum后不久，我见到了鲍勃大叔。那时我还是个新鲜出炉、心怀疑虑的ScrumMaster。鲍勃教我们使用TDD和一个叫作FitNesse的小工具。我问自己：“为什么总要写注定先面临失败的测试？测试不该排在编码之后吗？”就像团队中许多其他成员一样，我常常只能挠着头离开。但是，直至现在，鲍勃大叔对编程匠艺的热情于我仍然记忆犹新。他是个直言不讳的人。记得有一天，他看了我们的缺陷列表后，问我们到底为什么会对并不属于个人的软件系统做出如此糟糕的决定—“这些系统是公司资产，不是你们的个人资产。”他的激情鼓舞了我们。一年半之后，我们实现了百分之八十的自动测试覆盖率，得到了整洁又直观的代码库，客户和团队成员也都满意。之后，我们迅速修正了对“完成”的定义，以之为盾，挡住了潜伏在代码中的小魔怪。本质上，我们学会了如何避免自残。相处日长，我们对鲍勃心生暖意。对我们而言，他如同亲叔父—温暖、坚定、勇敢，一直帮助我们学会站直并做正确的事。有些孩子的“鲍勃大叔”教他们骑单车或钓鱼，而我们这位鲍勃大叔则教我们坚守正直—直至今日，在我的职业生涯中，有能力和愿望，满怀勇气与好奇心地去面对任何环境，仍是鲍勃大叔教会我的课程。

开始从事敏捷