作者：许晓斌(晓斌)

两百多年前苏格兰出了一位大哲学家，他的名字叫做亚当·斯密。今天人们对他的了解更多是在经济学家这个身份，都认为是他发现了“看不见的手”这一神奇的经济规律，以及他那本著名的《国富论》。然而除了这本书之外，斯密还出版了另外一本巨著——《道德情操论》（The Theory of Moral Sentiments），这是一部难得的哲学以及文学佳作。值得一提的是，我认为此书可以帮助我们去理解当代软件工程遇到的各种问题，也可以帮助我们探索一些解决之类难题的方法。

一、同理心

现代社会流行 ”同理心“（或称”共情“）这个词，这个词用英文来表达是 _empathy_，例如我们在街上看到一对久别重聚的恋人，他们快乐的笑容，能够让我们会心一笑；而当我们看到有人因为罹患重病而一筹莫展的时候，我们也会发自内心地感到伤感。

当然，我们共情他人的快乐、悲伤、愤怒，除了因为这个人表现出来的情绪之外，还因为理解他表现情绪的动机，并且其动机是合理的。例如，如果某人因为被不小心撞了下，就愤怒地拿出刀来要去刺那个撞他的人，那么我们就绝不会共情这种愤怒；但是如果某人的妻女被人强奸，而他愤怒地拿出刀来要去刺那个伤害他家人的罪犯，我们都是能理解并认可这种愤怒的。

虽然人都有共情的能力，但能体验到的他人的快乐和悲伤的程度，相比自己的切身体验，往往是很弱的。一个病危的人的无助和孤独，陌生人即便在当场观察良久，能体验的到无助，恐怕还不到十一；一个中彩票的人的狂喜，旁人所能有的快乐体验也是很弱的，有的甚至还可能会有妒忌的情绪。

作为情绪的感受者和表现者，当我们的快乐、悲伤、愤怒等情绪，被周围的人所认可，那么我们的快乐会加倍，我们的悲伤亦能的到缓解，我们的愤怒亦能被认可是正当的，进而得到发泄。

在斯密看来，社会的奖惩机制，就是基于社会中人与人的共情原理发展而来的。当一个人，出于良好的动机，做出一些行为，并让他人收获舒服和快乐，那么旁观者就能共情到受惠人的舒服和快乐情绪，也能理解施惠人的良好动机，那么就会同意奖励施惠人；当一个人，出于不良的动机，做出一些行为，并让他人收获痛苦和悲伤，那么旁观者就能共情到受害者的痛苦，也不会赞同施害人的不良动机，那么就会同意对施害人进行惩罚。

奖励的例子有，小河边路过的青年看到水里有落水的儿童，他出于救人的动机，实行了救助行为，最终儿童得救，儿童一家逃脱厄运，作为旁观者的我们，都会赞同对这个青年给予奖励；就惩罚而言，所有犯罪案例都是例子，例如路边有人看到商店里的手机，为了满足自己的私欲，实行窃取行为，对商店的主人造成了损害，那么作为旁观者的我们，会同意对盗窃者施行惩罚。

二、道德观与软件研发

基于同理心，人与人之间渐渐形成了奖励和惩罚的共识。斯密认为所谓道德，就是这么一些共识（或者说规则），当社会遵循这些共识的时候，整个社会就欣欣向荣。而那些无法形成良好共识，或者说共识得不到社会遵循的时候，那社会的发展就会出问题，渐渐走向衰落。斯密写作比达尔文早了一个世纪，但是这里我们能看到进化论的影子，即，对于自然（或曰上帝）来说，能进化出道德的社会才能让这个社会更好的适应自然，进而繁荣。

社会中，人与人相处，不能只考虑自己的情感而无视他人的悲欢。人在考虑自己感受的同时，也必须学会考虑他人的感受，并做出有益他人的行为，如此整个社会才能繁荣。

