两百多年前苏格兰出了一位大哲学家，他的名字叫做亚当·斯密。今天人们对他的了解更多是在经济学家这个身份，都认为是他发现了“看不见的手”这一神奇的经济规律。以及他那本著名的《国富论》。然而除了这本书之外，斯密还出版了另外一本巨著——《道德情操论》（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 给团队做绩效评定和晋升的时候，是否研发质量作为一项核心的考核指标。
而在软件研发道德的失效的组织和团队，我们无一例外地看到：当质量和时间发生冲突的时候，优先级被放在了时间上，质量被牺牲了；当质量和功能范围发生冲突的时候，优先级被放在了功能范围扩大上，质量被牺牲；在做绩效评定的时候，并没有认真考核研发在质量上做的贡献，换言之，对一个研发同学的短期业务结果，规划思考能力，质量贡献等角度综合评定的时候，质量贡献往往被忽略了。
内容剩余60%，完整内容可点击下方链接查看：软件研发的道德情操-阿里云开发者社区
阿里云开发者社区，千万开发者的选择。百万精品技术内容、千节免费系统课程、丰富的体验场景、活跃的社群活动、行业专家分享交流，尽在：阿里云开发者社区-云计算社区-阿里云
