4万字的“整洁三部曲”干货，全浓缩在这一篇里了

6月14日晚7点半，一场以“解码Bob大叔整洁之道三部曲”为主题的直播活动刚刚结束。

如果你知道Bob大叔，如果你对他的整洁之道有所耳闻，你一定能想象这场直播具有的非凡意义。从2001年敏捷宣言的诞生，到2009年《代码整洁之道》的面世，再到之后的《代码整洁之道：程序员的职业素养》，今年，刚好整整20年，Bob大叔创作的《敏捷整洁之道：回归本源》构成了“整洁三部曲”，其背后的思想和历程值得每一位希望写出整洁代码的程序员挖掘。

（这篇回放稿总共接近4万字，在这里小编尽量保证不曲解大咖们的原意，将其主要观点和精华浓缩出来，呈现给大家，希望大家有所收获。）

代码猴子的整洁之旅

分享嘉宾： 韩磊

互联网产品与社区运营专家，技术书籍著译者。曾任CSDN及《程序员》杂志副总经理、总编辑，广东二十一世纪传媒新媒体事业部总经理等职。现任AR初创企业亮风台广州公司总经理。《代码整洁之道》译者。

观点提要：韩磊老师从国内软件行业现状出发，讲了“代码产出能力变低”的原因、个人对“整洁”的理解，剖析了敏捷与整洁的关系，并猜想了未来软件行业的发展。

主题由来

在2007年，我曾经到硅谷参加一个软件开发者大会，在这个会上面，Robert C. Martin Uncle Bob关于软件匠艺的分享让我收获颇丰。

一开场Uncle Bob就唱了一首歌，这首歌叫做《Code Monkey》，这首歌是一个叫Jonathan的程序员写的，写的是从前自己的一个生活。

2007年，Uncle Bob用代码猴子这首歌来做开场，一方面是一种自嘲，另一方面也是形容很多程序员工作和生活有的时候是一团糟的。

对软件行业的忧心

2010年我翻译这本书，之后的10年里，继续看到很多烂的代码在出现，继续看到很多程序员每天下班九九六，有的是零零七，陷入在无边无际的需求当中，其实这样的情况是很令人痛心的，有的时候我们常常会怪罪外部的环境，但有的时候确实不见得完全是外部环境的错。

任何一个软件项目，当它相对而言略有复杂度之后，稍微略有复杂度的软件项目进行到一定程度之后你们会发现代码产出的能力，随着时间的增长慢慢变得低下，这其实是有点不太合理的。

为什么在一个程序组或者项目组里面，生产会顺着时间的增长一直往下掉呢？很简单，当代码量达到一定程度之后，你程序的复杂度增加了。再就是因为外部环境的影响产生了需求变更，就导致说你必须去修改以前的代码，有的时候甚至需要修改以前代码的架构。

这个时候问题就产生了，如果你的代码不是一个方便修改的状态，你的每次修改有可能导致更多的bug。咱们常常说一句话，当你修改一个软件缺陷的时候，你可能引入了5个到10个新的软件缺陷。需求的变更和缺陷的修补都有可能带来质量的进一步下降，于是发现随着时间的增长，我们的整个生产力一直在往下跌。

对整洁的理解

Uncle Bob提出整洁代码这么一个概念，从这几本书的情况综合来看，不是说光提整洁代码，他也提到了整洁的架构，如何用敏捷的方法来实现整洁，也包括软件开发者自身素质的提升，如何提升我们本身整洁的素质。

什么是整洁代码？整洁代码一定是便于人类或者便于其他程序员阅读的：

第一，能够很方便的把它读完

第二，能很方便的理解它

第三，很方便的修改它

我个人的意见，这就是整洁代码里头最核心的三个要素，当你的代码便于阅读理解和修改，那么代码一定整洁。

当我们的代码写完之后，不再动它，这样就结束了，完成了它的功能性的一方面就结束了。

但是，在更多的场景里头，代码是需要被其他人，有的时候是自己过一段时间翻过来再看一遍，再去修改它。这很多时候是来自于业务的需求，这种业务需求的变更或者业务需求的增加导致代码修改情况越来越频繁的发生。

