《程序员的认知心得》

认知并不是一个新的话题。2021 年知识付费如火如荼，刘润、罗振宇等人通过比普通人高的认知能力获得了他们想要的东西；各个行业咨询公司也站在更高的维度把握行业方向；管理大师通过高明的认知能力让团队勤勤恳恳为他工作。

在不好的一面，一些成功学大师也通过独特的认知能力收割大众，导致参与人高价参加课程换来的是如镜花水月一般的“成功梦”。

对于普通人来说，这些内容并非没有道理，刘润有道理、罗振宇有道理、产品经理梁宁有道理甚至成功学大师陈安之也有道理，但是，合到一起没有道理。或者，今天有道理，明天又没有道理了，后天继续想想还是觉得有道理。

这些道理在生活中无处不在，比如，有人说做人要宁死不屈，也有人说要屈能伸。在建立自己的世界观和认知体系之前，太多的道理反而成了认知负担。

我们如何建立自己的认知体系？

我们并不是首个回答这个问题的人，建立在空想和畅销书之上的认知是非常脆弱的，而且很难形成体系。每一个人都有自己的想法，建立认知体系的过程只能靠自己完成，外界的知识只能提供养分。

古希腊、中国的先秦时期已经诞生了大量的思想家，先秦的思想家即使在科学技术落后的时代，认知能力也比现代的普通人要高。在西方，我们可以学习苏格拉底、柏拉图、亚里士多德等哲学大师的著作和思想；在东方，我们可以学习诸子百家的思想。

随后的几千年时间里，黑格尔、叔本华、笛卡尔、康德、尼采等哲学家为我们建立了浩瀚的思想宇宙，通过哲学我们可以建立强大的认知体系。哲学并非缥缈虚无，建立在哲学之上的认知无比坚韧。

这和软件工程有什么关系，如何利用哲学的认知体系解决软件工程中的问题呢？哲学包含了认识论、逻辑学、方法论等不同的分类，这些内容可以指导我们如何辨别过度的信息、如何找到合适的方法、如何理解业务、如何建模和架构，以及如何处理团队的问题。

亚里士多德的逻辑学可以让我们在沟通过程中分辨什么是诡辩，什么样的描述是符合逻辑的。例如，订单中的商品是商品吗？要回答这个问题，需要深入理解概念，通过概念的内涵和外延来识别软件建模中的陷阱。基于逻辑学，可以让我们更深入的理解概念，不被概念的名字迷惑。

方法论这个词汇起源于笛卡尔的《谈谈方法》^[3]，那么软件工程中的各种方法论说的又是什么呢？例如，笛卡尔在《谈谈方法》中告诉我们如何分解问题，合理地分解问题和任务是测试驱动开发（TDD）的前提。

哲学分支认识论 ^[4]用主体、客体描述行为，将操作者看做主体，将被操作者看做客体。通过主客体方法可以把代码写的如自然语言一样流畅。定义清楚谁操作谁，使用拟人、拟物的方式来定义代码中的职责，这样的代码更加符合普通人的理解方式。

用哲学理解团队协作也别具一格。《社会契约论》^[5]中，组织是个体权利让渡后的结果。个体让渡了部分权力，以失去部分自由的代价实现团队协作，以换取个体的利益，当个体利益受到损害时，团队就会崩溃。这种认知要比道德、情怀的诠释深刻得多，也有用的多。

哲学思辨无法代替客观世界，哲学离开生活就变得空洞。软件工程产出的成果需要服务大众生活，软件的需求也来源于生活。罗翔老师讲过一个故事，他使用同样的司法案例在学校的课堂上和校外的普法活动中讲，发现普法活动的人民群众反而比课堂上的学生更能理解案例背后的法律原则，因为人民群众的生活经验比大学生多得多，而法律也来源于生活。

软件开发也可以从生活学习。在设计软件模型时，很多模型模棱两可，我们既不知道如何起名字也不知道如何设计。实际上，大部分业务软件的模型都可以在生活中找到影子。对软件架构理解深刻的架构师，往往对生活的理解也深刻。

例如，几乎所有的系统都需要登录，而登录过程中会话的概念对初级开发者不是很好理解，对于架构师来说也不是很好建模。这种情况，我们一般建议在生活中去寻找一些启示，通过比喻来提高认知。对会话的理解可以想象为开车上收费的高速公路，进入收费入口时，工作人员会给驾驶员发一张卡片，这张卡片就是这辆车行驶在这条高速公路的凭证。

还有一个例子，有一个需求是“当群组没有成员时，这个群组不出现在群组列表中。”如果按照编程的惯性思维，会很容易写出性能低下的代码：群组列表的每一次展示都需要过滤没有成员的群组。

回到生活，这个例子可以理解为最后一个离开办公室的人需要关灯，群组就像办公室，列表中元素的可见性类似于办公室的灯光。作为上帝，让每一个观察办公楼的人自动忽略无人的办公室太强人所难，而制定一个规则让最后一个离开办公室的人关灯则非常好理解。通过生活中的例子，有时候非常容易理解技术方案。

不以生活为师，很多需求就是伪需求，很多架构设计也是伪架构。软件产品设计的很多交互和环节是现实生活中确实存在的，如果产品经理 "创新"的发明一些特色的流程，用户可能反而不买单。

比如，现在的智能电视需要搭配机顶盒一起使用，机顶盒和智能电视系统中有非常多的功能还彼此重叠，但是很少人使用这些功能。智能电视不仅不智能，还变得极其复杂，让家里的老人打开电视都非常困难。从软件工程上来说，它是失败的。

但是反过来看，从商业上来说它却算非常成功，这些功能即使消费者不去使用也必须对它付费。所以，不能仅仅使用软件工程中的思维来理解，应该使用更高的认知尝试理解它。

黑格尔在《法哲学原理》^[6]中有一句名言，“凡是存在的就是合理的”，不过这句话容易被误解成“存在的就是正确的”。这句话合理的理解为，“凡是存在的东西，都是现实的”。我们不能理解一些事物说明还有一些隐藏的规则没有被发现或认识到，当这些隐藏的规则不存在后，这句话就变成“灭亡也是合理的”了。

在认识事物时，需要认识到事物的反面，然后认识到反面中值得肯定的东西。在哲学上，我们把这种认知方式叫做“否定之否定”，在生活中充满了无数的“否定之否定”。

为什么我们陷入技术问题很长时间，当开口向同事求助时，刚起身就想到解决办法？

同样的行为也发生在心理学案例中，为什么有一些电信诈骗的受害者在完成汇款之后立马就能意识到被骗了，而在之前很长时间都无法意识到，这种现象在心理学中被叫做思维定势。

思维定势无处不在，即使划时代的思想家也无法幸免，当我们获得一种思维方式，就会被这种思维方式困住。特别是这种思维方式在曾经带来过辉煌和成功，它就像长期佩戴的骑士勋章，慢慢的就变成了枷锁。

思维定势可以看做是大脑的一种性能优化，在一个场景中，我们得到了各种结论，大脑就会缓存这些结论，默认这些结论是正确的，而不再质疑它的正确性和留意其他解决方法，这样会加快思维的速度，但是代价是我们很难意识到需要去重新验证看起来明显不可能的结论，即便这些结论是潜在可行的。

每一次打破思维定势都是一种认知升级，踏上下一个阶梯的方法是离开上一个阶梯。可以引入旁观者来消除思维定势带来的认知局限，这就是为什么大型企业需要引入咨询师的原因之一，这些咨询师甚至没有行业背景，没有客户本身那么了解问题上下文。相反来看，没有背景反而可以跳出思维定势，提出一些富有建设性的意见。

这给扮演旁观者的人提出了挑战，旁观者需要足够高和不受限的认知能力，否则提出的意见也是局限的。如果咨询师能扮演足够灵活的旁观者，将不设限制的选项摆在桌子上，就能将咨询师的价值最大化。

在中国的古代，决策者意识到自己的认知局限性，他们的谋士（相当于咨询师）发明了一种有趣的思维方法叫做奇门遁甲。奇门遁甲往往被当做占卜、军事工具，其实它更像是一个形势分析工具。

奇门遁甲中的甲代表首领，遁甲的意思是需要把自己从当前的形势中隐藏起来，奇门的意思是事物发展的方向。奇门遁甲的局势相当于当前处于的环境，通过旁观者的形式观察自己的处境和周边事物来寻求突破。

认知提升需要特别的条件：认知提升的动力、合适的环境以及收集足够的信息。哲学类书籍没有任何门槛人人都能获得，五彩斑斓的生活提供了充足的锻炼环境。在三者之中，缺乏认知提升的动力是认知提升最大的障碍。

在自然环境中，生存为生物提供了进化的选择压力；在社会中，所面临的困难提供了认知的进化压力。《侏罗纪公园》系列电影中马尔科姆博士说"生命总会找到出路”，这句话深刻而残酷的诠释了进化的逻辑，可能他没有说出的下一句台词是“没有找到出路的生命会被终结”。

正常情况下，现实中大部分人并没有认知升级的动力，只有在工作和生活陷入挣扎之后才会在无人的黑夜中苦苦思索：是哪里错了，为什么我的策略不起作用？

这些认知的进化压力，可能来自每一次失败、挫折、困惑、嘲讽。一名成为团队 Leader 不久的开发者告诉我，他感到非常的痛苦，这个团队好像一台汽车，但是我却是背着它在马路上艰难前行。不具备理解团队和组织运作逻辑的认知水平，就无法轻松的驾驭团队，好像什么都无法推动，团队越大负荷反而越大。

我并没有帮助到他什么，在后来他理解了 "创造让他人行动的条件，而不是恳求他人行动" 的逻辑后，兴奋的告诉我他知道如何安排接下来的工作了，并把这个认知分享给了我。合适的做法是：他应该分析每个人的动机，驱动团队前进，而不是推着团队前进。

我自己也有过类似的体验，某件事情将原有的认知通通打破。在某个项目上，开始相信自己是对的，后来意识到自己的判断和能力不足以完成这样的工作（后来反应过来前面的认识、选择和判断都不对），遭受到了巨大的心理打击。

但是，请不要忘记那些曾经令我们痛苦的事，那是点燃认知进化之火的完美燃料。

在这个社会中并不缺乏观点。软件开发方法学更是层出不穷，花样繁多，大家为了这些观点提出了各种各样的理由和见解。但有时候在讨论中互相指出对方观点是错的，自己是对的，往往会让沟通陷入困境。

提高认知的第一步是清醒地看待各种各样的观点，选择自己需要的，得到有用的。非常重要的一点是关于对错的讨论，什么的对的，什么是错的。

我相信对错的概念已经植入大部分人的潜意识，我们很自然地使用对错的概念去描述事物，就好像使用高和低，美和丑这些概念来描述事物一样。我们好像不曾学习过它们，而是天生就会。

如果这样去想，就陷入了认知局限。这种认知局限，让我们陷入无休止的无效辩论中。在软件工程中，选择计算机编程语言对技术栈、人员招聘有重大影响，因此计算机编程语言的辩论是一个热点话题。

最经典的问题是：“PHP 是不是最好的语言？”。不可否认，PHP 是一门优秀的语言，虽然这几年略显颓势，但是也不妨碍依然有大量的 IT 从业者使用这门语言。

你觉得这个问题的答案是对的吗？如果你是一名通过 PHP 拿到高薪并乐此不疲的开发者，可能会说对。但如果体验过 PHP 在大团队中因为类型系统缺失而带来协作上的不便，就会说不对。 有过生活经验的人都会慢慢理解到，对错是相对的，所以才有那句名言“小孩子才谈对错，成年人只谈利弊”。

在《老子》中有一句话诠释了这个观点：“天下皆知美之为美，斯恶已，皆知善之为善，斯不善已。 故有无相生，难易相成，长短相形，高下相倾，音声相和，前后相随”。老子认为这些是非的观点是因为比较才产生的，如果没有比较也就没有了对错。在后人的哲学评价中，这是一种朴素地辩证思想，至于为什么是朴素的，我们在以后会聊到。

关于对错的思想，道家的代表人物列子也在《列子·周穆王》中讲述了一个故事。

春秋战国时，秦国人逢氏有个儿子，小时候非常聪明，但是长大后却得了一种迷糊的怪病。他听到唱歌却以为是哭泣，看到白色却说这是黑色，闻到香味却以为是臭的，尝到甜昧以为是苦味，做了错事却以为是正确的。他所想到的事物，无论是天地、方向、水火、寒暑，和常人相比都是颠倒错乱的。一个姓杨的人对他父亲说：“鲁国的君子学问多，也许能治好，你为么不去拜访呢？”

于是这位父亲准备去鲁国，在路过陈国时，碰到了老子，于是对老子说了孩子的情况。老子说，你怎么知道是你儿子糊涂还是其他人糊涂呢？现在天下的人（春秋战国时，礼崩乐坏）对什么是对的，什么是错的已经搞不明白了。也许不是你儿子迷糊，而是天下的人迷糊，甚至是鲁国的君子们糊涂。不要浪费你的粮食，赶紧回家去吧。

要理解这个故事，需要了解一下周朝末期春秋战国时代的历史背景。如果说商朝的社会规则建立在鬼神宗教之上的话，周朝是建立在一套叫做“礼”的规则之上的。“礼”不是礼物，也不是礼貌的意思，而是当时的一种社会规则，简单来说就是“君君臣臣，父父子子”，类似印度的种姓制度之上，每个人都需要恪守社会规则不能逾越。在社会规则之上才有了对错，不符合“礼”就是错的。由于社会生产力的发展，这套规则在当时崩溃了，而新的社会秩序还没有建立起来，这就是百家争鸣的历史背景。

关于对错的认识我们可以更进一步。思考这样一个问题：对错的概念起源于哪里呢？人们从什么时候开始就有了对错的概念呢？

很遗憾，没有在中国古代的资料中找到定义对错的内容，不过在亚里士多德的逻辑学中找到了一些线索。古希腊哲学家亚里士多德，将能判断对错的句子叫做命题 ^[7]，用命题的真假来表达事物的对错。为了得出命题的对错，亚里士多德认为需要将命题放到特定的条件下，通过这些条件才能得到命题的真假。

实际上，现实中人们的对错观并没有这么严谨，大多数情况下的对错并不是一个命题。比如当我们看到一项新的技术，你可能会说"我认为这项技术会流行起来"，并说了一大堆理由，但是这句话并不是一个命题，在短期内无法验证正确性，只是一个人的主观意愿。

《中共四川省委党校学报》上有一篇文章《现代思维模式真假、好坏、对错》^[8] 深刻讨论了人们的对错观。作者提出了一种新颖的观点。作者将真假看做认识事物方面的判断，好与坏是价值形态的判断，对与错就是对人们行为的判断。其实，采用不同的分类方法，就可以获得不同的认知角度，这也是人们讨论问题时难以达成共识的原因之一，这里我们不必评价作者这样分类的利弊（不然又陷入对错的局限中了）。

按照作者的理解：真假是在讨论客观事物是否符合某种规律，叫做合规律性；好坏是从一个人的立场出发讨论事物是否符合他的期望，叫做合目的性；对错一般是对人们行为的讨论，可以叫做合规范性。我们平时使用的对错混合了多种情况，按北京土话来讲就是，我说城门楼子，你说胯骨肘子。

