程序员的底层思维~张建飞

前言

◆ 成人学习的目的不是获取更多的信息量，而是学习更好的思维模型。

◆ 好的思维能力是可以被复制和迁移的，它应该是普适的，而不应该有行业的界限。

第一部分 基础思维能力

◆ 因为语言的抽象性，我在团队中会要求大家使用通用语言(Ubiquitous Language)进行沟通交流，因为只有大家对概念的认知达成一致，沟通交流起来才会顺畅，而程序只是我们程序员之间的一种交流方式。

◆ 这也是我在做设计和代码审查(Code Review)的时候，会特别关注命名是否合理的原因。因为命名的好坏在很大程度上反映了我们对一个概念的思考是否清晰、抽象是否合理，反映在代码上就是代码的可读性、可理解性是否良好，以及我们的设计是否到位。

◆ 有人做过一个调查，问程序员最头疼的事情是什么。Quora和Ubuntu Forum的调查结果显示，程序员最头疼的事情是命名。如果你曾经为了一个命名而绞尽脑汁，就不会对这个结果感到意外。正如Stack Overflow的创始人Joel Spolsky所说：“Creating good names is hard，but it should be hard，because a great name captures essential meaning in just one or two words.”（起一个好名字应该很难，因为，一个好名字需要把要义浓缩在一到两个词中。）

◆ 这个浓缩的过程就是抽象的过程。我不止一次发现，当我觉得一个地方的命名有些别扭的时候，往往就意味着要么这个地方我没有思清楚，要么是我抽象错了。

◆ 这样的斟酌是有意义的，因为明晰关键概念是我们设计中的重要工作。虽然不合理的命名和不合理的抽象也能实现业务功能，但代价就是维护系统时的极高的认知负荷。随着时间的推移，也许就没人能搞懂系统为何这样设计了。

◆ 提取重复代码只是重构工作的第一步。对重复代码进行概念抽象，寻找有意义的命名才是我们工作的重点。

◆ 修改接口是一件很难的事情，因此在最初设计API的时候，要尽量做到抽象完整。

◆ 有时，不合理地抽象比没有抽象对系统的伤害更大。

◆ 任何软件系统的设计都基于归纳法，而非演绎法，即软件设计人员总是通过对现有世界和业务的总结提炼，而无法通过推测演绎完成软件设计。设计人员无法对业务的未来做出预测，只能基于有限的经验，尽量保证设计的灵活性和正确性。

◆ 理解这一点非常重要，这会让你在软件设计、产品设计时心存敬畏，不会因一味地追求短期无法论证的结论而产生严重的过度设计。在实践中，对于基于抽象复用的平台建设，有以下几条建议。

(1)对于明显具备共性的模块，尽早抽象。在B端产品的体系化设计中，很多形态的产品是具备明显共性的，我们可以尽早地进行抽象设计，这样在系统架构建设的早期就能做出正确的设计方案，而且并不会过多地增加研发工作量，相反会让未来的系统扩展更加轻松。例如，业务系统中的统一权限管理系统、单点登录系统、组织架构系统、公告系统、短信系统等，都应该尽早完成抽象建设。

(2)对于共性不确定的模块，事后抽象。对于统一客户视图、订单中心、商品系统等软件模块，很难判断在多业务线场景下是否能够完全复用。如果对于是否进行抽象拿不准主意，那么完全可以先不做，等业务渐渐明确后，有足够的信息做出充分的分析和判断时，再决定是否合并抽象设计。

◆ 抽象层次越高，内涵越小，外延越大，泛化能力越强。然而，其代价就是业务语义表达能力越弱。

◆ 抽象层次一致性原则(Single Level of Abstration Principle, SLAP)应运而生。SLAP是ThoughtWorks的总监级咨询师Neal Ford在《卓有成效的程序员》一书中提出来的概念，其思想源自Kent Beck提出的组合方法模式(Composed Method Pattern, CMP)。

SLAP强调每个方法中的所有代码都处于同一级抽象层次。如果高层次抽象和底层细节杂糅在一起，就会显得代码凌乱，难以理解，从而造成复杂性。

◆ 在结构化思维中，有一个要点就是结构的每一层要属于同一个逻辑范畴、同一个抽象层次。

◆ 为什么阅读书籍比看电视更好呢？因为图像比文字更加具象，阅读的过程可以锻炼我们的抽象能力、想象能力，而画面会将我们的大脑铺满，较少需要用到抽象和想象。这也是我们不提倡让小孩子过多地暴露在电视或手机屏幕前的原因，因为这样不利于锻炼他们的抽象思维。