在这个时候，如果你的代码不够漂亮、不够整洁，不具备方便修改的特性，那么你会变得非常痛苦。

在这我还想再展开说一下，业务需求变更问题。在过去很多年里头，越往前，来自业务变更、需求变更的压力会是越小的，那个时候我们整个软件业界的做法都是你去做一个产品，写出来，然后你能卖出去，不管是卖给企事业单位，或者说卖给大众，编译之后，那你这个版本就算完成了。

越往后面，这件事情就变得不一样。尤其是到了现在这个时代，尤其是做To B、To G的业务，就可以发现很痛苦，为什么痛苦呢？需求永远在变更。当你做一个To C产品的时候，你可以按版本去做你的规划，但做To B、To G，上业务的时候就会很郁闷了，因为客户不会试图理解你关于版本的想法，而是不断要求按照他们的想法来做更改。

还有一个点，传统做To B、To G的时候，你还可以说我交付一个版本之后就结束了。现在有一个新的趋势，政府和企事业单位会倾向于不做一次性采购，而是用租赁或者长期服务的方式来购买这个服务。

这样子一个业务模式带来很严重的后果，意味着程序员每天都有可能应付新增的需求或者更改，这就让我们的项目组、程序员痛苦。尤其是在代码不够整洁的时候，你的代码写完了，你交付完了之后，客户说你给我改改这吧，拿过来这个需求一看。我们先说一个小的更改吧，你改一个小的地方，发现有5个到10个bug突然出现了，你就不知道该怎么弄。

有的时候涉及到价格上面的更改，你都不知道从何改起，这都是现实中我们会遇到的状况。从业务的方向来理解，这个状况会越来越频繁。

敏捷和整洁的关系

第一个点，我认为敏捷不会让项目更快。之前大家都会有一个很大的误区，在相关企业里面，可能老板引入敏捷的目的是希望让项目变得更快，或者让我们的软件开发变得更快捷，这是一个极大的思考误区。

为什么呢？在整个敏捷开发里面，你会做在传统软件开发过程当中不会做的事情，这些事情在老板的观念来看有可能是毫无意义的。

敏捷真正的目的是说让项目变得可控，就是你能够知道项目的进展是怎么样子的，这是我的一个观点。

但是写整洁代码不见得让项目更慢，而且越往项目中期、晚期去，甚至到第二版、第三版进展的时候，越整洁的代码会让你的项目或者让你的开发更快。

第二个点，变化一定是会发生的，不变化的情况非常少，这个变化来自于外部的一些影响。为了变化的发生，你一定要做好响应准备，从很多层面都要去做到响应准备，后面我也谈到了业务层面的准备。

代码从架构到每一类、每一函数，甚至到每一行代码，这个响应准备是随时要有的，如果你没有做好相应准备，面对既定会发生的变化的时候，你就会措手不及。

软件的根本目的还是为人服务，为人服务的前提是说软件的质量一定是高的，软件一定是根据人的需求变化而变化的。

第三个点，这也是很重要的，在过去一些年里头我一直在思考的。前些年我记得网络上有讨论，有一派观点认为代码的注释是没有必要的，因为代码本身就要让他写的足够有说明性，另一派认为代码注释非常有必要，因为再有说明性的代码你都不能够讲的足够清楚，用人的语言讲的足够清楚。

从我个人的观点来看，注释的必要性也许是存在的，但是如果我以注释为借口，而不把代码写的可读，这绝对是不可以接受的。代码本身必须具有足够的说明性，包括它对应的单元测试，其实证明自己说能够修改。

我现在越来越认为，整洁是敏捷开发的结果。敏捷开发贯彻的越彻底，对代码整洁度的要求就会越高，因为代码整洁是敏捷开发的一个基本要素。

未来软件行业的发展

我觉得未来会发生的趋势是什么呢？未来所有的工作都会更加的社会化和去力度化。

过去几个月以来，因为疫情的影响，很多人在家上班，也有研究指出，在家上班的效率也许是更高的。我们当然不去说生活跟工作混同这个问题，这个先撇开不说。在未来，我相信各个商业机构也会发现这样一个情况，当我的员工在家里工作效率没有特别变低，甚至更高的时候，我是不是有必要每天把大家放到一起来。