如果用这种认知方法来分析得到的信息会看得更深刻。在某一段时间，一些明星和社交媒体的大 V 号召国人吃素，他们认为吃素是一种更“对”的生活方式，因为可以更健康、减少碳排放。

那么，吃素“对”吗？

这里的对错观混淆了合乎规律性，吃素可以更健康吗？吃素可以有效地减少碳排放吗？这里也混淆了合目的性，大家想要吃素吗？明星说喜欢吃素的目的和我们一样吗？这里也混淆了合规范性，不吃素违法犯罪吗？吃肉会违反一般道德约束吗？

从规律性上来说，吃素并不是很健康，因为人体需要均衡的营养，有一些必要的氨基酸需要肉类的蛋白质才能补充。仅仅中国人吃素也不能有效地减少碳排放，因为中国人喜欢吃的猪肉相对西方人偏爱的牛羊肉来说碳排放更少。

从合目的性上来说，大部分国人并不是素食爱好者，我们在主观意愿上并没有享受吃素带来的好处。根据某些人士曝光，明星宣传吃素是受到了境外势力的影响，花钱让他们宣传中国人应该吃素，达到打击畜牧渔业，弱化国民健康的目的。

从合规范性上来说，只要不吃野生保护动物，吃饲养的肉类以及合法捕捞的渔获并不违法，也不违反世俗的道德。

所以，我们的对错观极其脆弱，如果有人可以混淆这些问题，就可能被人牵着鼻子走，有时候甚至是无意的。在规律性上用伪科学、经验混淆科学，在合目的性上用个体混淆群体，在合规范性上用小圈子的道德混淆大众的道德甚至法律。

我们容易被这样的话术影响：

在社会生活中，他们三者又是联系在一起的。比如：因为根据规律，打疫苗可以降低感染疾病的几率（真），所以对我的身体健康是有益的（好），所以我应该去打疫苗（对）。

所以在和其他沟通时，当一个人说出对错的时候，应该从几个方面分析问题：

比如你对同事说，这份工作太辛苦，我想要辞职。他说对，同意你的说法。一般情况下辞职符合道德和法律，他说“对”的原因是：

如果你们关系比较好，这是有可能的，如果你们处于竞争关系，他说“对”的原因可能是希望你离职，然后他就能获得升职的机会。

因此，在本书中，我们也会谨慎地使用对错这组词汇。因为对错的使用，需要在一定条件下才能有效。如果团队的目的是一致的话，尽量使用合适、不适合来代替对错讨论一个技术方案，用真、假来描述一个规律，如果真、假太过于学术，可以训练自己使用成立、不成立来描述规律。

当然，我们也不必这么极端，在大家都能默契的认同某些条件的情况下，使用世俗的对错也没有什么不对。

阅读本书需要记住的是，就像在序中所说的，不能因为得到了一些新的认知方法，就被新的方法所困住，也尽量避免使用通常意义上的对错来衡量本书的内容。

即使重新建立了对错观念，学会了不那么急于下结论，为了对错和人争辩，但是无法避免的是认知总会受限。这是因为认识事物的过程包括了收集信息、加工信息两个部分，任何一个阶段不够充分都会让结果造成偏差。

收集信息是通过我们身体的“传感器”完成的，也就是身体的感知器官，按照佛家的说法就是眼耳鼻舌身意。收集信息的过程中，充斥了大量的诱导、错觉，让加工信息无从谈起。比如，无糖可乐就是欺骗了味觉感受器，用特殊的甜味剂代替糖类，让人依然感受到甜味。

加工信息是根据我们的经验、思维方法、价值观等复杂机制下对收集的信息做出判断，大脑存在一些隐藏的“程序”，在我们无意识的情况下就能影响人的思维，正是这种隐藏的程序成了我们很多决策的基础。比如，程序员去一家公司面试，如果这家公司的装修非常 GEEK，类似于 Google 等著名企业，面试者就会对这家公司充满好感，虽然装修和雇主质量并没有决定性影响，但是非常影响面试者是否加入一家公司。

这两方面的因素让人的认知有所不同。

历史上的哲学家对我们如何真实地感知世界提出了很多理论，非常令人印象深刻的就是柏拉图在《理想国》^[9] 中记录的洞穴寓言。

洞穴寓言是这样描述的：假设有些人住在地下的洞穴中，他们是一群囚徒，生来就在地下，坐在地上背对洞口，不能转头看到洞口，只能面向洞壁。在他们身后有一矮墙，墙后面有些人形的生物走过，手中举着各种不同形状的人偶。人偶高过墙头，被一把火炬照着，在洞穴后壁上投下明明灭灭的影子。这些人终生都只能看到这些影子，会认为这些影子就是具体的事物。

洞穴寓言告诉了我们每天争论的概念，都是每个人工作、生活背景投射的影子。概念会随着人们对事物认识的加深而变化，尊重逻辑的人不会强行要求某个概念必须按照自己见解来解释（类比中世纪教会对经书的解释权）。

人们对信息的加工在一定程度上取决于有多少可靠的信息被输入进来。在软件工程中，如果 CTO 和架构师从来没有去团队中实地考察，去看看一线的工程师是如何编写代码的，那么就像洞穴中的人一样，缺少足够的信息输入。

比如，CTO 在听取质量部门的汇报后，Bug 太多，认为团队的代码质量太差，要求所有的开发人员使用 TDD，并将单元测试覆盖率要求设定到 100%。实际上可能是因为需求输入就不合理，没有逻辑清晰的需求，即使使用 TDD 也无济于事。

按常理来说，CTO 应该是公司获得信息最多的人之一了，缺乏有效信息的 CTO 就像站在高处瞭望，但是却高度近视。

另一方面，即使有足够多的信息输入进来，处理这些信息的“程序”过于低效或者过时，也无法建立高的认知能力。认知高的人可以通过尽可能充分地利用收集到的信息来分析问题，做到“不出户，知天下”的程度。这也很好理解，如果找到了一些足够好的模型来推理问题，就可以利用有限信息推理出更多信息。科学家也从没亲自去地球外看看地球，是通过一些观测方法和数学来进行推理的。

在软件工程中，每个人大脑中处理问题的“程序”不同，这决定了是否能更深刻的认识事物，并推动解决问题。所以一些高认知的人通过模型来建立处理信息的“程序”，这些“程序”要比本能反应成熟的多。

例如，团队 Leader 在处理团队问题时，如果团队出现摩擦，经验不多的 Leader 会被动地安抚团队成员帮助解决问题。如果换种思路，把团队问题使用一个模型进行抽象，通过“动力-阻力”模型，将这些摩擦看做团队的阻力，将激励团队前进的因素看做团队的动力。

团队起火往往是“动力-阻力”不再平衡，通过两个方面着手，可以向团队注入一些激励的因素，也可以优化团队运作方式，减少阻力，增加润滑。激励的因素不仅仅是金钱，还可以是情感关怀、营造成就感、为工作建立荣誉感等非常多的方式。

如果意识到局限的存在，并打破局限，就可以获得源源不断的方法去解决问题。

那么如何在一定程度上打破认知局限呢？洞穴寓言告诉我们可以从两个方面入手。其一是挣脱锁链走出洞穴，接收更多的信息。其次是通过有限的信息，进行推理，慢慢刻画事物的本来面目（有一些哲学家认为事物没有本来面目，取决于我们观测的方式，一些哲学家反对，整个哲学史都潜在的讨论这个话题）。

第一个方面就是我们通常说的多学习、多听、多看，其实质上是在拓展感知渠道，通过丰富信息输入的方式提高认知能力，所谓行万里路，读万卷书就是这个道理。除了多听多看之外，通过用不同感官获得的信息进行校对也是增加有效信息输入的方法。在洞穴寓言中，如果囚徒能够走近并触摸墙上的阴影，那么能得出不同的结论，认为阴影和通常的实体并非同样的东西。有机玻璃和普通玻璃用肉眼看可能没有区别，但是触摸一下就能发现本质是不同的。

如果仅仅是增加信息接受的渠道，还远远不够。还依赖大量的经验、知识、教训、反馈作为输入。从某种程度上看，年长的人必然会比年轻的人认知能力高，所谓“老年人吃过的盐比年轻人吃过的饭还多，老年人走过的桥比年轻人走过的路还远”。自然地认为学历高的人比学历低的人输入的知识多、信息多，认知相对也较高。

实际上是这样的吗？在一定程度上认知能力和年龄确实存在正相关性，但是也不完全相关；学历高的人在商业上的认知有时候并没有比贩夫走卒强太多。

所以我们也需要关注第二个方面，信息是如何高效、可靠的被大脑处理，建立更好的“程序”。柏拉图的学生亚里士多德说 “吾爱吾师，吾更爱真理”，否定了尚古思维。他认为不应该用世俗的观念干扰对真理的追求，而是需要找到一种真正可靠分析事物、处理信息的方法。这些方法被写到了《形而上学》《逻辑学》《政治学》等诸多著作中，成为了现代诸多学科的种子。

这些学科、方法可以用简化、稳定的模型来理解和叙述，模型是人为刻画的，并不是真理，否则又进入了另外一个洞穴之中。寻找更多、更有用的模型来描述事物的本质，这就是哲学家、科学家一直在做的事。

著名的投资大师、巴菲特之友、伯克希尔·哈撒韦创始人查理·芒格就是应用多模型思维的高手，他总能（模型并不是 100%起作用，只是提高了几率）在有限的信息中寻找到有用的结论。

在叙述前面的内容中，我使用了一个隐藏的模型来描述人的认知问题，简化人的认知为“接收-程序处理”，用这个简单的模型来解释认知差异，姑且比各种“大道理”有用吧。

你的技术决策是理性的吗？

大多数技术领导者、架构师在做出技术决策时都会认为自己是理性的。这无可厚非，软件行业作为现代商业的先锋，基本上代表着先进、科学、理性，好像和宗教、愚昧、迷信毫无关系。

但是有意思的是，如果回头看，软件行业其实充满了狂热、迷信和很多不理智的行为（有部分看似不理智是利益造成的）。从互联网产品兴起开始，几乎每年都会有热点词汇和技术（Buzz Word）。TDD、DDD、低代码、中台、VR、GraphQL 等新的模式和技术层出不穷，这些技术和模式有用，但是在布道者的推动下，大量狂热的追捧者不加选择的采信，因此有人戏称很多软件项目都是面向 Buzz Word 编程。

关于 TDD 有这样一段对话：

如果熟悉哲学史的朋友可能会想到，在经院哲学时期，人们会像下面这样论述上帝是否有用：

如果架构师用这种叙述方式讨论技术选择合理性的话，那么他们对事物的认知还停留在中世纪，还没有跨越文艺复兴的阶段。

不否定 TDD 在一些知名企业获得过成功，但是这不应该是其他团队也以此作为采纳 TDD 的依据。由于知名企业的某种技术实践导致大量的狂热崇拜，在软件工程中，人们称之为货物崇拜编程（Cargo Cult Programming）。

货物崇拜编程是指开发者不明就里、仪式性的使用代码、架构和团队实践，通常是因为开发者被这些实践所带了的收益所诱惑，而没有看到背后的代价，并冷静地思考和权衡，以至于最后付出惨痛的教训。

货物崇拜来源于一个有趣的故事。在太平洋战争期间，美军在太平洋的美拉尼西亚岛建立了军事基地，当时岛上的土著文明还处于原始部落阶段。当时的土著看见美军从“大铁船”（军舰）出来感到很惊讶，同时也看到了美军用“大铁鸟”（飞机）运送物资。由于美军也给了土著人一些现代化的物品，这些物品对土著来说非常有用，于是把美军当做神。

美军离开美拉尼西亚岛后只留下一些军服、低价值的物品，土著遍认为这些物品具有神奇的力量，相信美军还会回来带给他们更多的物品。虽然美军一直没有再回来，但是这些土著发展出了一套宗教仪式，以木刻的飞机为图腾，以美军的军服为法器进行崇拜。

在软件行业，一些技术和实践变成了图腾，一些人将软件成功的因素归结到一个单一实践上。例如，认为使用 TDD 或者 DDD 就能让项目获得成功。

货物崇拜的原因是混淆了因果性和相关性。相关性不等于因果性是科学研究中非常重要的一个原则。举个简单的例子，很多父母信佛，然后小孩高考的时候天天去求神问佛。如果小孩考上了大学，那么就是拜佛的功劳，如果没有考上，那就是小孩不努力。同样的，星座也是一种典型的相关性和因果性混淆，一个人的生日和这个人的性格目前没有证据能说明它们之间的因果性，但是因为选择性认知偏差让人将性格和生日联系到一起。

同样的桥段在各种电视、电影中存在。某一伙人闯入了一个村子，然后这个村子发生了瘟疫，群众认为是这些人带来了不详。软件行业也会有类似的讨论，因为大公司都用的 Java 而不是 PHP，所以 PHP 是一个垃圾语言，我们要成为大公司，所以要把 PHP 换成 Java。所以很多公司明明可以苟一下，却因为折腾死掉了。

另外一种破除货物崇拜的方法是使用逆向思维，当我们采纳一项技术或者实践时，不仅需要分析它所带来的收益，最为关键的是思考它同时带来的成本。

2020-2021 年间，软件行业最狂热的货物崇拜行为就是中台了。阿里巴巴在 2016 年提出了 “大中台，小前台” 的战略，传说中台的概念来源公司高层的一次外部访问（SuperCell 公司）。

热门游戏愤怒的小鸟就是 SuperCell 的产品。这家公司位于芬兰，2016 年以 86 亿美元的价格出售了 84.3% 的股份给腾讯，成为游戏行业史上价格最高地收购案 ^[10]。

这家公司独特之处还不止于此，SuperCell 被收购时还不到 300 人，并且由非常多的小团队组成。这些小团队独立完成游戏的设计、开发、运维，在这些小团队背后有一些支持团队，用来整合公司的资源，让小团队能在短时间内复用公司内部的基础设施快速地让游戏上线。

面向终端的小团队就是中台概念中的前台团队，在公司内服务终端小团队的支撑团队就是中台团队。如果了解过领域驱动设计（DDD）的朋友可能会联想到，这不就是架构中应用服务和领域服务的区别么。

应用服务用于提供具体业务场景下的应用，在阿里巴巴的产品生态下，闲鱼、飞猪就是类似的应用。 领域服务用于提供复用的能力，同样在阿里巴巴的技术生态下，订单服务、用户服务就是类似的服务。

这也是为什么我们在闲鱼上卖出去的东西可以在淘宝网的卖家后台看到的原因，因为他们复用了共同的能力（交易能力）。

因为中台建设给阿里带来了共享技术服务体系，让他们可以一个半月上线自己的团购平台，也就是聚划算。这种架构策略极其具有诱惑性，导致做互联网产品的企业前赴后继，甚至让传统企业在数字化转型的初期就直接进入中台建设。

随着越来越多的企业发现中台战略并不适合他们后，开始放弃这个策略，并发现好像阿里巴巴在开始“拆除”中台。

实际上，大型企业关注平台化建设、能力的复用并非开始于阿里的中台战略之后。例如，网易的课程服务平台，可以将课程能力提供给不同的产品，和国家精品课程中心合作的中国大学 MOOC 就是一个非常好的例子。