让我们回到在软件研发这件事情中。类似的，开发者不能只考虑自己，也不能只考虑机器，他必须要学会考虑其他开发者的感受，做出有益于其他开发者的行为，如此整个研发组织才能繁荣。许多开发者会错误地认为，软件只要能运行起来就没事了，和机器有关，和其他人无关；但每个人只要想想自己在过去一年中阅读了多少其他人写的代码，维护了多少其他人交接的系统，就会明白这种想法是多么的错误了。没有开发者是从零开始编写软件的，在大型组织中，开发者每天都依赖其他开发者的中间产物进行工作，而自己也在不断生产中间产物，这些中间产物包括：

文档：描述系统是如何设计，描述 API 是如何使用的。当研发工作依赖一个现有系统的时候，就必须要理解现有系统的设计，尤其是当需要对这个系统做改造的时候，就必须明白设计的核心模型。

代码：无论是使用他人提供的 service（及 client），还是使用中间件框架，还是接手遗留系统。进行新的研发工作都需要去深入理解这些代码，这些代码是否容易理解，是否引入不必要的依赖，是否有足够的测试覆盖（因此容易修改），都会很大程度上影响研发的效率。

服务：上层的业务会依赖大量的下层服务，尤其是在测试阶段，下层服务的质量和稳定性会对测试工作的效率造成极大的影响。比较底层的一些服务，如缓存，消息等，现在通常都是云提供的，而这些服务的质量往往都比较高。

当我们在日常研发工作中，使用到的软件中间产物，在其质量非常高的时候，我们会由衷地对于这些中间产物的作者生出感激、敬佩的情感；而在其质量非常差的时候，我们则会从内心泛起对中间产物作者的厌恶、鄙视之情。

而当组织中的每个人，作为中间产物的作者，能在生产和交付文档、代码和服务的时候，时刻考虑到这些文档、代码和服务的质量，会对其他的开发者产生重大的影响，进而约束自己的行为，用更高的质量标准要求自己，以期待从中间产物的使用者那里收获赞许和感激，而非厌恶和鄙视，那么这个组织就形成了良好的软件研发道德观。

三、Postel's Law

计算机领域中有一条可能不那么知名的设计原则：Postel’s Law（也被称为 Robustness principle）：

> Be conservative in what you do, be liberal in what you accept from others.

这条原则最早是 Jon Postel 在 TCP 协议中描述的，当计算机之间通过协议通讯的时候，对于其他计算机发送给自己的内容，要考虑各种异常、不规范的情况，即要主动消化各种复杂度；而当自己给其他计算机发送内容的时候，则要有严谨的 Spec，并且严苛地遵守 Spec。

虽然 Postel's Law 讨论的范畴是系统设计，但我认为要形成高效的研发团队，人与人之间的协作也应该遵循同样的原则，作为软件中间产物的作者，每个研发都应该对自己的产物提供清晰的 Spec 并严格遵循这些 Spec。只有 “be conservative in what you do”，那么一层层往上的研发工作，其效率才能够得以保持（甚至提高），否则的话，最上层的研发工作就犹如在一个摇摇晃晃的梯子上装灯泡，其效率之低可想而知。

四、软件研发道德的失效

前文我尝试说明：软件中间产物的质量（包括文档、代码和服务）对于研发组织的整体效率是至关重要的；良好的软件研发道德，或者有时候也会认为这是良好的工程师文化，就是大家形成一种以交付高质量软件中间产物为荣，以交付低质量软件中间产物为耻的共识文化。

然而在实际的情况下，我们往往看到很多组织未能形成这种共识文化。相反的，系统无清晰的设计文档，为了快速上线代码不做 code review，系统不做充分测试，代码没有单元测试覆盖，为他人提供的 client 加入了大量无关的依赖，种种现象司空见惯，简直可以用罄竹难书来形容。

当研发遇到这种软件研发道德失效的情况，往往会觉得沮丧、无力甚至愤怒。一些人因此觉得研发环境恶劣、团队缺乏吸引力、领导无能；另一些人觉得工作就是如此，尽管不理想但也默默接受并习惯。试图改变不理想的现状，但是失败以至于离开；或者对现状感到麻木并习以为常，似乎是再常见不过的结果。