当员工在家也能够做事情的时候，那么这个员工是不是非得是我的雇员，我认为这个变化很快就会出现，以后极有可能说我们会通过各种各样的社会服务来实现软件的整合。

在这个过程当中，每个人提供的服务就会更加的个体化，我们服务力度会变小，每个人提供微小的服务，这些微小的服务如果放在软件开发的情况里面来看，就变成一家公司。

这些程序员一定是遵循某种敏捷的模式，而且他的代码一定是整洁的，一定去符合一个持续提升的观念。当其中任何一小部分程序员发生变化的时候，一定有新的人员可以方便来接入。

在这个变化的大趋势里面，我认为整洁代码将会为软件从业人员，尤其是程序员，让你具备一个适应变化的基础能力，千万不要觉得说代码写的快就好，未来一定是持续交付的，在持续交付的环境里面你能不能去适应，我想这是给我们最大的一个启发吧。

文武双全，方为正道

分享嘉宾： 余晟

长期在互联网行业尤其是后端开发领域打拼，经历了从个人贡献者到团队领导者的转变，对技术的价值和定位也形成了自己的看法。业余时间写作、翻译、审校了若干技术图书，对技术文化建设方面也有一些经验。《代码整洁之道:程序员的职业素养》译者。

观点提要：余晟老师以自身经验出发，讲到程序员的“文武之道”，从追求专业性、不随便承诺、敢于拒绝等方面深入讲解了一个程序员应有的职业素养。

主题由来

这个主题来自于我自己很长工作以后，对经验的总结和感悟——把自己定位为一个能写代码的管理者。

“武”其实是非常容易理解的，就是我们说的硬功夫，你编码有多快。而关于“文”的方面，很长时间之内其实是被程序员所排斥，或者内心是有所抵触的。翻译了Uncle Bob《Clean Coder》这本书之后，我才开始慢慢意识到我们必须要做一个文武双全的程序员，这对我们的职业发展是非常重要的。

程序员应有的职业素养

企业让程序员以代码为工具，运用数据结构和算法去开发系统，最终创造价值。

这样的过程中，整个价值链中间还有几个更重要的因素，第一个是企业，第二个是创造价值，程序员的工作是在这样一个大的视角里面才能够真正的体现出价值。

1、专业对于程序员来说非常重要

这本书强调的第一点，专业对于程序员来说非常重要。你越会编程，你的系统越复杂，你的能力越强大，对于外人来讲，对你的不安全感也就越深，也就越强。

这个时候只有你体现出足够的专业素养，你才能够跟更多的人合作，你才能够赢得更多的机会，你也才可以得到更大的利益，这一点是我希望所有做开发的朋友都应该要意识到的。

2、内心要有对专业的追求

我也看到很多程序员吐槽，说培训机构或者怎么样怎么样的人，他们能写代码，就来抢我们的饭碗了；或者希望能够保持当前的水平、当前的收入就ok了，没有更多的追求，所以当你提高对他的要求的时候，他会觉得不值，觉得没有意义。

我想说的是，随着你工作时间的增长，只要你内心对专业有追求，你的专业素质在不断提升，你的竞争力就不会受到影响，所以我们内心一定要有对专业的追求。

Uncle Bob在这本书里面也讲到了，你一周如果工作40个小时，那你至少是要投入其它的20个小时来提升自己的专业素养。

一周工作只有40个小时，对很多人来讲是奢望，但是我仍然希望大家能够多出足够的时间，来尊重自己的专业，花足够的时间来追求自己的专业。

3、不随便承诺，承诺必须靠谱

程序员怎么估算工期呢，其实是一个非常简单的事情，就是你让经验最丰富的程序员，你问他说做这个事情要多长时间，比如说他说18个月，你得出来的结论是18个月乘以2，就是36个月，然后再加两个月就是38个月，这38个月大概是一个比较靠谱的估计，这充分说明了我们程序员承诺的可靠程度是什么样的。