另外一方面，阿里巴巴并非否定了中台战略，而是根据环境进行了多元化改造。中台建设的好处是提供了共享能力，但是这种能力过于强大，制约了阿里巴巴的灵活性，让阿里巴巴应对外部环境的变化变得非常困难。中台在阿里巴巴持续存在，只是中台变得更薄。通过牺牲部分复用能力，换取更强的机动性，这是一种妥协，或者说是一种取舍。我相信，他们甚至能构建动态中台策略，中台的厚薄能更加自如调整。

货物崇拜带来一个非常糟糕的效应：一开始绝对肯定的人，在后面变成绝对反对的人，而最初的提出者却很清醒。阿里巴巴董事长兼 CEO 张勇在湖畔大学分享时也说：如果第一天奔着平台来创业，基本上都是死 ^[11]。同样，如果一个企业内部奔着中台做中台，也是死。中台并非没有价值，它描述了一种构建了自己生态体系的企业，如何利用复用的能力去实现更大的价值。问题在于，往中台战略前进时，它早已暗中标好了价格。

奥卡姆剃刀是由 14 世纪方济会修士奥卡姆的威廉提出的一种逻辑学原则，这个原则是这样表述的：

“切勿浪费多余功夫去做本可以较少功夫完成之事”。

按照流行的话来说就是“如无必要，勿增实体”（这句翻译的出处已经不可考）。

要理解奥卡姆剃刀，需要理解当时的历史背景。 14 世纪是经院哲学如日中天的时期，经院哲学为了证明上帝存在性发明了大量的哲学概念和要素，始终讨论无休无止的“本质”。哲学家提出了一个概念，为了解释这个概念需要更多的概念来修补，陷入大量无意义的讨论。

这些讨论非常类似于我国的魏晋时期，魏晋时期人们热衷于讨论玄学，讨论世界的本源。在西方这类讨论被我国的翻译家叫做形而上学，形而上学在亚里士多德的《形而上学》中实际上是“如何做学问的学问”，仍然属于哲学范畴，并非完全一样。

奥卡姆的剃刀原则并非减少了形而上学的讨论，而是将逻辑学、哲学、自然科学、神学分开，他主张不能将神学的讨论纳入逻辑学中。逻辑学是关于概念、推理和语言上的学问，哲学是关于如何思考的学问，自然科学是关于具体事物的学问，上帝的问题留给神学来讨论。

因此，富有逻辑的人应该使用尽可能少的要素来解释更多的问题，而不是无休无止的引入学说，打上大量的补丁。

但是需要警惕的是，奥卡姆剃刀容易被伪科学人士当做工具用来攻击专业且复杂的学术理论。奥卡姆剃刀背后的本质是，对认知理解越深入，需要解释的就越少。甚至有人认为，奥卡姆剃刀的思想触发了随后的宗教改革和文艺复兴。

也就是说，如果我们能找到解释繁杂问题的根本原因，就不需要太多的概念和文字描述。有时候有人洋洋洒洒写了好几千字的文章，但是富有洞见的人却能用一句话表述出来。反过来看，如果暂时不能找到更简洁的理论，就依然得使用现存的理论，寻找终极简洁的理论是目前物理学在始终追求的目标。

举个例子，看似繁复的领导力问题实际上在一些“粗鄙”的江湖人士中，会这样表述：

"别人愿意和你一起干，作为领导者，你能保护他们，且让他们吃到肉。"

这里的肉是一个绝妙的比喻，含义是处于组织中的个体，是以自由的让渡作为代价，换取组织的保护，以获取比个体更多的价值。

保护不仅仅是安全，譬如合理的工作方式、良好的环境都算作保护。在企业工作的员工，并非喜欢打工，而是相比单独讨生活，在公司工作可以获得更合理的工作流程、更舒适的工作环境和更高的报酬。当一名员工可以独立企业之外，获得想要的一切时，他没有动机继续留在企业中。我们并不能使用道德来评价这些现象。

奥卡姆剃刀的启发性是它最重要的价值。在自然科学、社会学的中有大量的案例和应用场景，最著名的例子是爱因斯坦用它大胆的否定了以太学说。

19 世纪的物理学家们，为了找到电磁波和光的传输介质，提出了以太这种假象中的物质。以太最初来自亚里士多德，虽然它的概念随着历史发展不断变化，但是它是非常重要的一种假想物，用来解释是什么填充无穷的宇宙。

但是非常麻烦的是，引入以太这个概念，不仅没有解决物理学的问题，反而让很多问题变得更加复杂。1905 年爱因斯坦大胆抛弃了以太说，认为光速不变是基本原理，并以此为出发点之一创立了狭义相对论。

爱因斯坦因此说：

"Make everything as simple as possible, but not simple。让一切尽可能简单，而不仅仅是简单。"是数学中一种形式

思维经济原则可以看做奥卡姆剃刀的发展，用更清晰的方式诠释了奥卡姆剃刀的本质（注意很多文章将这两个理论混同了）。马赫认为“思维经济是科学的主要任务”，也就是说，如果科学成果不能让复杂的事物简化，那么就没有起到应有的作用。

他认为科学研究是科学模型和待解决问题之间的模写（提取模型）。提取模型就好像做 HASH 算法，将复杂的现实抽象成简单的公式。模写是简单化和抽象化思维，这种思维有经济性（不费力理解的一类更受欢迎）的倾向。思维经济性原则对世界起到巨大的影响，大量的理论出现然后按照经济性被选择下来，人类因此获得更优的理论。

奥卡姆剃刀被应用到最有趣的地方是应用到刑侦技术中，因为往往众多的假设中，对犯罪嫌疑人来说思维成本更低的最有可能，大部分场景下不太可能出现高明、精巧的作案方式。

奥卡姆剃刀也可以应用到软件工程中来，用一些模型简化业务问题。甚至能用模型简化软件开发过程中的模型，这种模型更加抽象叫做元模型，我会在后面专门聊模型思维的时候详细阐述。

作为架构师，需要对技术选型，找到合适的技术组件来完成业务目标。如果使用奥卡姆剃刀原则，就可以剔除思维过程中的杂质，直接对问题寻找更简洁和经济的方案。例如，一个客户找到我们需要建立一个数据湖，实际上当我们分析问题后发现他们仅仅需要一个简单的数据同步机制，而通常意义上的数据湖也具备这样的能力，给客户带来了认知干扰。

有一些违反奥卡姆剃刀原则的原因可能是人们在工作中逐渐忘记了目标和手段。

比如在一个电商程序中，如果一个发货单有 “拣货中”、“打包完成”、“运送中”、“妥投” 等状态，我们需要确保状态的并发操作正确。两个业务动作（打包和物流揽收）会导致系统产生两个请求：

由于种种原因 B 请求先被响应了，A 请求后被响应，如果不做控制，单据的状态就会变成了“打包完成”，而不是我们预期的“运送中”。

有朋友希望引入一套分布式锁机制来完成这个业务。通过奥卡姆剃刀原则来指导分析，我们会发现如果处理 “运送中” 的状态，必须检查已经是 “打包完成” 才会继续，如果条件不满足就让 B 请求报错即可。

在这个场景中，它的目的是避免异常数据的产生，分布式锁并不是目的，可能仅仅是因为习惯引入了分布式锁。这个场景下，其实可以用更简单的方法清晰的解决这个业务需求，节省大量的工作量。

总之，奥卡姆剃刀原则、思维经济原则给了我们一个很好的启示，用来评价什么是一个好的模型。不过，我们总是应该反过来思考，奥卡姆剃刀原则的局限性是什么？

"奥卡姆剃刀并没有说简单的假设就一定更好。^[12] " 有人开始将奥卡姆剃刀当做一种真理，这显然是违背科学原则的。当我们在横向对比诸多模型时，我们可能偏好选择简单的那个，但是需要建立在这些模型都能良好的描述研究对象才行。

在没有更简洁的模型出现之前，也不得不承认我们的认知停留在这里，只能先使用复杂的模型。

面向对象是应用软件设计比较好的方式，可以指导用计算机解决现实中的业务问题，因此是软件开发中的一种主流方式。

不过，用好面向对象则比较困难，即使有数年经验的软件工程师也难说能很好驾驭。大多数人往往是照猫画虎，没有理解软件开发的 “骨相”。

背后的原因在于面向对象是对现实业务的抽象，需要使用者对现实有深入的理解，于是面向对象带有一定的哲学认识论的色彩。

实际上，现代英语、现代法律、面向对象编程都和近代哲学有关，而近代哲学被称为“主体性哲学”，“主体” 概念和主客体关系是非常重要的内容。

现代英语、现代法律、面向对象编程看似三个无关的领域，背后的逻辑却惊人的一致。

在现代英语（古代英语除外）的主要语法是：主语 + 谓语 + 宾语 + 修饰语。想象一下你在一家餐厅吃饭，你点了一份三明治，用一般现在时就是：I order a large sandwich。在这套逻辑关系中，主体就是你自己，客体是三明治，行为是点餐，其他的内容都是修饰成分。

假定你和餐厅出现了纠纷，餐厅忘记给你上了餐，却说已经上了。你发起了诉讼，让餐厅赔给你三明治。在诉讼的逻辑关系中，这是一起民事纠纷，你是民事主体，民事客体就是三明治，诉讼内容是赔偿行为。

而如果软件工程师需要编写一个软件用来处理订单，实现一个收银机功能。可能他会写一个 OrderService 来实现。伪代码如:

这段代码可能会被认为不符合面向对象，因为某些书中，Order 是需要自己来完成业务的。实际上，在这段代码中，当我们认识到主客体关系时，一切豁然开朗。OrderService 是我们的业务主体，Order、User、Product 不过都是业务客体。和民事行为一样，业务逻辑也应该发生在业务主体中，这样就容易理解了。

既然主体、客体思维可以让面向对象更容易理解，我们来严肃的说下这些概念。哲学可能会有一些无聊，不过值得去了解它们。

主体、客体在哲学中的定义是什么呢？按照主流的哲学教科书，可以看到类似下面的描述：

这里需要修正下，随着科学技术的发展，主体可以不只是普通的 “人” 了，可以是一个具有集体意识的团体、网络虚拟世界的一个形象，比如 xxx 公司、初音未来也可以是主体。与之相对的普通人是 “自然人”。

主体、客体思维从笛卡尔时期就开始出现，在康德时期又进一步发展。在主体、客体英文分别是 Subject、Object，它们都是实体，主体是具有行为、感知和思想的一类。

需要注意的是，主体、客体是相对的、动态的。比如用户，在做出一些操作的时候它是主体，当被管理员或者系统操作的时候，它又是客体，这点尤为重要。

关于更详细的主体、客体的知识，我们会在后面大量被用到，在具体使用的场景中再深入探讨，比如业务分析、领域建模、架构设计和团队管理等方面。

当我们理解到主体和客体的思维后，就可以用它分析和指导我们的实践，也就是面向对象的编程了。

我们经常听到很多公司使用方法论这个词，那么方法论是什么呢？

广义的方法论指所有的思维方式，通常包括哲学、逻辑学等。狭义的方法论指解决特定领域问题的方法，比如面向对象算一种方法论。

方法论的起源可以追溯到笛卡尔的《谈谈方法》一书，在这本书中谈到了一些理解复杂事物和解决问题的一般方法，对世界影响深远，是众多方法论的基础。

笛卡尔认为，复杂的东西是简单的东西组成的，理解复杂事物就要先要理解简单事物，然后组合它们。如果复杂的事物理解不了，就回到上一步理解简单的东西，直到彻底被理解后再尝试理解复杂的事物。

分析一个问题，设计一段程序，策划一场活动，甚至只是学习一门技术，都可以按照这种思维进行。分解任务，然后一步一步完成，看起来是最慢的路线，实际上是最快的路线。“大道甚夷，而民好径”也说的是这个意思。

分解可以用作两个地方：学习新的知识和解决困难问题。

对于学习新的知识来说，学校教育最大问题是学习的阶段是固定的，不同认知能力的学生根据年龄分班，导致的后果是学习速度快的学生没有及时的投喂新的知识，学习慢的学生每个阶段都会欠债。

欠债是学习最大的杀手，俗话说就是基础不牢，但是有时候什么是基础这件事情不太好定义。总而言之学习的过程需要逐步铺垫，缺少背景知识会造成了很多学生无法理解新的知识以至于形成厌学的心理。

符合认知的学习方法是：在彻底理解一个知识点之前不要开始下一个知识点的学习，通过大量的练习彻底习惯使用前面的知识点解决问题（做题），然后再用前面的知识解释后面的问题。就像不理解函数的人难以理解导数，更不用说微积分了。每一次新的知识的引入都是在拓展一个人的认知边界，超出认知边界越多学习就越困难，当然学到的新东西也越多，学习曲线也越陡峭。反之，引入新知识越少也就越容易吸收，但是也会显得无聊。

总之，我们只能通过已经存在的认知范围和新的知识重叠的部分来学习，完全超过认知边界的内容我们是无法理解的。这就好比，一个已经消亡的文明留下完全未知的语言我们难以破解，就是因为找不到和现有认知之间的联系。

学习阶段的固定这个是社会资源客观决定的，不可能所有人都有条件通过私教定制课程和教学计划，所以在自学的时候就需要认识到这一点。

笛卡尔在《谈谈方法》中介绍了几个简单的过程：

对于我们学习编程或者新的计算机语言来说，找人推荐一本靠谱的 “Step by Step” 的书，一般这类书都叫做 《xxx Cook Book》之类，一步一步练习每一个阶段的例子，如果无法理解时，回去看前面的知识。

当然，这种方法需要两个条件：1. 这本书靠谱 2. 大量的练习。

对于解决问题方面也是类似的，如果我们没有大量的背景知识和经验，解决起来非常困难。尝试去请教一个熟悉此领域的人对问题进行分解（或者自己完成），将问题分解到显而易见的时候，再尝试解决这些问题。

操作的过程中，将这些分解的子问题写到纸上（一定要写下来或者使用笔记软件）。一步一步尝试解决这些子问题，如果问题还是无法解决，就继续尝试分解。当解决完子问题后，将这些问题合并起来。

如果一些场景下问题难以被分解，就进行假设。不要预设解决方案，将问题或者假设统统地写下来，无论它看起来多么不现实。最后在逐步的对这些问题进行一一验证、排除，直到找到答案。

这就是： “Put everything on the table” 的思想，有时候会发现合适地解决方案往往意想不到，或者被思考的早期阶段否定了。

否定之否定起源于古老的朴素唯物辩证法，被黑格尔首次系统性的阐述 ^[13]。我们不使用哲学相关的“大词”，用通俗的话来说就是通过不断看到问题的反面并来回倒腾加深对事物的看法。

其实敏捷就是否定之否定的结果。举个例子来说，没有任何管理的软件开发是无序的，有任何变化都会被工程师立即响应。大家认识到这种开发模式的局限性后，提出需要约束开发过程，像“瀑布”一样经历分析、设计、开发、测试等多个阶段，让软件开发具有被工程管理的可能性。

这就是第一次否定。

但是随着大家对瀑布开发的进一步认识，逐渐发现其存在实践上的局限性。瀑布开发的局限性是反馈周期太晚，过于依赖原始设计的可靠性。但是实际上，由于人们很难从一开始就做出完美的详细设计，并且也不满足响应变化的要求。

所以人们对瀑布进行了否定，产生了敏捷的思想，这就是否定的否定。可以说敏捷就是克制的在迭代内装了一个瀑布。

那么，敏捷的局限性是什么呢？这值得我们思考，这并非是在否定敏捷的价值。实际上，任何具体的方法论都有其局限性，没有局限性的事物会变成形而上学。