如果我们再思考一下斯密关于道德形成的理论，就能够理解为何组织中软件研发道德会失效，这种失效的直接原因是：

1. 生产高质量软件中间产物的行为没有得到应有的奖励。

2. 生产低质量软件中间产物的行为没有得到应有的惩罚。

当我们和任何一个研发的 TL 讨论软件质量的时候，没有一个 TL 会和你说软件质量不重要。但是我们都明白，一件事情的关键不在于那个人怎么说，而在于那个人怎么做。而怎么做具体就体现在：当质量和其他因素的优先级发生冲突的时候，这个 TL 会如何做出选择；当 TL 给团队做绩效评定和晋升的时候，是否研发质量作为一项核心的考核指标。

而在软件研发道德的失效的组织和团队，我们无一例外地看到：当质量和时间发生冲突的时候，优先级被放在了时间上，质量被牺牲了；当质量和功能范围发生冲突的时候，优先级被放在了功能范围扩大上，质量被牺牲；在做绩效评定的时候，并没有认真考核研发在质量上做的贡献，换言之，对一个研发同学的短期业务结果，规划思考能力，质量贡献等角度综合评定的时候，质量贡献往往被忽略了。

我以前一直认为软件质量的问题，研发效率的问题，是技术的问题，是因为先进的技术没有得到理解和应用；但是行文至此，相信大家能理解，我的观点已经发生了改变，软件质量和研发效率的核心不是技术问题，而是一种类似社会学的问题，是人的问题。

五、应该怎么做？

既然是人的问题，就必须从改变人的行为入手，这里首先要让质量的信息透明化，其实是要让质量相关的行为得到应有的评价。透明化是合理评价的前提。

无论是敏捷软件开发的方法论，还是精益的方法论，都强调 Build Quanlity In，这句话的意思是，质量是在每一个过程细节中建设起来的，只看最终的软件产品的质量，或者结果质量，是不行的。一旦过程质量被忽略，大量的返工，大量的问题修复，会严重影响产品交付的速度。

今天大部分组织都非常关注结果质量，最典型的就是服务的可用性，客诉等等。这本身没有问题，但令人失望的是，似乎很少组织保持了对 Build Quanlity In，对过程质量的足够关注，这些信息没有得到清晰透明地展现。因此要将过程质量透明化，在软件研发过程中，具体包括：

代码全面开放：让每个研发提交的代码都能被其他人看到（git blame 是个很好用的命令），代码质量的好坏自然一目了然；
开发文档全面开放（也需要有版本化记录）：让每个研发的设计和思考都能被其他人看到；
Code Review 机制的推行，让代码进入主干之前都能被同事认真审视；
CI Dashboard：是否有足够的自动化单元测试覆盖等等，也得到透明的展示。

质量信息透明只是第一步，第二步是信息的透明和激励机制挂钩。这就好比，假设我们白天在马路上都能看到有车闯红灯，但实际上闯红灯不会被扣分罚款，那总还是有很多人会继续闯红灯的的；再好比我们看到有人在马路上扶起倒地老人，我们都知道他做了正确的事情，可是当老人不感谢他反而讹诈他，而且没人出面帮助他证明的时候，此人再高尚也不会继续施行善举。

因此组织在绩效评定的时候一定要把研发人员的软件质量贡献纳入核心的考核标准。但这个时候问题又来了，主管是否有能力评价团队每个研发的研发质量？或者说，主管是否关心每个研发的研发质量？

我想表达的第一个观点是：主管的核心职责之一应该是关心研发质量，因为这决定了组织的研发效率，不关心这一点的主管，是不称职的。

我想表达的第二个观点是：主管不一定有能力全面评价团队每个研发的研发质量，因为有些团队规模较大之后，主管对于细节的把握就有心无力了，但是这个时候他可以做两件事情：