02 逻辑思维

◆ 按照《逻辑学导论》中的定义，逻辑学是研究用于区分正确推理(inference)与不正确推理的方法和原理的学问。

◆ 对概念的明晰和定义是我们设计过程中的重要内容。在一个领域内，如果一个系统的核心概念的定义出现了问题，可能会给上层的业务带来毁灭性的打击。

◆ DDD的核心就是强调概念和语义，概念的重要性体现在通用语言(Ubiquitous Language)上，语义的重要性体现在界限上下文(Bounded Context)中。一个团队只有具有统一的语言概念基础，并划分了清晰的边界，才能更好地沟通协作；文档和代码中的核心概念只有保持一致，才会具备更好的可读性和可理解性。因此，我建议，任何领域都应该有一份核心领域词汇表，方便团队在这些核心概念的表达和命名上达成共识。

◆ 概念是一切的基础，要提高逻辑思维能力，就要从弄清楚每一个概念所表达的具体内容（内涵和外延）开始。

◆ 概念技能是管理者对复杂情况进行抽象和概念化的技能。在基础管理中，技术技能所占的比例较大；而在高层管理中，处理无形事物的概念技能就显得尤为重要了。因为越到高层，越需要快速的理解能力、良好的表达能力，以及快速抓住问题本质的能力。

◆ 1845年，科学家发现天王星的运动数据和其他行星比起来出现了2分钟的弧度差值。勒维耶提出一个假设：天王星的差值是由另一颗（未发现的）行星引起的，基于这样的假设，那颗新行星——海王星很快被发现。对于程序员来说，基本每天都在运用这种溯因推理。我们通常说的故障排查(Trouble Shooting)就是溯因推理，用的手段基本上也是假设和求证。

◆ 当你看到一个关键词在论证中不止一次地出现时，就要注意其意义有没有发生改变，如果意思发生改变，那么要警惕偷换概念的谬误。高度含混的术语和词组是偷换概念的绝佳材料。

◆ 每个人的背景和身份不一样，代表的利益不一样，所以在话语中经常带有自己的价值倾向，只有把这些隐含的假设暴露出来，我们才能进行正确的判断。

◆ 以偏概全是使用归纳法时常见的谬误，即使用过小的样本量或者不具代表性的样本，归纳得到一个错误的结论。比如，用某一张偏方治好了某个人的某种疾病，如果据此得出“这张偏方具有治疗该疾病的作用”，那就错了。现代临床医学研究总是强调大样本、多中心、随机、双盲和对照试验，目的就是避免在运用归纳法时陷入以偏概全的谬误。

03 结构化思维

◆ 写出优雅的代码也许不在于运用多么高深的技法，而在于是否能静下心来把结构梳理清楚。

04 批判性思维

◆ 《选择的悖论》一书中提到，如果有100个选择却只能选择其中一个，那就意味着我们选择任何一个，都会失去另外99个选择。而我们天生有损失厌恶的倾向，所以选择意味着满足感和幸福感的下降，甚至会带来焦虑。

◆ 研发≠写代码，实际上我们大部分时间不是在写代码，而是在沟通协调，况且与人打交道要比与机器打交道麻烦得多。这也是《人月神话》一书中说“加人只会让项目更糟糕”的原因，因为额外增加了更多的协作成本。

◆ 正如尼古拉斯所说，在现代生活中，简单的做法一直难以实现，因为它有违某些努力寻求复杂化以证明其工作合理性的人所秉持的精神。

◆ 例如对于商品业务，淘宝的商品、盒马的商品、零售通的商品之间可能存在巨大的差异，它们的扩展属性和业务校验规则都不一样。这种情况就适合把中台做得很薄，让其退化成EJB中的Entity Bean。这也是业务中台的底线，即业务中台要做统一的数据收口，防止产生数据孤岛。即使是薄中台，也是极其有价值的，因为它能帮助我们解决商品的存储、存储扩展、性能、稳定性、工具（商品360、forest类目管控）、搜索构建等一系列和业务无关的非功能属性问题，这就足够了。

◆ 架构需要在重用高耦合和重复低耦合之间做一个权衡，所以代码重复(Ctrl+C/Ctrl+V)并不总是差的，而是一种设计选择。