我们否定掉又重新肯定的东西很多，这些东西还经常影响技术选型和对问题的判断。拿非常火的领域驱动设计（DDD）来说，它的局限性是什么？怎么通过否定之否定来分析呢？

领域驱动设计中的充血模型是对 Smart UI 和事务脚本的否定，由于直接操作数据库往往会忘记考虑业务一致性约束，非常经典的例子就是订单的总价需要订单项来整理计算出来，单独修改任何一项的数据都会带来业务一致性问题。

领域驱动中使用聚合来处理一致性问题，在很多人理解的领域驱动设计中，是通过将业务逻辑“充血”到实体（聚合根+实体）中。并对聚合“整存整取”的内存操作来完成业务一致性封装的。领域驱动设计的局限性也在于此——充满理想化的思想让我们掉入下一个更美好的陷阱，“充血 + 整存整取”总是会带来各种各样的问题，因为现实世界没有一个足够大且永不断电的内存。

理想化的方案总是和局限性共存。它俩就像黑白两面，让工程师被梦魇笼罩。被否定之否定的规律支配的事物还很多，当我们得到了一个方案的好处，常常需要在看不见的地方付出代价。中台是另外一个经典例子，中台建设获得了可复用的支撑能力，但是它的局限性是失去了灵活性，因为中台一旦被使用，改起来影响就大了。

那么我们怎么通过否定之否定来对新事物进行分析呢？

否定之否定规律能发挥作用因为事物矛盾的存在，正是因为旧的矛盾就会出现新的方案，当新的方案出现后解决了原来的矛盾，新的矛盾又会出现。分析新的技术或做出选择时，可以从下面几个方面着手：

从这三个方面应该能帮助我们做出一些技术、软件工程上的选择。

以一个真实项目案例来说，某项目是 Node.js 作为主要的开发语言，但是出现了很多 Bug，不够稳定。新的技术领导认为，这是 Node.js 语言的原因，需要换成 Java。结果花费巨大的代价，但效果并不好，实际上是因为软件不够稳定而不是 Node.js 语言的原因，那么这次的“否定”无效。

而有效的否定之后否定就像瀑布否定无序开发，敏捷否定瀑布；网站开发中，模板开发否定了对 CGI 输出字符串的模式，前后端分离否定了模板开发，而后端渲染（SSR）又部分否定了前后端分离。

那么，我们每前进一次，为新技术而满怀激动的时候，带来的新矛盾是什么呢？

我曾经参与一个物联网系统的设计，这其中大家经常会提到一个词“设备”，但是“设备” 这个词在不同的开发者眼里有不同的概念，为此，讨论 “设备” 这个词花费了不少的功夫，最终依然没有定义清楚。

有些开发者认为“设备”是现实中看得见摸得着的物品，另外的开发者将服务器上用于映射物理设备的实例也叫做“设备”。于是，他们在沟通时经常会出现对于“设备”的理解不一致导致的混乱。

另外一个例子是“用户”这个概念。在不同的场景（上下文）下，“用户”这个概念可以是使用软件的大活人，也可以是数据库中的一条记录，也可以是服务中的用户对象，有时候也将用户服务类叫做用户。

这样就非常混乱，不仅无法沟通，而且还导致开发者对系统的认知也变得困难，很多东西处于混沌状态。

在咨询的工作中，我发现非常有意思的是，将软件中的概念一一定义清楚，整个系统的设计工作差不多就完成了。所以设计软件的过程和现实中人们相互交流非常类似。英国哲学家维特根斯坦把人们交流的过程叫做“语言的游戏”，当我们描述事物的时候实际上就是将有清晰边界的元素贴上标签，这个标签就是我们说的概念。

朴素的概念是来源于个人背景和理解，因此概念难以统一。正是于此不同语言之间准确的翻译也不太可能，不同文化背景难以找到合适的概念互相映射。后来哲学家认识到人们认识的概念是由一些更为基础的属性构成的，那可以认为概念就是由属性组成的。比如 “人” 这个概念，有四肢、可直立行走、皮肤光滑等属性。

这些基本的属性又是一些更基本的概念，如果我们对这些基本的概念达成共识，那么我们就有机会对概念进行统一。类似于面向对象语言中的类，类有各种属性，这些属性最终都可以通过 8 种基本的数据结构描述。

因此属性是认识概念非常重要的一方面。属性包含了事物自身的性质、行为，比如黑白、高矮、是否能飞行、是否独立行走。事物除了自身的性质外，还与其他事物发生一定的关系，比如大于、相等、对称、属于等。事物的性质、行为以及和其他事物的关系，统称为事物的属性。

通过属性就能找到概念的边界。具有相同属性的概念是同一个概念，即使是叫法不同也不应该分为不同的概念。比如土豆、马铃薯，一旦属性的增加和移除都算作不同的概念，比如小土豆是土豆吗？通过属性就能发现生活中的命名谬误，比如小熊猫并不是小的熊猫，而是单独的一种动物。

概念只是我们对所认识的事物起的一个名字，词语是概念的自然语言形式，概念是词语的思想内容。

一个概念可以具有多种表达方法，对于软件设计来说，我们可以用自然语言描述概念。也可以通过定义一个类来描述，并在程序运行时实例化这个概念。通过数学或者数理逻辑，我们可以使用集合来描述一个概念。

比如 “商品” 这个概念，可以通过不同的方法表达。

自然语言中，商品是指可以通过货币或者其他物品交易的物品，可以是自然实体，也可以是虚拟物品。而社会经济中对商品的描述为，商品具有一个核心属性就是价格，有价格意味着可以交易。

自然语言中，概念和词语之间并不是一一对应的，这是需要日常特别注意的。

自然语言（Natural Language）就是人类讲的语言，它是自然人类发展中自然形成的，比如汉语、英语。

这类语言不是经过特别设计的，而是通过自然进化的。它的特点是语法规则只是一种规律，并非需要严格遵守的规则，这种语言含有大量的推测，以及对话者本身的认知背景（比如东西方不同的文化背景形成了大量的哩语）。认知背景赋予了词汇、概念的不同含义，比如，豆腐脑这个词，不说东西方差异，就是国内南北都会有争议。

著名的白马非马争论在于自然语言的不确定性：

正因为如此，才会产生大量的诡辩，让交流效率降低。

逻辑学中的形式语言开始发挥作用。形式语言（Formal Language）是用精确的数学或机器可处理的公式定义的语言 ^[14]。例如数学家用的数字和运算符号、化学家用的分子式等，以及编程语言中的一些符号（Token）。计算机编程也是一种形式语言，是专门用来表达计算过程的形式语言。

形式语言需要严格遵守语法规则，例如 1+1=2 是数学中一种形式语言。

形式语言来源于形式逻辑，特别是形式逻辑中的符号逻辑。亚里士多德的《工具论》为形式逻辑奠定了基础，中国古代的周易的卦爻可以看做一种朴素的形式逻辑，后来很多人牵强附会将计算机的起源和二进制关联到周易上。虽然中国古代有了形式逻辑的朴素思想，但是遗憾的是没有脱离朴素的辩证法。中国古代哲学不缺乏更有价值的内容，但是周易的形式逻辑和计算机并无关系。

形式逻辑的含义用一句话表述为：用一套特别的（形式的含义）、显性的规则来约束逻辑推理规则。

由于形式逻辑也在不断演化，现代形式逻辑和古希腊也不太一样。19 世纪以前的形式逻辑主要是传统逻辑，19 世纪中叶以后发展起来的现代形式逻辑，通常称为数理逻辑，也称为符号逻辑。

莱布尼兹倡导建立“普遍的符号语言”，通过推理演算和机械化的思想一步一步严谨的完成逻辑推理。如果需要建立符号推理系统，就需要定义符号、推理规则作为系统的要素。

弗雷格完成了《概念文字》^[15]一书，建立了一个初步的逻辑体系（一阶逻辑体系），通过概念系统来消除二义性，避免偷换概念，并通过推理结构来完成严格的推理。

这个时候的概念依然是通过定义完成的，直到康托尔创立了集合论，通过集合来描述概念，集合中的元素就是概念的内涵，集合能被用到的地方就是外延。集合论的建立，标志现代形式逻辑的建立，也就是符号逻辑。

实际上，弗雷格建立的一阶逻辑体系可以看做一套逻辑体系模板，用它可以拓展出更多的逻辑体系。例如，在人们认识到概率前，认为逻辑推理是确定的，当引入概率后就不行了，因此哲学家们又发展出来概率归纳逻辑。

总之，知道形式语言和自然语言之间的区别，可以避免无意义的争论。软件工程师就是一个对现实业务形式化的工作岗位，将需求这种自然语言转变为代码这种形式语言。

正因为如此，需求和沟通的矛盾不可能避免，除非提出需求的人也是用形式语言，那么软件工程师的价值也就没有了。

使用形式语言可以精确的定义一个概念，并使用精确的语义规则和计算机沟通，这就是软件工程师编写软件的过程。通过计算机语言来描述一个概念，其实就是面向对象中的一个类，这里定义商品有两个属性名称和价格：

如果用集合的枚举法来表述商品就是：

计算机语言和数学语言是一种形式化的语言，可以精确地描述一个概念，但是自然语言只能给出模糊的概念描述。自然语言翻译成计算机语言的不确定性，带来了无休无止的争吵，但这也是软件设计者的主要工作。

正是因为自然语言的这种模糊性，为了更加具体地描述一个概念。哲学上概念的共识是概念有两个基本的逻辑特征，即内涵和外延。概念反应对象的特有属性或者本质属性，同时也反映了具有这种特有属性或者本质属性的对象，因而概念有表达属性的范围。

概念的内涵是指反映在概念中的对象特有属性或本质属性。概念的外延是指具有这些属性的所有对象，即囊括对象的范围。

例如商品这个概念的内涵是 “能进行交换的商品”，本质属性是能进行交换，从本质上区别产品。它的外延就是投入市场能卖的所有事物。

对概念外延的清晰描述对我们设计软件产品的定位非常有帮助，我们购买软件服务无非两种情况，生活娱乐使用，或者工作使用。马克思社会经济学精妙的描述为生产资料、生活资料。这其中的逻辑完全不同，按照生活资料的逻辑设计一款生产资料的产品注定要走弯路。

概念的内涵和外延是在一定条件下或者上下文中被确定的，这取决于参与人的共识。概念的内涵和外延是一个此消彼长的兄弟。当内涵扩大时，外延就会缩小，概念就会变得越具体。当内涵缩小时，外延就会扩大，反映的事物就会越多。通过操控内涵和外延，也可以在语言中构造诡辩，这一点在后面会讨论。

这在面向对象软件建模中的影响非常明显。对象特有属性或者本质属性越少，那么这个对象能被复用的场景越多，也就是内涵越小。反之，特有属性越多，能被复用的情况就越少了。软件建模过程中随意修改概念往往意识不到，但是每一次属性的添加和移除都带来概念的内涵和外延发生变化。

非常典型的一个例子发生在订单模型中。一般来说，我们会把支付单和订单分开设计，订单的概念中没有支付这个行为，但有时候觉得支付单的存在过于复杂，会将支付单的属性放到订单中，这个时候订单的内涵和外延变了。

内涵和外延发生变化但是设计人员没有意识到，会使用同一个词语。一旦使用同一个词语就会产生二义性，二义性的存在对软件建模是致命性打击。比如用户维护的地址、地址库中的地址、订单中的地址，这三个 “地址” 虽然名字相同，但是内涵和外延不同。

意识不到概念的内涵和外延，是无法设计出逻辑良好的软件模型的。

变量命名和缓存失效是编程中最让人头疼的两件事。

变量命名其实就是在给一个概念下定义。定义是揭示概念的内涵和外延的逻辑方法，一个准确的定义需要反映出对象的本质属性或特有属性。下定义困难普遍有两个痛点：

对于第一个痛点，根据概念的属性、内涵和外延，逻辑学中有一些很好地下定义方法。

属加种差定义法。 这种下定义的方法通俗来说就是先把某一个概念放到另一个更广泛的概念中，逻辑学中将这个大的概念叫做 “属概念”，小的概念叫做 “种概念”。从这个属概念中找到一个相邻的种概念，进行比较，找出差异化本质属性，就是“种差”。比如，对数学的定义，数学首先是一门学科，和物理学处于同类，它的本质属性是研究空间形式和数量关系。于是可以得到数学这个概念定义：

用这种方法给订单、支付单、物流单下一个定义：

在逻辑中可以参考下面的公式：

对于第二个痛点，这不是软件建模能解决的问题，需要充分和领域专家讨论，获取足够的业务知识。人们对概念的定义或者认识是随着对事物的认识不断加深而变化的。一个完全对某个领域没有基本认识的软件工程师很难做出合理的软件建模，例如银行、交易所、财会等领域的软件需要大量的行业知识。

我们做消费者业务的互联网开发时，往往因为和我们的生活相关，所以这种感受并不明显。当做行业软件时，领域知识对软件模型的影响甚至是决定性的。

概念只是语言的元素，如果需要建立逻辑思维，还需要一些逻辑规律。逻辑学的三个基本规律可以让沟通更加准确，避免无意义的争论，减少逻辑矛盾，让讨论有所产出。这三个重要的规律是：同一律、矛盾律、排中律。

在沟通中，人们会下意识的引入谬误，从而主动或者被动的诡辩。诡辩的方法非常多，下面是常见的几种诡辩方法，认识到诡辩的存在，让讨论的输出更可信。

在实际使用逻辑学技巧的过程中，我们可以借助一些思维工具。

概念图是指用图表的方法梳理概念之间的关系，不仅可以加深对概念的理解，还能避免因为概念混乱带来的诡辩。尤其是偷换概念是诡辩中最容易出现的一种，

学计算机的人大多有被人要求修电脑的经历。“你一个学计算机的修个电脑都不会”这种“大妈式”的暴力辩论逻辑实际上是一种典型的偷换概念，计算机维修和学计算机完全是不同的概念。

所以通过梳理概念之间的关系，可以清晰得到一个概念，可以通过使用概念图来描述概念的层次关系，上面使用的图即是概念图。

美国著名教育学家诺瓦克遇到了同样的问题，他需要一种清晰地方式给学生解释一些课程中需要用到的概念。同时，也需要了解学生在理解概念上的变化。他们的研究小组从拓扑分类学和语义学方面得到灵感，创造出“概念图”这一思维工具来表达概念。诺瓦克在他的著作《学习、创造与使用知识——概念图促进企业和学校的学习变革》一书中详细阐明了概念图相关的内容。

例如一个常见的逻辑问题是：联合国是否是一个国家？

因为“联合国”这个词的结尾有一个国字，而且中国是联合国成员国，所以有人想当然的认为联合国也是 “国”。这种谬误不仅发生在对世界不理解的少年儿童身上，甚至会出现在成年人的对话中。联合国是一个由国家构成的组织，而中国才是一个国家，为了避免谬误，合适的表述是“中国是联合国成员国”。

下面这张图为使用联合国是概念出发绘制的概念图，用来描述概念和概念之间的关系。

当然，你会发现“成员”的概念下面只有中国和美国，这是因为全球 200 多个国家和地区也画不下。到目前为止，概念图也没有标准，那么也就不存在概念图的“对错”。