还有关于质量的判断，程序员交付出去的很多东西，说做好了、做完了，这个“完”其实是非常广泛的描述，有的人说的做完是代码写完了，有的人说的做完是测试做完了，有的人说的做完是能够部署了，还有的人说做完是确实能够上线，没有问题了。

Uncle Bob在这本书里面强调的是说，我们如果要做一个专业的程序员，我们就不要随便承诺，当我们说做完的时候就真的是做完了，这个东西可以交付了，而且可以上线了，完全没有问题了，达到用户能够正常使用的程度，你才能够叫做完，否则你的承诺就是不靠谱的，一旦你的承诺不靠谱，你的专业形象就会受到影响。

他还专门提到了一个东西，就是不要随便说试试看。我知道说试试看的时候，程序员表达的意思是说大概能做成，大概也做不成。但是对于外人来讲，对于跟你合作的不懂技术的这些人来说，他认为有80%-90%的几率是能够做成的，所以我们一定不要随便说试试看，说可以就可以，说不可以就不可以。

4、敢于拒绝

别人提了一个需求，你拒绝的时候，很可能争论的焦点就会变成你到底有没有本事。很多人会不愿意承认说我能力不到位，我没有这个本事，于是他就会把这个问题接下来，或者至少他不会当面拒绝。一旦你没有明确的拒绝，对其他人来说就意味着你同意了。

这样的同意，其实本身就蕴含了非常多的矛盾和冲突，这也是后来非常多的冲突，包括矛盾发生的根源。

所以，对于程序员来讲，你一定要有明确的概念，就是说我敢于拒绝，这个东西我不做，不应该做，我们不要做这样的事情。

又很多人在问怎么样说不呢？我没有办法说服其他人说不行，虽然我知道这样做不行，但是我没有办法说服其他人。

这点就引申出来Uncle Bob讲的下面一点，对于程序员来讲，理解业务其实是我们终极的追求。

一旦你能够站到业务的角度，一旦你能够从利益的格局里面去看待你的工作，你就会掌握更多的话语权，所以我希望大家能够充分的意识到这一点，遇到沟通困难的时候不要缩回去，你要勇敢去理解义务，然后你才真正能够获得更多的话语权。

正本清源：Bob大叔欲对敏捷行业清理门户

分享嘉宾： 申健

 优普丰敏捷学院首席敏捷教练，自2007年开始敏捷实战。国际Scrum联盟CST培训师和CTC认证教练，极限编程实践者。擅长结合教练技术等软技能助力金融、通信、互联网企业进行敏捷转型咨询和落地。《敏捷整洁之道:正本清源》译者。

观点提要：申健老师以“Bob大叔对敏捷清理门户”这样极具话题性的主题，展开讲解了人们对敏捷的误解，批判了大型伪敏捷，最后给出了敏捷在企业落地的建议。

主题由来

敏捷这个概念太火了，吸引了方方面面的人进来，传统的咨询行业，一些卖工具的都来了，都打着敏捷的旗号，把这个行业就搞乱了。

所以Uncle Bob在这本书里讲了业务实践、技术实践、团队实践，然后告诉大家我们本来的敏捷是怎么回事，不是你现在卖的那套东西。

对敏捷的误区

对敏捷最大的一个误区——敏捷就是快，用了敏捷以后，原来3个月的项目，我现在一个月就能做出来，那都是不可能的，那都是骗子。

敏捷其实是想要打破原有传统的瀑布式工作方法，以前很多公司的项目开发流程都是先做需求，把需求都搞清楚，再做开发，然后再做测试，然后再做上线。

你会发现这个方式并不适合于软件开发这种智力型的、创造型的行业，早在1970年，这个人叫Waste loise（014510），他写了一篇文章，批判阶段性get basic process，说这个方式不适合，结果瀑布模型流传到现在，很多公司，包括我们一些客户的公司仍然还是这样一个开发模式。再加上2000年左右，由于CMMI传入中国，不能说它们没有作用，当时可能是对中国的软件工程行业也起了一些作用，但是逐渐就演化成一种企业自治的一种方式，咨询师跟评估师串通一气，给你刷一个证，最后发现能力完全还是没有提高。

 

在现实中，人们对敏捷现在还有其它的期望。