◆ 能使团队更加敏捷的架构师比只做决定的架构师要更有价值，因为只做决定的架构师会成为团队的瓶颈(bottleneck)。显然，一个架构师的价值和他做的决定是成反比的。实际上，在这篇文章中，Martin甚至不认为架构师(Architect)这个名词是合适的，他认为更合适的叫法应该是向导(Guide)，即一个更有经验的人带领团队走出复杂的迷雾。

◆ 在阿里巴巴的B2B部门曾经就有这样一个架构组。我记得在当年的启动会上，负责人要求我们画架构图，我质问他这个架构组存在的意义是什么。如果只是画架构图，给老板当PPT用的话，那么我不愿意画这个图。

实际上，画架构图这种务虚任务还好，虽然用处不大，但也构不成杀伤力。真正构成杀伤力的是架构组不甘无为而挖空心思要“做事情”。可以说，在业务技术部门，架构组这种想做事的行为是很危险的，事情越大，杀伤力越大。

为什么这么说呢？我们不妨先来看一下，在业务技术部门中的架构组能做什么。

(1)业务架构？我是营销域的、订单域的、商品域的、供应链域的……如果架构组想比产品经理、运营人员、工程师更懂业务领域、业务流程和业务细节，恐怕很难。一个合格的产品经理应该能做好业务领域的抽象和业务流程的抽象，至于细节，好像没有人比一线开发人员更懂。——架构组，卒！

(2)应用架构？需求相对清晰之后，在应用架构领域有一些影响力的团队负责人(Team Leader, TL)在和团队讨论边界划分和设计方案的时候，尚且会时常争论不休。架构组的“外人”想来指手画脚？这是多么碾压程序员的自尊心啊！——架构组，卒！

(3)技术架构？好吧，让我们架构组回归技术本身，做点纯技术的事情。可是对不起，但凡有点价值的技术中间件都已经有中间件团队在做了。——架构组，带着整个部门一起，卒！

因此，在企业内部设立架构部门是一件要十分谨慎对待的事情。

对一个企业来说，在某个特殊阶段，也许的确需要实体架构组织去保障落实架构工作。但在大部分情况下，特别是在技术体系已经相对完备的情况下，最好不要在部门(Business Unit, BU)内设立专门的架构组织。在我的职业生涯中，我看到过很多业务技术部门尝试设立技术架构组织，基本都以失败告终。

◆ 很多后劲不足的人主要是过早地停止了学习和成长，你的能力应该是围绕着你的层级上下震荡的，这个震荡范围偏差不会太大，迟早会归于一个相对合理的区间。

◆ 你不仅要熟悉业务架构、精通技术架构，还要通过组织架构设计去解决部门墙问题，让生产关系适应生产力的发展。唯有如此，才能使技术稳定高效地支撑业务发展。

◆ 很难想象一个没有技术追求的团队能开发出一个健壮、可维护性好、可扩展性好的系统。业务代码的堆砌，从短期看也许较快实现了业务需求，但是从长远来看，这种烂系统的增加会严重阻碍业务的发展，形成一个个的“屎山(shit mountain)”系统，而工程师被裹挟在业务需求和烂系统之间心力交瘁。

◆ 现在很多的技术人员一旦晋升到TL岗位就开始脱离技术工作，俨然一副“道法自然”的模样。试想，如果一个TL从来不关注技术、不写代码，对技术没有热情也不学习，甚至其本身技术就很差，那又怎么能指望在他领导下的团队能有技术味道呢？实际上，我们不需要这么多“高高在上、指点江山”的技术管理者(Manager)，而是需要能真正深入系统和代码细节中，给团队带来实实在在改变的技术领导者(Leader)，

◆ 很多会议其实是低效无意义的，所以TL需要更注重独立思考，而不是人云亦云。

◆ 雷军说过，永远不要试图用战术上的勤奋，去掩盖你战略上的懒惰。这句话用来形容大部分的PD简直再贴切不过了，所以我宁愿PD“无为”，也总比做出很多无价值的产品要好，很多系统的复杂性就是由大量无意义的需求造成的。在一定程度上，技术人员的疲于奔命，内因是团队缺失技术味道，外因主要是PD的乱作为。这里给PD的意见是：请一定要深入理解并思考业务，不要退化成一个PPT设计师和业务需求的传话筒，不要只停留在写PRD、画Demo上，要用系统化的思维来规划产品并解决业务问题，从而赢得技术人员的尊重。给TL的意见是：TL必须深入思考业务，严格把控PD提出的“客户需求”，把伪需求、无价值需求挡在门外，防止它们侵占团队原本有限的技术资源，从而让技术团队将更多的精力投入到系统优化上去。