模型这个词常常会听到，通常出现在某个 PPT 或者一篇商业评论中，社会和经济学中的模型往往比较朴素，金字塔、V 型图、四象限会以各种形式出现在不同场合中；软件工程师的模型会更加形式化，UML、E-R 图等，能用较为精确的形式语言描述；数学模型就更加精确，马尔可夫、蒙特卡洛等模型可以用数学语言描述。

广义来说这些都叫模型，甚至你随手在白板上画的一个用来解释当前程序结构的图形，这也能叫做模型。哲学家库恩将这种思维框架叫做范式，也就是模型。维基百科将广义的模型定义为：

我们天生就有用简单的东西代表另外一个东西的能力，比如幼儿园数数用的竹签，学习物理时的刚体、真空中的球形鸡，都是模型。通俗来说模型就是经验的抽象集合，平时听到的谚语、公式、定理本质上都是一种模型。

为了理解模型，斯科特·佩奇在 《模型思维》一书中给出了模型的几个特征：

为了建立和利用模型，模型思考有几个层次：

在斯科特·佩奇在《模型思维》^[16]一书中，使用了一张形象的图例，如下所示：

我们可以尝试用这种方式来看待原本很困难的知识，比如去简化复杂问题，并理解它。通过模型思维来看待软件开发，我们会发现，软件从设计到开发的过程就是各种模型的转换。

我整理了一个图表，说明了一款软件从商业探索开始到编译成可交付的软件整个过程中可能会用到的模型。

我将模型分为形式化和非形式化两种。形式化的模型是精确描述的模型，例如表达领域模型的 UML、ER 图，而非形式化的模型是一些非精确描述的模型，主要用来做商业、业务探索。

对于应用开发的软件工程师来说，核心的问题并非如何编写代码，而是如何将非形式化的业务输入（模型）进行合理抽象、设计，并转换为形式化模型的过程。

某种程度上来说，通过高级语言编写的代码也是一种模型。在多年以前，计算机科学家们认为编写 Java 代码的人不算程序员，可以由业务人员直接编写业务软件。软件工程中非形式化和形式化之间存在一个巨大的鸿沟，编程就是模型的形式化过程，从这个角度看能深刻分析业务并获得良好抽象结果的程序员具有竞争力，并不会被 AI 编程所代替。

在非形式化模型这一步，实际上又存在两种模型。一种是描述软件背后的生意，即使不使用计算机系统参与到业务中，该如何完成交易，并让企业获得利润，我把它叫做商业模型。另一种是描述软件的操作和交互的模型，关注参与的用户、流程和业务规则，我把它叫做软件业务模型。

我们可以分别将其定义一下：

那么弄明白商业模型和业务模型后，再来看软件设计，软件设计就是关注软件如何为业务、商业提供服务，提高业务和商业能力。虽然商业模型和业务模型有所不同，但是从商业模型体现的生意出发就能快速地理解一个应用软件（和日常生活相关的软件，区别于工具类软件，例如电商、ERP 等软件）。

优秀的产品经理往往能深刻地理解商业模型，然后才设计出合适的软件业务模型，避免了空想的业务规则，以及铺天盖地无用的功能。优秀的架构师应该也能理解商业模型，并从软件业务模型中提取合适的概念，构建软件的骨架，而不是让软件构建在没有地基的空地上，然后修修补补。

在软件实施过程中，需要思考项目管理、团队的问题，项目经理或者 Tech Lead 也可以有自己的模型理解和认识项目、团队管理、项目管理的模型，就是我们熟悉的瀑布、敏捷。团队管理的模型比较少，在后面会讨论一种系统化的团队模型，通过将团队中的个体分为 Dispatcher、Worker 来认识团队。

除此之外，还有一些模型并不需要过多深入了解，这就是和计算机工作原理相关的模型，这是计算机科学家的工作，对于普通开发者来说可以加深对计算机的理解。例如，符合人类的认知的编程语言（面向对象、函数式）背后的模型，面向对象可以看做一种模型，还有一些计算机科学基础的模型：冯诺依曼结构、图灵模型、布尔逻辑（数理模型）。

将这些模型串起来，能够提高对软件工程的理解，以及每个部分背后的逻辑，明白这些模型背后的目标后可以更加从容地应对各种问题。

使用模型思维开发软件并不是计算机科学家的专利，对于应用开发来说我们也会想尽办法找到合适的模型。应用程序设计中有很多套路，一些书叫做范式、模式或者其他词汇，如果按照模型思维的逻辑，我们可以叫它们模型。根据场景找到合适的模型就能把应用程序设计的很好。

做应用程序设计，除了特定领域外，大部分应用都有一些通用的的内在逻辑，我们可以尝试把这些内在的逻辑找出来，通过模型可以帮助分析业务问题。

通俗来说，系统分析的关键是怎么找到一根线把系统的大部分元素串起来，达到逻辑自洽的目的。串的东西越多，能分析的系统就越复杂。现代商业软件系统的类型往往由商业价值决定的，一般有这几类：

当然从分类上来说不可能做到尽善尽美，只能说常见的产品属于上面三类，还有一些难以划分在这几类之中。

当有人提出一个模型，然后一群人喋喋不休，争吵得你死我活的时候。让我想起了 George Box 的一句话：“All models are wrong; some are useful. ”这句话深刻的揭示了我们日常讨论心智模型时的一个原则，那就是：

所以我们能看到一些奇奇怪怪的思维模型，但是居然能找到用处。数学家布尔发现可以通过真值表来做一些逻辑判定，然后通过基本的对错进行复杂的逻辑运算，在布尔活着的时候数学界并不承认布尔逻辑是数学。

在那个年代，布尔逻辑只不过是一种分析问题的小把戏。这种观点一直持续到了布尔去世 200 年后，人们发现了门电路，当组合门电路就可以创造出复杂的逻辑装置。比如现代家庭卧室都安装了的双向开关，就是一种门电路的应用。

那么既然模型当不了真，如果我获得了一个思维模型或者理论，甚至仅仅只是软件中的领域模型，怎么知道它是否有用或者合适呢？简单来说就是两个方向：拟合现状和预测未来。

一般来说，我们不会平白无故的获得什么模型，比如有很多讲思维模型的书籍，介绍了上百种模型。其实这类书籍用处不大，因为模型存在的价值首先在于解决问题。

找到合适的问题模型就有用了，不管是先有模型还是从模型中找到能解决的问题。这就是拟合现状，找到的模型能满足当前的状态。比如在项目上，有一大堆的技术债需要解决。

我们可以使用一个四象限模型对这些技术债归类，这个四象限有两个维度，分别是重要性和紧急性。就能分出处理问题的优先级：

按照这种方法就可以清晰识别手上的一堆问题，这就是拟合；同时也为我们采取行动指明了方向，这就是预测未来。我们发现，拟合 + 预测，可以作为模型评估的“模型”，要做到拟合、预测就要满足一些条件，将其展开就能得到一些模型评估的清单。

尝试问几个模型拟合性相关的问题：

尝试问几个模型预测性相关的问题：

软件工程中太多的模型了，有时候多到不知道用哪个。有属于 UML 规范中的时序图、类图、ER 图，有现代更潮流的用户旅程、业务蓝图、应用蓝图等，也有随意画画的 Freestyle。

我以前也整理过一个项目上需要用到的模型清单，比如用 C4 架构图 + 时序图+领域模型图（UML）+ ER 图基本上能满足大部分业务需要，能充分的描述软件现状。当我慢慢把虚拟的软件世界和现实世界映射时，发现可以用一个思维框架来组织哪些模型是我们需要的。

我们用“宇宙”这个词来描述现实世界，在中文的词源中“宇宙”是两个词组成的，宇指代空间，宙指代时间。更有意思的是，“宇宙”这个词汇出自庄子的《庄子·齐物论》：“旁日月，挟宇宙，为其吻合。”。

那么我们可以从时间和空间两个方面来寻找一些模型描述软件，并且做到正交，就能清晰的认识到相关模型在软件建模体系中的位置，这样也能让模型保持干净。

先从空间上来看。领域模型图是在描述软件概念骨架，描述业务概念或数据在软件中是如何组织的。设计领域模型就好比我们将手机和电池分开设计，需要清晰地定义手机、电池，以及手机与电池的关系。

所以在建立领域模型图时，需要保持干净，体现实体、实体关系就行了，用 DDD 的风格，表达出聚合、上下文就完全满足开发需要。进一步来说，领域模型图、数据库实体关系图、架构图、部署图都是在空间上描述软件，只不过这是不同的形态。从空间上来说，可以类比建筑行业的图纸，但是软件是动态的，需要响应用户交互，于是又需要从时间（流程）上来看，这点和建筑完全不同。

从时间上来看，依然可以用不同的态来看待这些模型。时间维护上的模型体现的是流程、事件。从最朴素的流程图到用户旅程、服务蓝图，再到事件风暴、时序图、状态图都算描述时间过程上的模型。流程图由于粒度不确定的问题，可以用于草稿，实际上用的不多。

用户旅程、服务蓝图，描述现实中业务主体为了达成业务目标中间所经历的过程，可以用在商业探索早期。将用户旅程带入用例的视角，就可以解决颗粒度的问题。以用例为单位，用例的流动就是参与业务主体的契约在不断变化。

事件风暴则通过系统核心状态变化为线索寻找背后的实体，有点像电影的关键帧，通过状态的变化可以提取出描述软件空间结构的领域模型。

时序图则用于软件编写中，描述操作实体的服务（主体）之间的交互，时序图也可以有不同的层次关系，比如子系统（微服务）之间，服务之间（Controller、Service）。

那么通过时间和空间的思维，可以帮团队裁剪一套软件设计过程中的模型，例如：

模型思维不算是一项硬技能，它相当的软，以至于不少人在使用这种思维但是意识不到。显性化强调模型思维这个概念的用处是可以训练自己有意识的使用模型思维。为模型寻找一个表达方式，这样更容易理解复杂事物，载体可以是一个比喻，也可以是一页 PPT，或者简单的在白板上画出来。

把一些有规律的一组信息的首字母提取出来拼凑为一个有意义的单词来记忆也是一种设计模型的方法。比如说 PEST 分析法、FIRST 原则、SOLID 原则等。

如果想自创一些模型并让人信服不见得是一件容易的事情，由于晕轮效应的存在，人们对于大众流行的模型更能接受。所以如果我们想在汇报、说服的场景讲模型，可以将自己的理念嫁接到已经广泛流行的模型上，可以起到意想不到的作用。比如在项目的管理上，可以对开发过程模型 RUP、Scrum 模型进行裁剪，设计基于主流模型的定制化方案，相比基于自己经验完全制定的方案更加容易令人接受。

这里以一款售后的 CRM 系统为例，如果想要快速地理解售后 CRM，我们可以先从必不可少的业务概念开始，聚焦生意本身，其他的业务概念都是为生意服务的。

售后 CRM 的生意是当用户需要售后服务时，销售方需要创建一个服务工单来管理相关的售后问题。一个极端简陋的 CRM 就是一个服务工单，服务工单的两端构成了消费者和售后服务方之间的契约。例如，消费者买了一部手机，在保修期内需要维修，消费者发起了保修的请求，售后服务方通过服务工单作为契约接过了手机，开始维修。

售后服务方的接待员需要在系统中有一个身份，那么就需要引入一个用户的概念。紧接着，如果维修工作需要材料，CRM 就需要增加对材料的管理功能，否则就只能用纸、Excel 来管理消耗的物料。对于大型企业来说，这些物料需要在网点、总部之间流转，那么就需要建立一套调拨关系。网点和总部之间的物料来往需要出入库相关的流程来支持多地的库存管理。为了 进一步扩大服务体系，会将一些地区的网点承包给当地商户，这样物料的往返、工费就发生了结算，以及财务相关的逻辑就必不可少了。

虽然复杂的 CRM 系统会极其复杂，但是识别核心的业务关系并不会过于复杂。当识别到这些关键业务概念后，进一步展开看到具体的业务逻辑和流程就不会晕头转向。

当然，并不是说通过这种方法就能真的完整的理解业务，而是作为了解业务的第一步。

另外一个方法是“向钱看”。这是一种逆向思维，通过结算和财务往来快速找到系统之间的关键业务流转。它的逻辑很简单，一般商业软件都直接或间接和钱有关系，如果不涉及业务结算的软件一般是一些工具软件、非商业软件，不在我们讨论的范围。

正是因为商业软件具有和钱绑定的特点，那么我们可以首先去看结算的相关业务，也就是“谁在和谁做生意”，分析谁在和谁做生意必然会发生财务往来。通过财务线索看财务双方的身份，就找到了业务的核心主体，再看收费的项目就找到了业务的客体。

在前面售后 CRM 例子中，大型公司往往将其售后服务外包给一些地区代理商，这些代理商会和公司签约共同进行网点建设，人员培训，提供售后服务。如果不从结算出发，我们的视线会被淹没在一些无关紧要的场景中，忽略了真正重要的业务主体是代理商和公司之间。

再来看结算的项目中使用了什么载体做的结算处理。在售后体系下，既有物料的概念也有产品的概念。但是有意思的是，产品只是被维修的设备，用于登记用户维修的信息、判断被维修设备是否属于保修期内。如果用户在保修期外，需要付费维修，维修的过程中需要消耗物料，那么代理商就需要对服务费、配件的消耗进行结算。如果去查看结算相关的资料，我们会发现结算的客体是物料而不是产品。我们就能找到整个系统中最为关键的对象，也就能快速地理解整个系统了。

需求变化是软件工程师最难以容忍的一件事，为了做好软件设计，不得不猜测未来需求的变化方向。猜中了就是 “正交分解”，猜不中就是冗余设计。

那么需求变化背后的逻辑是什么呢？

首先我们不得不承认，从客观上讲软件它是区别于硬件的，为什么叫软件，因为它本身就是能改的，并且修改的成本低于硬件。硬件涉及电路设计、制版、开模等流程，在开发的过程当中，需求变化会带来巨大的成本。这是为什么软件能够提高效率的原因，因为通过搭建在通用计算机平台上的软件，能够很快做出业务应用。通用软件的出现，软件开发和硬件开发分离是信息社会的一个关键节点，所以软件被发明出来就是为了容易改。

但是事物总是矛盾的，容易改的软件相比硬件降低了成本，但软件容易修改的能力被滥用后，给软件工程也带来负担。

对于软件来说，修改并不是没有成本的，只是相对硬件而言小了许多。对软件工程师来说，业务的变化往往会带来困扰，因为它会让软件的架构设计和模型的建立变得非常复杂。

但并不是所有的软件需求变化，我们都不能接受。对于一些软件的交互和界面 UI 样式等这些细节上面的修改不影响主体的业务变化，这种修改是没有任何问题的。我们说的软件需求变化带来的困扰是指的在软件开发过程中随意变更软件的逻辑，让软件的整体性和逻辑性受到了破坏，这是我们不喜欢，不能接受的软件修改的方式之一。

对于专业的产品经理来说，软件的修改是非常谨慎的，因为修改一个地方，可能会影响其他地方。

那么在软件开发和迭代的过程当中，我们可能难以意识到一个小小的修改会影响整个开发、测试、上线等不同的环节，造成项目的延期，这是开发团队人员不喜欢软件被修改的根本原因。

那么怎么应对软件需求的变化呢？

如果我们理解了软件背后的生意，可以更加从容地设计软件。更为重要的是，和需求提出者的交流更加容易，除非需求提出者也并不熟悉正在设计的软件背后承载的商业目标。