第一，我抄。我没有什么创新能力，但是我抄竞品，比比皆是。Uncle Bob说了，敏捷不见得能帮你少花时间，只是能让你该去抄哪，你抄作业得抄对了吧。

第二，少招点人，资源利用率提高点，这也没有错，但敏捷不见得能帮你提高产能，只是能增加一些可管理性，可管理性来自于哪呢？来自于透明性，信息可视化、透明性，然后你才有机会做检视和调整。你如果信息不够透明，你也没有机会检视、调整。

第三，按时上线。按时上线当然也挺重要，但是敏捷不见得能帮你确保时间，它只是摧毁你不切实际的幻想。什么叫不切实际的幻想？就是我到每个时间点，我想要的东西都能上去，不太可能，即使都上去了，通常你也会得到程序员的偷工减料，因为程序员都是高智商人士，他们是非常清楚如何偷工减料，所以你逼他，他就会给你采取那些办法。

第四，营业额。用了之后，我的经营业绩是不是能提升，营业额增加了，客户量也增加了。恐怕不行，敏捷只是能让你更早的知道你哪个产品方向行不通，但是并没有办法让你知道你哪个方向能够行得通。

而且敏捷是一套工作方法，它能够助力你业务功能上线、交付，但是它与营业额、用户量或者钱的增加，并没有直接的关联关系。

最后要讲的一点，不管是极限编程还是Scrum，他们都是一些框架和实践集。但我们很多客户想要落地，要的是敏捷转型或者叫变革管理，这是正交的两回事。在这里先放一句，你要分成两个角度去看，实践集放在那里，但是我们怎么走过去，这是另外一回事。

不管是哪种方法，都是通过一种叫做加速反馈机制来破解复杂性，为什么要敏捷？大家常见的需求经常变更、软件质量差、可维护性差，导致项目失败率。

首先他们讲需求没有不变，因为业务就是在变的，因为市场是在变的，所以不要幻想说我代码能够整整齐齐写干净，然后放在那里供起来，这是不可能的。

第二个就是你的团队、人员、资源能力是一个动态的变化，人员有流动，今天走俩，明天来俩，太正常了。这个敏捷就靠什么呢？就是我们走一步看一步吧，“天下难事必作于易，天下大事必作于细”，你把困难的事拆成简单的，大事拆小，才能够去应对，敏捷里面就能把大的组织拆成小团队，把大的产品需求拆细，拆成用户故事，拆成小任务，把大的时间周期拆成小的、迭代的周期，然后把代码也写的越小越好，都是在破解复杂性，就是反馈机制才是敏捷的根本。

批判大型伪敏捷

市面上有一些方法论，号称叫规模化敏捷，套了一个敏捷的帽子，其实就是原来的瀑布改了名字，仍然是一个传统的矩阵结构，这是一种误区。

还有人说敏捷宣言没区分IT敏捷还是业务敏捷，他就没搞明白，IT敏捷和业务敏捷之间是不是一回事，IT敏捷是干什么的，软件开发敏捷是怎么达到的，是通过屏蔽验证达到的，把代码写清楚，然后通过咱们讲的持续集成、开发迭代，去看跟需求方讲的是不是一样的，是不是人家要的。

业务敏捷是什么？你的诉求是说我的公司能够在市场环境里面增强能力，听起来没错，但是业务方向，战略上其实不一定是通过迭代来进行或者达成的，它可能是通过资源交换来达成，另外它可能是通过广撒网来达成，所谓广撒网就是我孵化好几个业务方向，我看哪个行我就做哪个，像腾讯叫赛马机制。

Martin Fowler当然也是极限编程，和Uncle Bob一样，是极限编程的发起人或者是主要成员之一。他们都在喷SAFe的一个所谓规模化敏捷的东西，包括敏捷宣言其他创始人都对这个东西Say No，说这个东西根本就不是敏捷，套上敏捷的帽子来骗人。

Uncle Bob在《敏捷整洁之道》这本书里讲了一句话，他说敏捷是解决小团队的问题，不是解决大团队的问题，他说大团队、大项目的应对之道，几十年前就已经解决了，怎么解决？咱们讲的矩阵式结构、层级式结构，这就是解决之道。事情分解，已经解决了，但是小团队如何协作的问题没解决，这是提出敏捷的原因。