◆ 不要把自信建立在贬低他人的基础上，什么时候你能发自内心地欣赏你不喜欢的人，你就成长了。

05 维度思维

◆ 如果一个人一生只能收到点状努力的即时收益，从来没有享受过一次线性周期的成果回报，这就叫穷人勤奋的一生。

◆ 这些年我一直在电商领域工作，发现但凡一个业务做大了，里面的每个功能都会变得复杂。

◆ 业务代码的复杂度主要取决于业务场景和业务流程的复杂度。再复杂的业务，其业务场景都是可以枚举的，关键是找到构成业务场景的核心要素。

06 分类思维

◆ 不存在所谓的“完美”分类。分类具有主观性，Coombs曾说：“如果要将系统划分为对象系统，那么有多少架构师参与这项工作，就可能有多少种划分方法”。

07 分治思维

◆ 分治的价值在于，我们不应该试着在同一时间把整个问题域都塞进自己的大脑，而应该试着以某种方式去组织问题，以便能够在一个时刻专注于一个特定的部分。

08 简单思维

◆ 简化本质上是一个熵减活动。所有的事物都在缓慢熵增，就像凯文·凯利在《必然》一书中提到，世间万物都需要额外的能量和秩序来维持自身，无一例外。这就是著名的热力学第二定律，即所有的事物都在缓慢地分崩离析。而熵减就是逆向做功，即通过更多的努力让混乱的系统重新归于秩序。

09 成长型思维

◆ 成长美学的特征就是相信积累的效应，对人生持有固定论，本质只是为拒绝改变寻找的理由和借口。相信发展，相信改变，容易形成正反馈，以微弱优势聚沙成塔，成功世界本就来自一只蝴蝶挥挥翅膀的触发，这就是我能从低谷爬起来，并持续成长的秘密。

◆ 不同的人在面对竞争、失败、挫折的时候，会有不同的想法和做法，这个反应就是你的思维模式。

◆ 比如，总是觉得自己没有准备好。事实上，无论什么事情，我们都很难一次性做到尽善尽美，通常只能是通过一次次的试错、一次次的调整，才能让事情趋近于完美。正是在这样的试错和调整中，我们能获得进步和成长。就像提交给上级领导的方案，不管你如何做，领导多多少少总能找到一些瑕疵，但也正是因为他提出的这些瑕疵，才能让你下次做得更好。所以，不要总是等什么都准备好了才开始行动。

◆ 生活中，最好的状态是什么？就是全神贯注地做你当前正在做的事情，不论是学习、工作、思考，还是娱乐。但对于有些人来说，这种状态可能是一种“奢侈品”。

◆ 对于一件事情，如果你想不到特别有力的不去做的原因，那么就优先选择去做。也可以把这句话作为我们提升行动力的信条。

◆ 只有去行动了，你才能把未知变成已知，把不确定变成确定，让它们在大脑中得到安放和处置，不再干扰你的思考。

◆ 巴菲特说，人生就像滚雪球，关键是要找到足够湿的雪和足够长的坡。好在，在技术领域，“雪”是足够多的，而且“坡”也足够长，关键看我们能不能坚持下去，但凡能持续学习和持续精进的人，其结果都不会差。

◆ 也许你也时常能听到这样的说法：“某某炒股赚了100万。”“谁谁都晋升到副总了，你都30岁了，怎么还在写代码？”在这个时代，人极易变得浮躁。也难怪，同龄人之间巨大的竞争压力，家庭沉重的经济负担……即使是“佛系”的技术男，也难逃世俗的漩涡。平和的心态是我们持续成长的基础，因为人的专注力是有限的，内心平和的人可以更多地专注在学习和工作上；而内心挣扎的人，需要支配更多的精力去应付内耗，那么投入在学习和工作上的精力自然就少了。因此，拥有一颗平常心，不患得患失，不急功近利，非常重要。这样在你遇到困难时，才知道怎样与自己和解，并知道如何应对焦虑，把精力专注在解决问题而不是内耗上。

◆ 追求内心平和有一个简单技巧——正念呼吸，即每天花一些时间，把思绪都集中到呼吸上，抛开杂念，只专注呼吸，让眉头舒展开，让僵硬的肩膀放松下来……经常这样锻炼，可以让自己平静。比如，在跑完步之后，我喜欢闭上眼睛坐在那里，感受汗水，聆听心跳，享受运动带来的“成就感”；在吃柚子之前，我喜欢闻一闻柚子的清香味，感受食物的美好。