分析一个企业的商业模型方法非常多，下面介绍比较常见也比较简单的方法——商业模式画布。

顾名思义，商业模式画布是一种描述企业商业模式的模型，最早来源于亚历山大·奥斯特瓦德的《商业模式新生代》 ^[17] 一书。其主要的思想是，商业模式不应该由几百页的商业策划书来描述，而是应该由一页纸就能清晰地呈现。根据思维经济性原则，无法清晰表述的商业模式其价值也值得怀疑。

商业模式画布，包含 9 个模块，可以呈现在一张画布上。如下图所示：

编写商业模式画布实际上需要回答 9 个问题，弄明白至少这 9 个问题，才能知道对未来相关的商业设想是否靠谱。如果投资人看这份商业模式画布，才能快速知道这笔生意是否能赚钱。

这里将商业模式画布 9 个模块的含义通过问题给出来。

通过商业模式画布可以理解企业的商业模式，弄明白在企业的业务中谁是客户，收入从哪里来，合作伙伴是谁等。不过，商业模式画布没有将企业的内部运转结构打开，一个企业需要运转起来，需要各个部分之间的通力合作，并和用户产生交互。

如果理解了一个企业的商业模式，以及支撑商业模式的业务，再来看构建在两者之上的信息系统或者软件就容易很多。

我们可以做一个思维实验，一家主营食材配送的企业，它的客户是餐厅老板，公司的主要业务为每日清晨为各个餐厅配送食材。毫无疑问在现代化的社会，信息系统必然是存在的。这家公司使用了微信作为渠道，建立了小程序、H5 应用建立了来支持食材的订购，同时又为承担配送工作的员工开发了具有送货、打单功能的安卓原生 APP，以及财务核算的 Web 应用。

假定在某天系统故障了，但是配送的工作不能停下来，这是事关商誉的事情。如果因为一次无理由的断供，导致相关的餐厅无法营业，营业中断带来的损失远远超过当天的货物的价值。于是，公司领导无论如何都需要想办法将食材送到客户手中。在信息系统无法使用时，它们可能的做法是，从数据库导出备份的数据，打印出来，人工的通知到客户。我们会发现，对于这类软件，完全可以使用纸和笔延续之前的业务。

这种思维实验，也是在软件设计时常用的方法。当业务复杂，产品经理或者业务人员无法描述清楚，我们可以将“电”断掉，思考如何通过纸和笔来完成软件设计。

断电法，可以将系统中晦涩难懂的概念在现实中找到可以被理解的物品。比如，用户这个概念比较抽象。餐厅老板或者经理可以作为用户在配送平台上下单，如果断电了，那么用户在现实中是什么呢？可能是食材配送老板大脑中的一段记忆，也可能是写在笔记本上的一段记录。

可能会发生这样的场景：

如果用现实中的行为扮演 IT 系统的逻辑，可以降低认知难度，更加容易理解业务。前面的业务服务蓝图，可以看做断电后的纸笔推演，而接下来我们需要将 IT 系统引入整个商业体系。

对于行业软件来说，软件技术本身并不复杂，它更像是一个“机器人”（软件），难在如何教会这个机器人像专业人士一样工作（领域知识）。

为了描述我们引入新来的小帮手，可以使用两个思维工具：电梯演讲和应用服务蓝图。

当我们把 IT 系统引入到业务体系中后，会面临一个新的问题。无论是产品设计还是软件设计，无论作为产品经理还是架构师，有一个难以回避却引人思考的问题是：哪种产品设计是好的？

不像艺术设计类工作岗位，产品设计、领域模型或者架构岗位往往不好通过某种考核来评价人员的能力，于是更多的是过往的工作经历来证明其设计水平。

另外一方面，大家评价一个方案的好坏有多种偏好。有人喜欢用是否足够前沿和创新来评价方案，有人会用同行的竞品来评价方案，甚至有人通过个人偏好来评价方案。但是归根结底要从方案的收益和成本上来看，否则为什么要做这个软件呢？这就是产品设计的经济性考量。潘家宇老师的《软件方法》^[22]一书中给出了一个公式：

这是一个非常反常识的观点。首先他将产品设计同利润联系起来，因为我们做软件产品是为了提高生产力，而不是花费更多的人力建造软件，但是带来的收益还无法抵消构建软件花费的人力成本（虽然现实中这种例子非常多）。那么利润就是省下来的钱，这也是投资该软件的目的和动机，这是一切的起源。

如果这个公式用于软件产品设计，可以这样表述：一家公司有各种各样的业务场景，支撑业务场景的就是需求，因为产品经理或者业务分析师（BA）经过抽象、归纳和设计，使用较少的软件功能就能支撑这些场景，就说明能获得更高的利润。

如果代入到领域模型中，用足够少的领域模型能支持多种多样的功能，并具有一定的拓展性，那么就能说明领域模型的抽象和设计是能减少重复开发，因而能带来收益。

既然设计是如此重要，可不可以将设计做到极致，让开发成本极其低呢？理论上是可以的，但是这样会牺牲用户体验，以及软件的可靠性。如果将所有页面都设计成简单的增删改查，开发人员能极快的完成开发，复制粘贴就可以做完所有的工作。但是，这样的软件能满足需求吗？

所以产品设计中有一个矛盾，我们需要在这个矛盾中找到平衡，这个矛盾是：

通俗来说，就是能用 3 个关键步骤就能满足业务需要的设计，没有必要设计为 5 步。精兵简政能提高用户体验，降低成本，在当下的互联网软件中是一个趋势。在设计良好的情况下，这个成本减少带来的收益是双方的，用户的操作成本和企业的运营成本都会减少。

但是如果产品经理不加以设计，直接简化关键步骤，一拍脑门说要学习“极简风格”的乔布斯。后果是软件没有完整阐述线下的商业逻辑，本来应该达成的契约没有完成，剩下的就是运营人员需要面对无休止的纠纷。

举个例子，某会员系统具有一个会员充值功能，但是在业务上操作员在为会员充值时可能出错。一般此类系统，都会提供一个“冲正”的功能来修正之前的错误操作，但是两条记录都会存在。

某产品经理在新的版本中创新的简化了逻辑，提供了一个“撤销”的功能，可以对原来的充值单做出修改，在用户侧也“简洁”的看不到两条记录。在上线运行后，偶尔接到恶意投诉，用户提供了某时刻的账户余额截图，以及充值记录，说自己明明有多少钱（装作不知道撤销这回事）但是后面又少了。

所以用通俗的话来说，靠谱的产品设计是在不产生“扯皮”的情况下，用最低的成本和流程把“生意”做了。使用经济学作为基本原理，选择最具有经济性的产品方案。

所谓极致的用户体验和简洁性，其实也是从用户的角度发挥产品设计的经济性原则。让用户做的少了，代价是软件的开发、运营成本变高了，公司需要做的更多。为了让用户感受到丝滑般的体验，需要付出巨大的成本，从公司的角度也不是最经济的。

换句话说，先用低成本把生意做成了，再付出更多成本让用户体验更好，吸收更多的用户。生意没做好，和系统好不好用没有太大关系。虽然信息系统对企业运转至关重要，但是也没有到生死攸关的地步。

领域驱动设计（DDD）^[23] 是 Eric Evans 提出的一种软件设计方法和思想，主要解决业务系统的设计和建模。DDD 有大量难以理解的概念，尤其是翻译的原因，某些词汇非常生涩，例如：模型、限界上下文、聚合、实体、值对象等。

实际上 DDD 的概念和逻辑本身并不复杂，很多概念和名词是为了解决一些特定的问题才引入的，并和面向对象思想兼容，可以说 DDD 也是面向对象思想中的一个子集。如果遵从奥卡姆剃刀的原则，“如无必要，勿增实体”，我们先把 DDD 这些概念丢开，从一个案例出发，在必要的时候再将这些概念引入。

Eric 在 DDD 一书中阐述了领域驱动设计的重要意义和一些基本实践，但是并没有给出一套具体的建模过程方法。这给架构师巨大发挥空间，各种建模方法就都可以拿来使用，比如事件风暴、 四色原型等建模过程方法。

于是有一些朋友会产生疑惑，这些建模方法背后的逻辑是什么呢，它们有没有什么共通之处？这里和大家一起探讨软件建模过程方法的基本逻辑，以及如何设计一套简单的建模过程。

目前进行领域建模方法使用的最多的是事件风暴。事件风暴 ^[24] 的发明人是 Alberto Brandolini ，它来源于 Gamestorming，通过工作坊的方式将领域专家和技术专家拉到一起，进行建模。事件风暴非常有意思的地方在于，它先从事件开始分析，捕获事件。然后分析引发事件的行为和执行者，从这些信息中寻找领域模型，最终进一步展开。

Event Storming 的逻辑是什么？为什么需要先从事件开始分析？这是事件风暴工作坊中遇到过最多的问题。

我带着这些问题请教了很多专家，甚至发送了邮件给 Alberto Brandolini，有幸得到回复。根据 Alberto Brandolini 理解，他认为系统中事件是一种容易寻找到的元素，通过头脑风暴，容易打开局面，仅此而已。

带着同样的问题，分析了几种建模方法（为了减少争议避开了公司同事发明的建模方法）。

多对多关系是软件建模中比较麻烦的场景，如果梳理不清楚对软件架构伤害很大。在不久前的一个项目中，十足的体验了一次多对多关系带来的痛苦。

我们的项目是一种多空间模型，也就是用户可以处于不同的空间，在不同的空间中可以访问空间中的资源。一个空间可以拥有多个用户，用户可以出现在多个空间中。看起来和编程老师在数据库课程中的多对多关系没有区别。

对于数据库来说，多对多关系需要一个中间表，一般会使用类似 workspace_user_relation 的名称。假如不对这个中间模型进一步分析，可能会得到 E-R 模型如下。

团队使用了 JPA 的 @ManyToMany 注解，导致 workspace 和 user 两个对象无时不刻在一起了。另外，通过 user 可以操作 workspace，通过 workspace 也可以获得 user。

这种设计，不仅在技术上实现困难，对业务的支持也不足。

如果团队和系统的规模不大，可以根据一两个人的经验设计出足够合适的模型。但是，当团队规模非常大、系统极其复杂的时，我们就需要制定一些原则来评审、检查各个团队产出的模型是否合适。

这些原则也许不能指导所有的场景，但是能在一定范围内做出约束。年轻的工程师总是喜欢自由，经过历练的工程师开始理解到约束的好处，想法也变得成熟。

我收集了一些社区讨论的观点，这里整理了一些 DDD 战术建模中的一些原则，作为软件领域建模中的基本要求。

1. 当一个【实体】被多个聚合根使用时，需要将其设计为【聚合根】或者将其拆开，不能再作为实体使用。

如果我们将聚合理解为系统中业务一致性、生命周期相对独立的一组实体，可以作为系统设计的基本单位，那么，一旦出现被多个聚合共享的实体，聚合就不再有意义了。

当两个聚合中出现了相同、相似的实体，有时候我们可能想要减少实体的数量，于是有了将其合并在一起的想法。比如，在分销系统中，销售和退货由两个不同模型实现，但是它们有类似的操作记录。如果将操作记录作为实体，但是处于不同的两个聚合，就会让这两个聚合耦合，让开发人员在开发时摸不着头脑。

类似的，在不同的业务场景中都会使用到附件，如果将附件作为实体存在，会造成混乱，与其这样不如直接设定一个原则，不允许出现共享实体的聚合。

2. 不允许使用【中间表】处理多对多关系，探明多对多原因，明确中间模型的归属。

多对多关系是领域建模的杀手，但在有些地方却会是消除系统耦合的钥匙。

一个多空间系统，用户可以出现在不同的空间下，空间也可以容纳多个用户。看似是一个典型的多对多关系，我们大多数情况下会使用简单的中间表处理。

使用中间表往往意味着没有创建时间、状态等额外字段了。但是我们仔细一分析会发现，这个中间表的创建时间就是用户加入空间的时间，也就是说它是具有业务含义的，只不过被我们疏忽了。

当出现禁用空间下的用户业务时，只是删除中间表无法表达合适的业务需要，于是我们可以在中间表加上状态以满足业务需求。随着业务的丰满，中间模型就会显露出来，慢慢体现其重要意义。

多对多关系的存在，让我们无法建立合适的聚合。也就是说，无法将中间模型的归属问题明确下来。查询空间时，可以获得用户列表，同样的查询用户时，也可以获得空间列表。

那么，是用户拥有空间，还是空间拥有用户呢？

这就变得混沌，我们明确中间的模型为“成员”，明确空间拥有“成员”。当需要根据用户查询所属空间时，本质上是根据用户在空间下的成员信息来筛选空间。

当然，中间模型可能会归属到任何一边，这就需要架构师来拿捏和设计了，但是重要的是，中间模型的归属问题需要尽早的明确下来。

3. 区分【关联】和【拥有】，避免将本应该关联的模型设计到聚合之下，否则聚合非常大。

本条原则可以避免聚合设计过大，也可以避免不合适的生命周期。

以银行信用卡开户流程来说，代入到具体场景，银行账户是一个核心的模型，可以构成一个聚合。相关的，在开户时，会提交一个开户申请，银行的工作人员会对信息做出审核，完成审核后进行开户。

一个不佳的设计是，账户不能将开户申请纳入聚合中，因为申请的生命周期和账户并没有关系。开户申请和账户之间可以存在关联，但是不应该具有拥有关系。

4. 领域模型和数据库保持一致。

本条原则约束了领域模型落地实现的处理方式。

在理想的情况下，领域模型、数据库、API 都能体现系统状态（RESTful 叫做表征状态转移）的变化，如果能一一对应能让系统的复杂性降低，换个时髦的说法是让“熵”足够低。

有时候，我们会偷懒，想要将不同的模型持久化到同一张数据库表中，节省数据库设计。但是，这种差异造成了团队认知负载。如果没有必要，不建议这样操作。

5. 聚合的层级保持在 2 级，最多不超过 3 级。

这条原则非常好理解，层级过会带来落地上的巨大成本。

聚合的大小是领域模型设计中非常难取舍的地方。过大的聚合持久化，更新操作都不好处理；过小的聚合业务一致性得不到保证。

根据经验，2-3 层的聚合已经能满足大部分场景，如果超过 3 级，考虑将部分模型进行分解。

6. 事实数据快照化。

这条原则往往容易被初级的工程师忽略，但是非常重要。

根据范式理论，如果想做到很高的一致性，就不应该冗余过多的数据，这是大学数据库课程的基本内容。但是现实情况不能一概而论，对于重要的交易业务来说，完成业务后不会再更新，不存在一致性要求，反而是应该锁定交易时发生的关键数据。

这是因为一些事实数据本质上是业务合同。举个例子来说，合同的甲方乙方会记录下身份证号码、以及名字，即使当事人去派出所变更了姓名，也不会影响到合同中的主体。

7. 核心交易，设计交易流水或日志，用于审计。

接上一条原则，交易发生后，可能会对一些账户、库存、积分等信息进行变更，需要意识到为这些重要的信息记录流水、操作记录或者日志做备份。

这是因为大部分信息系统都有商业契约性质，为了保护用户利益，需要在系统中留下足够的痕迹，避免未来“扯皮”，在纠纷发生时能提供证据。

8. 抽象类核心模型，提供拓展策略。