敏捷在企业的落地

所谓敏捷规模化，在大型产品里面多团队合作、多人合作的时候，解除依赖才是敏捷应对之法。

架构怎么组，不是说我画一个所谓的规模化敏捷图形架构问题就解决了，他一定是靠不断的沟通，跨团队的协调机制，你放一个集中化的架构团队架构师，仍然解决不了这个问题。

剩下还有一些组织的转型、组织障碍的移出、内部社区等等还有自动化测试这事怎么做，都知道自动化测试好，都知道重构好，大型遗留代码，几年甚至十几年留下来的，想补，别说想补重构，补自动化测试，你看都看不懂，人员流动你看都看不懂，你怎么补，所以这也有一个策略的问题。

另外就是绩效考评，这个在企业中是绕不开的，敏捷方法，各个方法都没有提到说应该怎么考评，那我觉得绩效考评根本也不是敏捷要去直接解决的问题，他就是看你公司的导向，你想公司业绩是什么样的或者工作方法像什么，你就考核什么就行了。

另外还有一些配套的事情，包括我们给一些企业做落地转型，发现产品经理能力不行，或者BA需求分析能力不行，就是编程基本功的问题，最后都会落到基本功的问题，你就是不会，你用什么方法论他也做不出来。

程序员的基本功写代码，你知道程序员最头疼的事就是起名字，再加上英语不好，业务领域知识不知道，就只能起到像Run、Process、Handle等等这个水平。Uncle  Bob在之前的一本书也提到你要想知道代码质量的好坏，就是数数这个程序员在阅读别人的代码时心里骂了多少次WTF。

怎么练基本功，Uncle  Bob提出来极限编程，现在市面上其实也有一些练基本功的培养的方式，包括线上线下的基本功练习，程序员练功房、工具箱练功房等等，Scrum联盟他有一个CST的课程也是在讲这些极限编程手艺，还有一些朋友在做直播，直播就是写代码，直播做重构，直播给你讲集成，这些都是值得大家去参考的一些资源。

另外还有敏捷合同，敏捷合同像Scale Lam等等给出了一些合同的思考和模板，因为你如果像传统像项目管理签的这种合同，时间范围成本都定死了，当不可避免的需求到来的时候，你就没有任何变化的余地，所以敏捷合同签署也是有一定学问的。

最后是教练式的领导力，这个特别有意思，在Clean  Agile这本书里面，Uncle  Bob除了讲团队实践、基础实践和业务实践之外，特意开了一章讲敏捷教练的事情，我理解他以前这些事情管理的东西其实不是特别在意，但是现在随着敏捷教练行业的兴起，他也提出了一些自己的想法。

我们知道市面上比较流行的敏捷教练的入门学习可能就是美国Scrum联盟CSM培训认证，但是上了这么一个课并不代表你对敏捷有了了解，只是一个入门。再往上就是要真正成为一个敏捷教练要发展自己的软技能，软技能通常指Patient会议引导的技巧，还有coaching教练式对话的技巧，包括教练式领导力的技巧才是帮助人们慢慢去转变的一个方式。

总结一下，用Uncle  Bob这句话说，敏捷是一种帮助小团队运作小项目的小方法，任何大项目都是由若干小项目组成的。所以以小见大，梦想要大，步子要小，别总扯什么大型敏捷，大型咨询，没有用，先把小团队运作好了，然后慢慢暴露组织中的组织结构问题，互相依赖的问题，去推进整个组织或者更大范围的转变才是正道，上来就想搞一个大型敏捷框架也好，实践也好，往上一套基本上就是输在起跑线上了。

所以我也奉劝行业中的各位敏捷教练，包括我们自己，一起共勉。还是先把小团队的敏捷之道搞好，如果丢了代码年头太多，想法拾起来，如果没有任何代码基础，给别人做敏捷咨询的话，最好先学学潘石屹，了解一下程序员的工作情况才能更好的理解敏捷到底是怎么一回事。我想分享的内容就这么多。