手机版|
二维码|
未经审视的人生不值得过。
——苏格拉底
在我的工作经历中，会发现有一些技术人员成长很快，能够迅速成为团队的骨干，也有一些技术人员总是在原地踏步，工作十年和工作一年的区别并不大。渐渐地，我发现这些优秀的技术人员都有一些共同的特质和素养，从而帮助他们不断进步，脱颖而出。
10.1 不教条
在软件的世界里没有“银弹”，在技术人的众多素养中，“不教条”占有重要的地位。我在工作过程中看到过太多教条主义的错误，例如，我曾见过一个团队为了做微服务，将本来的一个不大的应用拆分成了几十个微服务应用。
教条的主要原因是我们还停留在有样学样的阶段，导致我们忘记了 软件的第一性原理是“控制软件复杂度”。但凡能提高代码可读性、可扩展性和可维护性的方法，都是值得考虑的，并不一定要拘泥于某种特定的开发过程或者编程范式。
就像 Effective Java 一书的作者Joshua Bloch说的，“同大多数学科一样，学习编程艺术首先要学会基本的规则，然后才能知道什么时候去打破规则”。
10.1.1 瀑布还是敏捷
选择软件开发过程绝不是要么瀑布（Waterfall），要么敏捷（Agile）这么简单。实际上， 软件开发的生命周期风格类似一个连续光谱——有从瀑布式到敏捷，以及它们之间的多种可能性。
以我的工作经验来看，软件开发过程并不是软件工程中最大的障碍，不是你花了大量时间在需求分析和设计上，项目就一定会失败；也不是你每天早上花5分钟讨论“昨天做了什么，遇到什么问题，今天做什么”，项目就一定能成功。
敏捷开发是基于迭代模型发展起来的一套软件开发指导原则。我们在实际操作中应重视指导原则，弱化方法论。
就像Scrum的创始人Jeff Sutherland在其敏捷宣言中说的，“我建立Scrum模型就是为了把敏捷的价值观糅进一套工具集以便于更好地实践， 敏捷模型没有方法论。”
敏捷还有一个误区，就是弱化设计。其实我对此事的认知也是有一个过程的，我是敏捷的极力拥护者，非常感激敏捷让我们摆脱了软件能力成熟度集成模型（Capability Maturity Model Integratio，CMMI）的沉重枷锁。凡事过犹不及，实施敏捷就可以“无设计”吗？设计可以在敏捷过程中自然涌现吗？实践告诉我们，似乎不能。就像盖房子，在盖之前要打牢地基，如果地基还没完工就匆忙建造房子，那么就很难摆脱糟糕的地基了。类似地，系统架构中的基础改动起来会变得困难，从而不得不做出各种妥协和临时方案。
因此，我们需要在大设计和无设计之间找到一种平衡。一个软件从无到有，不管你是瀑布、迭代，还是敏捷，一般会经历下面的过程。
（1）需求：对于系统该做什么，建立并保持与客户和其他涉众的一致意见，定义系统的边界。
（2）分析与设计：将需求转化为系统设计，设计将作为在特定实现环境中的规格说明，包括逐渐形成一个健壮的系统架构，建立起系统不同元素必须用到的共同机制。
（3）实现：编码、单元测试以及对设计进行集成，得到一个可执行的系统。
（4）测试：对实现进行测试，确保它实现了需求，通过具体的展示来验证软件产品是否像预期的那样工作。
（5）部署：确保软件产品能被它的最终用户使用。
基于此，我推荐一种综合了瀑布模式、迭代模式和敏捷思想的软件开发过程。在此提倡根据迭代所处阶段的不同，在不同科目上花不同的时间，如图10-1所示，灰色部分代表一个阶段在当前迭代中所花时间的比重。
图10-1 改良的迭代开发
10.1.2 贫血还是充血
一提到事务脚本（Transaction ）和DDD，人们就习惯性地给它们扣上贫血 [1]和充血的帽子。简单来说，贫血模式提倡模型对象只包含数据，并提供简单的Getter和Setter；而充血模式提倡数据和行为放在一起，是一种更加面向对象的做法。两种模式都有自己的道理，也都有人支持。
在我看来，这种争执是没有必要的，因为没有抓住问题的本质。问题的核心不在于行为和数据是否在一起，而在于你能否有效地控制复杂度。如果你有很好的面向对象思维，使用贫血也可以写出好的代码；没有面向对象思维，即使采用DDD，也会陷入复杂性的泥潭。
纠结于贫血还是充血，一方面是因为没有抓住问题的本质，另一方面也源于一种非黑即白的教条思维。就像4.2节中的Rectangle案例所展示的，行为和数据是否放在一起，只是表现形式的差别，并不是用来区分面向对象和面向过程的关键区别。
10.1.3 单体还是分布式
在业务发展早期，因为用户少、流量少，功能相对简单。如图10-2所示，基本上单体（Monolithic）应用架构就足以支撑业务的发展。
图10-2 单体应用架构
然而，随着业务的发展和用户的增加，单体应用的局限性开始显现。具有水平扩展性（scale out）的分布式系统架构几乎已经变成互联网公司的标配，如图10-3所示。
图10-3 分布式应用架构
虽然面向服务的架构（Service Oriented Architecture，SOA）和微服务有一统天下之势，但是并不代表单体架构就会退出历史舞台，特别是在中台概念提出来以后。中台要求通过集中式的中台管控来提升软件系统的复用，避免趋同的业务重复造轮子的现象。中台的目的就是要通过中台能力来赋能前线业务，提升对前线业务的支撑效率，其架构如图10-4所示。
图10-4 中台架构
可以看到，中台虽然也是对业务进行聚合，但并不是对单体架构的简单回归，而是综合了分布式理念之后升级版的“超级单体”。正是这种不教条和辩证的发展思维，才推动互联网架构不断地向前发展演进。
10.2 批判性思维
批判性思维（Critical Thinking）是一种谨慎运用推理去断定一个断言是否为真的能力。它要求我们保持思考的自主性和逻辑的严密性，不被动地全盘接受，也不刻意地带着偏见去驳斥一个观点。批判性思维也是一项能够被习得，并且通过训练和运用来提高的能力。
技术人员虽然有很强的逻辑推理能力，但不见得都有很强的逻辑思维，我也是如此。在知晓批判性思维之前，我曾吃过很多亏，明知道对方在强词夺理，可就是找不到很好的反驳理由。无论是在公司和同事争辩，还是在家里和老婆斗嘴，几乎没有赢过。后来我学习了一些批判性思维的知识，情况才有所改观，可以抓住对方的一些逻辑漏洞和推理谬误进行反驳，这使我在职场上拿回了不少话语主动权。不过在家里，我依然是输多赢少，后来我才发现，原来家不是一个讲逻辑的地方。
关于训练批判性思维的书有很多，我重点推荐两本，一本是尼尔•布朗写的被誉为批判性思维领域经典读物的《学会提问》，另一本是樊登读书会推荐的《思辨与立场：生活中无处不在的批判性思维工具》。我在读这两本书的时候，经常会有aha moment（顿悟时刻），真的很有收获。
在《学会提问》一书中，有这样一个案例。
小张：“小王真不是个男人，酒吧里那个醉汉威胁说要揍他一顿，他吓得屁滚尿流。”
小李：“他要不是男人，你怎么解释他身上那些鼓鼓的二头肌呢？”
你觉得小李的话有道理吗？如果你觉得有点道理，但又觉得有点不对劲，那么就应该去好好读读这本书。这里小李犯了一个典型的推理谬误——偷换概念谬误（Equivocation Fallacy），小张说的“男人”是指“男子气概”，而小李说的“男人”是指“男人生理”，这两个概念是不一样的，这就是问题所在。
10.3 成长型思维
成长的过程中不可能是一帆风顺的，肯定会有痛苦、有阻力、有挫折。面对逆境，我们应该怎么做？有些人也许不堪重负，就此沉沦了，而有些人可以越挫越勇，把每一次失败都当成学习的机会。研究发现，成长型思维（Growth Mindset）和固定型思维（Fixed Mindset）会极大地影响我们面对逆境的处理方式。我在最低迷的时候，正是成长型思维帮我渡过了难关。
斯坦福大学心理学教授卡罗尔•德韦克在经过数十年的研究后，发现了 思维模式的力量。她在《终身成长》中提醒我们：我们获得的成功并不是能力和天赋决定的，更多受到我们在追求目标的过程中展现的思维模式的影响。
成长型思维和固定型思维体现了应对成功与失败、成绩与挑战时的两种基本心态。你认为才智和努力哪个更重要、能力能否通过努力改变，决定了你是会满足于既有成果，还是会积极探索新知。通过了解自己的思维模式并做出改变，人们能以最简单的方式培养对学习的热情，以及在任何领域内取得成功都需要的抗压力。
具有成长型思维的人相信自己可以通过学习来提升自我，相信学习和成长的力量，相信努力可以改变智力和能力。我们可以通过图10-5所示的对比来判断一个人是“成长型思维”还是“固定型思维”。
图10-5 成长型思维和固定型思维对比图
我曾经就是一个典型的固定型思维的人，在遇到困难和挫折时很容易引发自我怀疑和自我否定。在了解了成长型思维之后，我开始逐渐转变思维模式，会用更加理性的态度看待一时的成败得失，内心坚定地相信成长和学习的力量。从某种意义上来说，你正在读的这本书也是我在习得了成长型思维之后，才得以写出来的。
技术人员的工作面临着很多的挑战，我们需要具备成长型思维才能应对工作和生活中的压力，这样在遇到问题时，我们才不会轻言放弃，而是会积极主动地去学习，去寻找解决方案。即使最终还是失败了，我们也不会一蹶不振，而是把失败当作学习的机会。
10.4 结构化思维
在日常工作中，我们时常会碰到有的人讲一件事情的逻辑非常混乱，前后没有逻辑性关联，甚至无法把一件事情说清楚。思维混乱是缺少结构化思维的典型表现。实际上，我们不仅在表达上要结构化，在分析问题时更要有结构化思维，这样才能分析得更全面、深刻。
什么是结构化思维呢？我给结构化思维的定义就是 “逻辑+套路”。
1．逻辑
所谓逻辑，是指结构之间必须是有逻辑关系的。例如，你说话时用“第一、第二、第三”这个逻辑顺序是合理的，而如果用“第一、第二、第四”就会显得很奇怪。实际上，组织思想的逻辑只有4种。
（1）演绎顺序：比如“大前提、小前提、结论”的演绎推理方式就是演绎顺序的。
（2）时间（步骤）顺序：比如“第一、第二、第三”和“首先、再者、然后”等，大多数的时间顺序同时也是因果顺序。
（3）空间（结构）顺序：比如“前端、后端、数据”和“波士顿、纽约、华盛顿”等，化整为零（将整体分解为部分）等都是空间顺序。在做空间分解时，要注意满足“相互独立，完全穷尽”（Mutually Exclusive Collectively Exhaustive，MECE）原则。
（4）程度（重要性）顺序：比如“最重要、次重要、不重要”等。
只要我们的思想和表达在这4种逻辑顺序之内，就是有逻辑的，否则就是没有逻辑的。
2．套路
套路是指我们解决问题的方法论、路径和经验。比如，5W2H分析法就是非常好的，是可以帮助我们分析问题的一个“套路”。试想一下，面对任何一个问题，你如果都能从“Why、Who、When、Where、What、How和How much”（如图10-6所示）这7个方面去思考，是不是比不知道这个方法论的人用点状模式思考要全面得多呢？
图10-6 5W2H问题分析法
逻辑是一种能力，而套路是方法论、经验；逻辑属于道，而方法论属于术。二者都很重要，只有熟练地掌握二者，我们才能有更好的结构化思维。接下来，通过两个案例来介绍结构化思维在实际工作场景中的应用。
10.4.1 如何落地新团队
想象这样一个场景，你刚刚入职一家新公司或者转岗到一个新团队，作为一个技术人，你将如何落地开展工作呢？
这里就能用上结构化思维来帮助我们理清思路，从而有条不紊地开展工作。要知道对一个企业来说，核心要素无外乎就是 业务、技术和人。我们所要做的就是如何去熟悉业务、熟悉技术、熟悉人，然而每一部分又可以进行进一步的结构化拆解，如图10-7所示。
图10-7 落地新团队的策略
1．熟悉业务
（1）了解产品形态：任何一个团队都有自己要负责的产品，申请一个测试账号去用一下产品，是熟悉产品比较好的方式。
（2）了解业务流程：任何业务都有自己的业务流程，而业务流程中的核心是信息流。我们可以通过人员采访了解关键节点的信息输入和信息输出；通过画一些泳道活动图来理清楚系统的主要角色，以及它们之间的交互关系。
（3）走访客户：通过走访客户，我们可以获得业务的第一手资料，更加贴近业务和客户诉求。
2．熟悉技术
（1）了解系统架构：可以让团队的技术人员介绍他们当初做系统设计和架构时的思路。
（2）了解领域模型：查看关键的核心表结构和系统API，快速了解系统的领域模型。
（3）了解代码结构：下载系统工程，熟悉整个工程结构和模块职责；以一个最重要的流程为入手点，阅读代码，看清楚核心的执行逻辑；做一个小需求，掌握相关的流程和权限。
3．熟悉人
（1）了解组织结构：查看公司的组织树，知道公司大概是如何运作的，以及哪些是关键人（Key Person，KP）。比如，一个典型的电商公司会包括产品部、运营部、销售部、技术部、人力资源部、财务部和法务部等。
（2）了解人员角色：了解公司都有哪些岗位，以及各岗位的职责范围。
（3）勤沟通：找出和自己工作息息相关的岗位，比如产品和运营，积极和这些同事沟通，向他们请教业务问题，多多交流。这样既可以建立良好的人际关系，也可以更快地熟悉业务。
10.4.2 如何做晋升述职
我在阿里巴巴已经做了多年的晋升评委，发现很多人都缺乏结构化思维，讲着冗长的PPT，却不能很好地把一件事情说清楚。实际上，做工作汇报或者述职是很容易结构化的。
最清晰和实用的结构化表达是“ 提出问题，定义问题，分析问题，解决问题，最后展望未来”。如果按照这个逻辑顺序去阐述一件事情，会比不知道这个“套路”的效果好得多。这也是麦肯锡常用的解决问题的框架。
另一个有用的思维框架是“zoom in/zoom out”。 我们说事情时，应该像电影镜头一样，先从远拉近，再由近拉远。“zoom in”是先从宏观背景开始，首先让大家知道你的事情发生的背景，为什么这件事情很重要？然后讲到具体细节，怎么做成的？解决了什么问题？后端思考是什么？最后“zoom out”，从细节调回到整体，结果是什么？带来的客户价值是什么？你对未来的思考是什么？
可以看到，这些结构化的方法论可以帮助我们做到事半功倍，经常锻炼结构化思维可以极大地提升我们的职场竞争力。