如果我们将一类相似的模型抽象统一后，注意设计良好的拓展策略，避免抽象后的模型无法支持拓展。

每位工程师都应该听过编程中追求复用的原则，但是并非所有的工程师认识到复用和抽象带来的制约。当抽象发生时，意味着放弃了一些个性化的数据和行为，被抽象的模型在以后的命运中被绑定到一起。

如果我们想清楚了需要将一组抽象到一起，应该通过“不变点”找到共性，然后通过各种设计模式（例如，适配器模式，策略模式）为“变化点”提供拓展。

举个例子来说，餐饮领域中外卖、堂吃是两种不同的订单，外卖具有送货信息，堂吃具有座位信息。如果我们将两种订单抽象为一起，设计了订单模型，这是合理的，因为订单是“不变点”，和金额、结账、支付有关。

对于送货信息、座位信息可以使用适配器模式隔离出来作为独立的聚合并关联订单，避免订单上挂载送货信息、座位信息这类和场景相关的信息。

9. 当业务变化时，分而治之；当业务稳定后，抽象统一。

接上一条原则，如果在是否将相似模型抽象到一起而犹豫时，说明没有足够的信息输入，以至于缺乏信心。

抽象的模型是通过归纳产生的，如果没有信息做出归纳，可以优先分而治之，待业务明确后再重构为统一的方式。

10. 让合适的人做合适的决策，并做好决策记录，为后续决策提供背景信息。

最后一条是写给架构师的原则。

如果一个团队存在专门的架构师，而且团队又非常庞大时，架构师无法获得完整、足够细致的信息，需要承认无法在任何场景下都做出合理的决策。

架构师应该只关注系统核心的模型，以及划定上下文边界附近的模型归属，确保系统作为一个有机的整体。而对于系统某个角落的模型设计应该交给具体的开发人员来决定，记得做好决策记录就行。因为架构师认识到什么重要，什么不重要比事无巨细的决策更有意义。

对于领域模型而言，我们是站在结构而非流程的视角上的。我们就不应该把流程、行为赋予领域模型。如果我们在设计一台机器，工件可以看做一个聚合。工件在被用到的各个地方才具有相应的能力和用途。

需要时刻注意的是，领域模型表达的是软件的逻辑结构。沿用工件的例子，一颗螺丝可以被用到婴儿车上，也可以被用到起重机上。但是有些工件却是某个特定机器的零件，虽然它并没有特定的功能，但是有经验的老师傅一眼就能看到它可以被用到那些机器上，并提供某种特定的功能。

大部分情况下，领域模型就是数据库表在代码中类的体现，所以不是特别赞同为了"干净"将领域模型和映射数据库的类分开，大部分情况下领域模型（代码中）就是数据库表（数据库中）的映射。

从复杂和混乱的信息中找到重点才能定义出元素以及找到关系。架构是一个非常玄学的领域，它不像编写一个确定的中间件一样，有明确的输入条件和输出。架构充满了权衡、取舍和纠结，其原因就在于复杂性问题。复杂的信息越多，系统熵越多，没有能量输入时，系统逐步趋向复杂、无序状态。

《人月神话》里面提到两个概念：本质复杂度和偶然复杂度。本质复杂度是在解决问题时，无法避免的事；偶然复杂度是做事方法不对，人为引入的复杂性。

架构师就是与复杂性对抗的人。

本质复杂度无法避免，而导致偶然复杂度上升的原因有：

我们必须能找到办法对抗复杂，我们能用到的工具有：

分层的目的是水平隔离复杂性，那么怎么定义“一层”呢？由于对具体分层的定义非常模糊，导致了我们实际上分了很多层，但是却觉得没几层。

服务划分的目的是垂直分解复杂性，垂直是指在某一层内的垂直。也就是说，在不同层垂直划分的粒度可能并不相同。

图片来源：https://www.eecs.yorku.ca/course_archive/2010-11/F/3213/CSE3213_03_LayeredArchitecture_F2010.pdf

在很多系统的垂直划分时最大的误区是穿透了分层，想象一下我们有一套自己的通讯协议，这套通讯设备同时具备了应用层、网络层、传输层、数据链路层，那么这套通讯协议就很难被归纳到 TCP/IP 协议簇中了。

架构演进是通过时间维度来分解复杂度的一种方法，在设计时就考虑架构的演进方式，并制定一套架构演进路线图，对架构非常有帮助。

制定架构演进路线的好处有：

架构演进路线主要需要包含当前状态、目标状态、关键节点和时间。比如，我们可以使用企业架构标准化制定组织 Open Group 提供的通用图例绘制架构演进路线。

图片来源：Open Group 文档

我们在架构设计时，往往拿到的不会是一个全新的系统，从一张白纸开始设计。我们往往容易被当前的系统状态限制，将未来、现在两种状态混在到一起。

比较好的做法，我们可以将架构设计工作分为 AS-IS、TO-BE 两套，AS-IS 用来分析现状，将当前的架构信息重建出来，使用 TO-BE 的工作设计未来的架构方案。AS-IS 和 TO-BE 中间还需要考虑分阶段实施方案、数据迁移方案。

架构路线图需要包含 4 个要素：

一些项目管理工具是可以提供一些架构演进工具的，比如 roadmunk.com 网站就提供了如下风格的架构演进地图：

图片来源：Enterprise Architecture Roadmap https://www.productplan.com/glossary/enterprise-architecture-roadmap/

在不使用专业工具的情况下，使用表格软件、PPT 也没有问题，关键在于我们的架构应该保持一种活跃的状态，因此在研发资源投入的时候需要将架构演进和持续更新的成本计算在内。

什么是架构中重要的事情呢？在和同事、社区的朋友交流时，收集到的一些架构关键因素。

以权限设计方法为例，说明主客体思维在架构中的应用。

在设计架构时，鉴权是无法避免且非常重要的一个专题内容。但是当我们说鉴权的时候说的什么呢？是认证（Authentication）、鉴权（Authorization）还是审计（Audit）?

这个问题并不复杂，一般来说：

认证、审计可以被单独讨论，这里只讨论分布式系统下鉴权的问题。问题往往在于当我们系统分布式化后在每层“谁”这个概念可能发生了变化，因为“分层是主体权责的让渡”，下层的主体可能已经变化了。

这样说可能有点晦涩，举一个例子来说。用户服务提供了一个 API 用来查询用户信息，我们自然会想到查询用户信息是敏感信息，需要鉴权防止信息泄露。前端和另外一个服务都可能使用这个 API 时，权限应该怎么控制呢？

于是往往会出现两种流派。一种是领域服务只提供通用的能力，无需鉴权，鉴权的点应该由应用层来做。另外一种是领域服务每次的请求也需要知道用户的存在，并在领域服务内检查权限。

这两个流派都不能完全解决问题，如果鉴权只是由应用层来完成，基于不同权限展示的数据无法限制。如果将权限检查留给领域服务实现，会造成 API 的混乱。因此折中的思想是将权限设计为功能权限和数据权限，通过区分这两种权限类型来解决这个问题。

我们说分层的元素是主体、客体、行为，那么如果能给这些元素起个好名字，就能写出表达力强的代码。

首先，我们可以对命名进行分类：

团队管理是社会学讨论的问题，分布式系统是计算机中的概念。它们能有什么关系呢？在开始写作前，我在和同事聊到这部分内容的想法时，同事笑道：你这个想法非常有意思，但是你可能只是强行将它们联系到一起。

这两个概念甚至都不在一个学科，一个是文科，而一个算工科的内容。但是，世界是非常有意思的，跨学科的碰撞往往能发挥意想不到的作用（以后还会有类似的跨学科联系的文章）。

查理·芒格一生都在不停强调跨学科思维的重要性，在他的模型中，数学、物理、生物、化学、哲学、社会学、心理学等领域都会被突然联系到一起。例如，大家以为的投资是经济学话题，其实是一个社会学或心理学问题 —— 当身边的人开始向你推荐股票，牛市就结束了。

在《分布式计算——原理、算法与系统》^[29] 这本书的开篇提到，“分布式系统是一组相互独立的实体构成的集合，这些实体相互协作可以解决任何单独的实体所不能解决的问题”。作者认为，分布式系统在宇宙之初就存在了，从蜂群、微生物系统、甚至由人体细胞构成的各种系统，这些都是分布式系统。

团队是一个能独立承担一定功能和职责的人类群体，那么也应该是一个分布式系统，符合分布式系统的一些基本理论。这是这篇文章的基本前提。

接下来我们会聊到分布式系统的两种模型，分别代表两种典型的团队形态，也代表不同的计算模型：

大部分情况下，我们不会用到反馈调节模型，但是当我们仔细观察和分析大型企业的工作机制时，就能发现端倪。这部分的内容，这里不过多讨论。

当我们聊完了这两个模型之后，我们可以得出对管理者有价值的一些启示。

当然，从站在被管理者的角度理解这两个模型，也会让自己受益。

不知道有驾照的朋友尝试推过失去动力的汽车没有，对于有一些糟糕的团队来说，Leader 变成了推动团队运行的人，就如同一名驾驶员通过推车的形式让汽车跑起来。

虽然我们知道，IT 团队 Leader 往往是技术最好的那一个。但是，团队 Leader 不仅仅技术好就行。我时常去徒步，我发现体力最好的人未必能作为领队，因为领队还需要负责制定路线、判断天气、鼓励团队前进等超越了独自运动的范畴。

如果团队 Leader 没有意识到带领一群人完成艰巨的任务是“驾驶”技术，那么就会陷入无法推动团队前进的情况。甚至由于 Worker 角色占据了他全部的带宽，Dispatcher 的身份就无法充分发挥。

在敏捷软件项目中，我们往往会提前一个迭代设计技术方案，并在下一个迭代进行交付。如果，技术方案设计的不够充分，无法起到帮助下一个迭代更好的指导团队开发的作用，技术 Leader 就不得不花费大量的时间进行支持。

更糟糕的是，有的技术 Leader 觉得交代任务沟通起来非常麻烦，与其交代给团队成员完成还不如自己一个人干掉。实际上，看似完成了工作，但是整个系统却并不健康，因为这个系统不再具备任何的拓展性，无法将更多的团队成员加入进来。

我们必须认识到，在汽车的隐喻中，推动团队前进的是团队成员而不是 Leader。作为驾驶员只能判断路况，将前进的信号传递到车机，当发动机的转速提高后，驾驶员需要变换合适的档位，以便让汽车在合适的工况下工作。毛主席曾指出“人民，只有人民，才是创造世界历史的动力。” 我们也可以充分的发挥群众的力量。

团队也是一样，想要团队良好的前进，就需要在两方面下功夫：减少团队的摩擦，向团队输入能量。

什么样的团队更好管理？认知能力越强的团队还是平平无奇的团队？和直觉相悖的是，认知能力越强的团队越不好管理。

管理的难度是由管理者和被管理者之间的认知差距造成的，认知差越大越容易管理。相反，如果被管理者的认知差距大于了管理者，那么管理者做出的政策都会被破解和失效。

那么，这种差距体现在什么方面呢？

在广义的解释下，人的认知是能够被度量的，认知能力是指人脑加工、储存和提取信息的能力。包括了概括抽象能力、发现问题的能力、预见性能力等。

在软件工程和团队的范畴下，狭义的认知差距具有更为具体的含义。管理者更需要具备下面的特质：

当管理者和团队的认知拉开差距时，矛盾和服从性问题就能解决。“服从”并非一个贬义词，换句话说就是管理者除去行政职权外，对团队的影响力有多大，这决定了其政策和方向能否被团队接受，并实现统一思想。

据我所知，有一家做制造的传统公司为了推进数字化转型，为制造、采购等单位开发软件。按照测算，软件上线后可以裁员 40%，并节省大量开支。

但是 IT 部门却发现了一个问题，在需求分析阶段业务部门就非常不配合，并且勉强上线的产品也无法推广。原因是电子化后，一方面监管变得容易，没有灰色操作；另外一方面由于软件的替代作用，业务团队人员数量会被缩减，业务基层领导也不愿意看到这种情况，于是暗中阻挠希望维持团队规模。

IT 部门领导获得公司高层授意后，制定了一条政策：设立一项考试，获得电子化操作证书的员工优先提拔并重新评职级，这条政策本质是 IT 部门制定，却需要由业务部门执行。 这条政策的执行很快让软件的实际使用情况获得迅速提高。

在数字化推进的过程中，这个案例并不鲜见，我们来分析这个案例。

首先，在不使用政治手段时，IT 部门几乎没有办法提高软件使用率，如果把解决问题的方向放在软件体验上，将毫无用处（这条政策也有一个前提，软件的使用即使有一些问题，至少不耽误正常业务运转）。IT 部门使用了"不堪"政治手段，"不堪"的地方在两点。

这是一个"不堪"的政治示例，讲述了一个简单的道理：政治就是让朋友多多的，让敌人少少的。政治是操作矛盾的艺术，操纵民族矛盾对立，就可以消除阶级矛盾，而制造外部矛盾就可以缓解内部矛盾。

拉一个打一个是操纵矛盾的基本手法。

拉一个打一个是普通手法，在软件行业中，甚至当没有人可以拉时，可以"买一个"，这就是接下来需要讲的故事。

可能有非常多的人和我一样不了解管理咨询公司到底做什么的，在社会中扮演者什么样的角色。我曾经一度对各大管理咨询公司的神秘抱有敬畏之心，直到后来才发现相关他们的秘密。

而这些秘密需要新的认知才能理解。

如今的管理咨询公司有点像古代的谋士或者门客。他们不是用高大上的方法论、专业的数据收集和调研来解决一些具体的问题，这些工作是研究院做的事情，这是一个普遍的误解。

我们换个角度思考，企业为什么需要管理咨询工作，甚至为它付高额的报酬？难道仅仅是因为管理咨询公司对某些领域更专业？请了咨询师不打当前管理者的脸嘛。

本质原因是一些难以推动的事情需要通过管理咨询公司的包装才能进行下去。如果一个公司需要对组织结构进行调整，那么直接动手会遇到极大的阻力。很简单的方法，包装一个高大上的项目和计划，例如进行变革、创新等行动，在行动中顺理成章的实现超出管理能力范围内的目标。

咨询师如果真的给出了"专业"的建议并否定了当前管理者的管理政策，那么必然会碰一鼻子灰。而真正的认知是，读懂并理解当前管理者的意图，并积极给予帮助。

从管理咨询的作用是作为达成雇主目标的工具这条认知出发，我们需要思考一个问题：权力的来源有哪些？

如果管理者有绝对的权力，下面的人对其言听计用，那么花钱购买咨询服务自然就没有必要了。从某种程度上来看，购买而来的咨询服务就成了行使权力的手段。

和我们常常理解的不同的是，名义上的领导往往无法行使与其表面相称的权力，而是被四处掣肘。

对于公司来说权力的最终来源是人事权、经济权。所以一般情况下，权力的来源是具有人事权的领导授予的，而不是来自团队成员的支持。"悦上者荣,悦下者蹇" 说的就是这个逻辑，取悦领导的任何往往混的比较好，而争取得到下属支持的人却不受优待，这是因为权力来源客观决定的。

虽然权力的来源不是来自下属，却在执行任务时需要得到下属支持，这点容易让人混淆权力的来源。所以实际上的领导争取下属的支持，但是权力的基础却不在这里。某些人拉拢同事对抗领导，相当于平白无故的争取权力，是没有人能接受的。

在写这条认知的时候感到非常残酷，却越想越是如此。我们能在历史中找到非常多类似的示例，在工作中也能发现不少蛛丝马迹。 当然权力的来源不仅仅如此，否则所谓的"政治"就太简单了，权力的另外来源还有能控制的资源。

对于销售为核心的公司，客户资源往往是隐性权力的来源；而对于技术为核心的公司来说，核心技术掌握也是权力的来源；群众的支持也算一种权力的来源，不过微不足道。

这些隐性的权力来源往往会和官方权力来源出现矛盾，这就是"政治"游戏的中心了。从各方的动机上来说，领导者的职责就是不断拆解隐性权力的影响，平衡团队。而隐性权力的受益人来说，自然不肯放弃，这就形成了极其复杂的博弈。

权力另一种的来源更加"不堪"，那就是伤害别人和造成破坏的能力。在社会中这类的例子非常多，不过过于敏感暂且不说。即使在软件工程行业，通过"掀桌子"获取权力的案例也比比皆是。最不堪的就是恶化代码质量，人为地提高自己的门槛也不失为一个例子。

除此之外，抢占道义的高地也是获取权力的方式之一，这也是一些公司部门为什么抢着申报"创新"、"变革"等项目，利用这些项目可以对权力体系造成道义影响，行使超出自己职权范围外的权力，俗称"拉虎皮扯大旗"。

通过权力来源的分析，我们会发现一个非常有意思的现象。现实生活中，很多事情并不像表面运行的那样，而是通过一些隐性的东西在支配和运转。

我们可以把表面支配我们生活的东西叫做规则。这些规则可能是工作制度、道德、法律，但是更多的是运行在规则之下的规则。有一些人把这类东西叫做"潜规则"，而我可能更愿意叫做秩序。

规则是名义上的，而秩序却必然存在，而秩序就是通过权力体系构成的。

比如一个公司表面上由老板决定了如何分配工作和任务，一线的员工却把苦逼的事情额外的给了实习生，在老板无法事无巨细管理的地方由隐藏的秩序支配。

有时候会因为秩序的改变让事情走向截然不同的方向。举个狗血的例子来说，公司老板和经理的管理模式，构成了基本的秩序和权力格局。如果有一天，公司老板和市场部某位女性产生了不正当关系，原有的格局慢慢发生变化，新的秩序便形成了。

新来的员工在只知道明面上规则的情况下，不了解真实的秩序，那么极大可能在不该遇到麻烦的地方碰壁。

一个残酷的事实是，秩序的建立不受道德、公平和正义的丝毫影响。换句话说现实没有公平，只有秩序。

如果在一个学校的某班级中，按照规定应该平等的调整座位，如果班主任不进行干预，那么很快调整座位这件事就会变成秩序的体现，被霸凌的学生就只能永远坐最后一排。

另外一个更残酷的事实是，秩序只被有意愿且有能力影响局面的人影响，或者被某些事件影响。延续前面被霸凌的例子，如果被霸凌者去找老师投诉座位调整问题，如果遇到不负责的班主任老师，往往不会干预甚至觉得烦扰。如果被霸凌者接受了这个事实，那么不公平的秩序就建立了，除非通过某些极端手段改变当前的秩序。

关于秩序的问题，带入到软件公司和团队中并不会有太大差异。某公司一个团队负责人给自己的头衔是“架构师” ，然后请了一个外包项目经理催进度。听起来挺离谱的，但是这名"架构师"却是团队真正秩序的主导者，还不用做催进度的坏人，有时候甚至还可以和开发团队共情。

在公司的环境下，盈利是商业公司的目的，那么秩序往往由利益这只看不见的手控制的。

所以很多看似愚蠢的事情也能理解了。对于能作为领导的人，你以为他很蠢，其实是坏；你以为是坏，但是其实还是为了挣钱。

而为了挣钱就是利益驱动，有的时候个体利益和群体利益毫不相干。把含铜的电线偷来卖掉，获得极少的个人利益，但是却损失了极大的群体利益，这种事情在大型企业中非常常见。

所以，道家的杨朱学派提倡秩序的建立者应当认识到这种自私的人性。形容普通人是"拔一毛以利天下而不为"的本性，热衷于奉献的人是为了在博弈中获得更大的利益，而不是当下的小利益。

利益和动机是了解软件团队中非常有利的方法。匹配其动机的事，不需要推动就会顺利，而不匹配其动机推起来就非常困难，而动机往往是和利益绑定的，即使推动某些事情会损害公司利益。

举个例子来说，推广单元测试这件事情从长期来看无论是对公司、团队领导、开发人员都是非常有益的，但是实际情况却很难推动。

因为没有人具有太多编写单元测试的动机。开发人员短期内会增加工作量，对于团队领导来说看不到快速的收益，无法纳入 KPI 管理。除非有追求的开发者，为了长期构建质量内建坚持推动外，不具备自发性推动的动机。

因此很多公司可以通过利益捆绑，在 KPI 中增加单元测试覆盖率的指标，进而制造编写单元测试的动机。

所以动机和利益给我们启示是：不要说服你觉得合适的人合作，而是筛选有动机的人合作，即使一个人图名，一个图利，甚至只是图个开心也需要有动机才能达成合作。

了解一个人的动机的威力就已经足够大了，那么如果是群体的动机呢？

这就是接下来需要讲的政治工具：形势。

如果一个人想创业的方向是和国家基本政策违背那么可以说希望渺茫，比如在减少煤炭产量的时候购买煤矿的采矿权，经营煤矿那么会非常惨烈，和前段时间 K12 教育的现象一样。

在公司内部也是一样，如果公司的发展形势是全面上云、技术栈转 Java 等战略方向，那么反其道而行自然不太好。

不过形势很难被分析看到，不然人人都是大师了。有一种说法我比较认可，形势是群体的动机，而群体的动机又是有影响力的人推动的，归根结底是人性和利益的动机。

安逸和方便的生活是整个人类社会的动机，也是科技的基本驱动力，所以搞出一些让事情变得复杂的发明自然不会有人买单。对于公司来说，盈利是其动机，因此所有活动都需要奔着盈利去。对于团队内部，群体的动机往往是领导的 KPI，那么形势也是如此。

形势的作用就像水流和船的关系，水流的方向是宏观形势的推动方向，而风向是微观形势推动的，靠引擎或者人力的推动是主观能动性。

在很多情况下，甚至只有船长具有主观能动性，其他人不过是在船底部的机舱中卖劳力而已。这些人形如我们，看不到水流的方向，也看感受不到风的方向，仅仅知道的是船长的指令。

他们虽然辛苦，但是不用过多地的耗费精神，也感受不到危险，同样也没有决策的压力。如果一个机舱中的船夫跑出来指点船长的工作，甚至舰队领袖的工作，那么大概率的情况是连船夫也没有资格做了。

而对于一名船长来说，观察风向、看清水流、识别礁石等风险才是他的工作，一名和形势对抗的船长某种程度上来说是不合格的。

博弈的平衡和秩序的形成，产生了生态位，每个人都在自己的生态位生存。从某种程度上来说文明社会并没有比生物圈更文明，只不过作为人类在和平的状态下生存环境更好了。

实力、背景和运气的差距是客观存在的，参与到竞争环境中的个体从来没有平等过，在充分的竞争下形成了某种秩序，这种秩序让个体产生了分层，也就形成了生态位。

如果把《湖南农民考察报告》再多读几遍，发现软件工程和行业也存在相似的结构。软件行业的生态慢慢分化出老板、大厂技术经理、大厂程序员、小厂技术经理、小厂程序员等层次。

如果把精力投资在深入技术上可能得结果是在生态位上被刻画的更死，因此有人把精力投资在生态位的变化上。这两种投资需要保持某种微妙的平衡，既不能太务实，也不能完全务虚。

另外，生态位切换的过程有点类似于甲壳类动物需要蜕壳，虽然在蜕壳完成后可以获得竞争力，但在蜕壳期间很危险。

这样的经历往往就是软件工程从业者焦虑的原因。大多数人都会经历从前端到后端，从业务分析师到项目经理，从技术人员到市场人员来回切换。 切换的过程中充满了不安、竞争力丢失等危险。

一位做前端的朋友告诉我他被提拔为了团队的负责人，直接管理后端、测试、产品等人员。但是他高兴不起来，原因是处于一个非常尴尬的生态位。被提拔的原因是因为在人员不稳定的公司里，他是相对工龄比较久的人。作为团队负责人却没有太多后端、产品等其他经验，无论是在当前岗位还是出去找工作都会不利。

从某种程度上来说，职业发展路线就是在不同的生态位上跳跃，每个生态位就是关键的职业节点。从某些节点上升更加平滑，有些节点上升更加陡峭，而一些节点彻底就是死胡同了。

在前面职业发展路径中聊到，职业发展就是生态位的提升，那么避免不了的两个方向就是技术和管理。

我们需要思考，为什么看似什么也不懂的管理者，收益却远比技术人员高呢？就像马云曾坦言，他不需要很聪明，但是他能找到聪明的人。这虽然是谦虚的说法，但是也表明了他无可比拟的优势和能力。

他是一名优秀的管理者，而不必做一名出色的技术人员。 其实对于管理者而言，其特质并不像普世价值说的那样：温良谦虚的君子。而更像是狮子在他的领地管理森林、草原和牛羊。

所以做技术的人和做管理者的人在认知上有两项极大的差异： 做技术的人关注创造价值，而做管理的人往往关注争夺价值。

当然这两项特质可能发生的同一个人身上，也可能某些人两者都不具备。创造价值也可以分为为别人创造价值，也可以解读成为自己创造价值。而争夺价值的人同样可以被理解为为团队争夺价值或者在团队内部为自己争夺价值。

对此种种，我们不便用世俗的道德评价它们。往往我们谈论的政治手段，更多的是争夺价值。

在争夺价值的思维里，才会分析权力的构成、形势、动机和利益问题；而在实施争夺价值行为的过程中，才会利用政治的手段。这些手段可以是具体的心理学攻势、谈判、游说等具体的行为。

心理学的技巧有：群体认同、沉默、肢体暗示、恐吓；谈判技巧有：制衡、制造稀缺；游说的技巧：利害转换。这些内容我们挑一些有趣和有用的重点讨论。

落地政治有写不完的内容，包括一些令人不齿的技巧。由于政治本身就是影响人的技术，从某种程度上来看，也有很多科学性的内容可以使用。

一些心理学的书籍坦诚的就说，某些心理学技巧就是为服务政治而来的。比如 NLP 神经语言程式学（不是自然语言处理的 NLP）就是一种通过心理暗示的方式影响他人的行为和决策。他的理论基础是：人脑是一种通过反馈不断修改和调整自己下一次判断的"程序"，这种程序可以自我学习。比如，打一个人伸出的手背，这个人就会缩回，那么下一次只要发出打手的信号，就会不自觉的缩回，这就是一种神经语言程序的修改。

人类有一些固有的思维程序可以加以利用，也可以通过某种手段修改其他人的思维程序。

举一个小的例子，在历史的场合中，和自己行为相似的人往往是同族，于是大多数人都被印上了一段行为。就是和自己行为相似的人，可以信任。于是利用这一点，我们可以通过可以模仿他人的行为、口头禅、习惯来制造信任。

这一点不用多解释，可以试一试。

政治手段除了通过心理学造成对他人的影响外，还有一个非常重要的内容，就是谈判。 谈判无处不在，有时候甚至不知道存在的情况下就发生了。在软件行业，软件工程师需要谈需求，谈方案。对于所有的人都需要谈薪资，所以掌握谈判能力的人，更具有优势。

最常见的一种谈判能力就是购物时讲价。有一些人天生就能讲价，将其谈判的能力发挥到极致。通过讲价引出的第一个认知变化就是：不要给可能设限，任何场合都有谈判的空间。当一些事情看似已成定局，或者想改变显得不可能，实际上在条件成熟时都有可能变化。

我在工作以前，以为连锁酒店的价格基本无法修改的，越是正规的酒店越没有谈判的空间。工作后，满世界飞，认知被颠覆。 18 年夏天，公司在西安组织了一次国际培训，我有幸是培训师之一。周末带其它讲师到成都旅行，到达成都后还是下午，因为没有提前定酒店，于是在街上挑选合适的酒店。

我们看到一个非常不错的花园酒店，挂牌价格为最低 800 一间。我进去打了个招呼，问了下价格，被告知价格无法修改，于是灰溜溜的出来了。在出来的一刻，同事进来找我，酒店接待的服务员看到我们十来个人，于是马上提出，可以帮我办理一个会员卡，而会员卡的价格是 300。 我被震惊了，挂牌价格和真实价格的落差如此之大，我继续询问是否包含早餐，被告知这个价格已经无法包含早餐了。经过大家七嘴八舌的抱怨后，可能是这家酒店属于淡季，最终依然满足了我们的条件。

这次讲价的经历给了我一个重要的启示：任何场合都具有谈判的空间。。博弈论是系统性被用到了商业谈判中，它有各种各样的分类方法。博弈，是社会中每一个人都需要掌握的能力，甚至比做具体的工作更重要，这里有几种博弈的分类，可以作为在处理博弈问题时作为参考。

合作博弈和非合作博弈 合作博弈是指在这次博弈中能达成共赢的局面，而非合作博弈很难达成共赢。那么，这两种场景中，需要采用不同的策略达成自己的目标。

如果能基于共赢的情况进行博弈，就可以互相摊牌，让对方看到所有信息，优先让对方达成条件，这样对方会驱动一起达成己方的条件。合作博弈 + 信息透明是最完美的合作状态，但是大多数情况下都不能达到。

如果不能做到合作博弈，博弈就变成了非合作博弈。后者在生活中更为普遍，更残酷。非合作博弈中，参与的各方都希望能达到利益的最大化，于是各方尽可能的隐藏自己的信息，了解对手的信息。

完全信息/不完全信息博弈 完全信息/不完全信息博弈是根据信息暴露状态来看的。当我们陷入不同的场景中，就可以利用信息状态的转换来实现博弈目标。

在合作博弈中，转换为完全信息博弈对双方更有利；在非合作博弈中，转换为不完全信息博弈，并且尽可能的少暴露自己的信息，了解对方的信息，成功的几率更大。

对任意一方来说信息状态有下面几种：

如果再组合一下，己方是否了解对方的信息状态，又会有三种情况：

所以，最优的状态是：

最差的状态是：

多阶段博弈 人和人之间如果只是一次交易，互相欺骗的可能性高，但是如果是持续合作，彼此更倾向于不欺骗对方。这种情况被叫做重复博弈或者又叫多阶段博弈。

认识到重复和单次博弈的区别，对我们谈判用处非常大。举个例子，旅游时用餐和在家门口用餐的博弈场景完全不同。景区的餐厅做的都是一次性生意，欺骗性极强。这种博弈在一次交易完成后一般就没有下次了，就应该尽可能保证当次的利益。

如果是商务合作中，长期合作的合作伙伴，在初期合作时，可以采取让利的策略，先建立合作关系，再从后续的交易中获得价值。

多方博弈 多方博弈是指在博弈中，参与方有多个，这样就会产生大量的博弈关系。最经典例子是国际社会中三方会谈，往往有六向双边关系将一个问题变得极其复杂。 当数量超过三时，会变得更加复杂。多方博弈时就需要达成几个目标才能取得较好的效果：