目录
什么影响架构的成败
架构师的六大生存法则
一、所有的架构规划必须有且只有一个正确的目标
二、架构活动需要尊重和顺应人性
三、架构活动在有限的资源下最大化商业价值
四、架构师要考虑依赖的商业模块和技术生命周期
五、架构师为什么要关注技术体系的外部适应性
架构师能注入外部适应性
不同职能之间视角的差异性
影响技术体系外部适应性的因素有哪些
六、如何鉴别文化环境是否有利于架构师的生存
如何识别企业的真实文化环境
架构师如何在小范围内打造一个友善的文化环境
生存法则的逻辑是什么
什么影响架构的成败
架构活动就是制定并且交付架构方案的过程。在整个软件架构的活动过程中，我们作为一
个架构师，首先要做的就是确定架构设计方案。
这个方案需要和企业目标一致，与商业、软件环境相匹配，并且还需要满足各种资源的约
束条件。而你作为一个架构师，要在这些方案中找到那个能够最小化资源和成本，最大化
商业价值，以及最大化目标用户满意度的方案。最终，你还要组织技术团队交付这个架构
设计方案。
架构师的六大生存法则
一、所有的架构规划必须有且只有一个正确的目标
所有的架构规划必须有且只有一个正确的目标，而且它必须与公司的战略意图相匹配，这是你架构设计的起点。否则，系统就会变得复杂和无序，缺少结构性。
目标缺失的两大根因
- 技术上：目标缺少全局视角
- 业务上：目标太多、不明确
你作为一个架构师，怎么判断一个目标是不是正确的呢？我的建议如下：
- 首先，要用企业的战略意图去鉴定架构活动目标的正确性。
- 接着，如果目标与战略意图不匹配，那么你要试图影响甚至是改变这个目标。你可以与架构项目的发起人反复沟通，陈述你的理由，建议他去寻找另一个更接近战略意图的目标。
- 如果目标与战略意图匹配，那你要看看是否存在一个更合理的目标，可以让企业能够更快地逼近战略意图。
一个架构活动目标和企业战略意图相匹配，指的是架构活动对一组 KPI 的贡献，需要与对表达企业战略意图的 KPI 形成增强关系。简单来说，就是你的 KPI 对战略意图是有正向贡献的。
在彻底理解新方案的价值之后，你就可以比较客观地思考这么六个问题：
1.新方案的实现成本有多少？
2.新方案上线后带来的短期价值有多大？
3.这个新方案是否可以全面替代现有方案？
4.全面替代的实施成本有多少？
5.全面替代之后，这个新方案带来的长期价值是什么？
6.如果不能全面替代，而是两套方案并存，那么增量的维护成本有多大？
架构活动的起点，也是甄别架构方案的主要输入，所以架构师有义务影响和干预这个目标，以确保目标本身的正确性。
如果这个架构原则能起什么作用的话，我想就是在你最需要勇气的时候帮助你。
这个原则让你能够找到现有方案的弱点，看到这个目标和公司大目标不匹配的地方，然后让你有勇气站出来敢讲真话。讲真话的时候，不是你在反对你的上级，而是你在用一个架构原则来判断另外一个人的决策质量。
以下是比较有见解的评论：
东百老师的课总是一针见血，如迷茫黑夜中的一缕阳光，更如技术人员职业荒漠中日夜期盼的甘露。只有经历过国际顶级巨头的洗礼+国内互联网的锤炼后，依然保持人性最为光明的良知，才能有如此非凡的见识，实在稀有难得。
二、架构活动需要尊重和顺应人性
在架构设计中如果能尊重和顺应人性，也就是人的基本感受和合理需求，那么我们也会拥有另一个解决问题的视角，辩证思考我们正在从事的架构工作。
架构师为什么要学习马斯洛的需求理论？
如上图所示，假设一个人同时存在 5 个需求，需求 1 和需求 2 已经被满足了，那么这两个
需求就不会再诱发动机。而需求 3、4 和 5 没有被满足，它们会同时诱发各自的动机。但
由于需求 4 和 5 诱发的动机被需求 3 所压制，因而最终是需求 3 诱发的动机，在组织和驱
动这个人整体的意识和行为。
我们来总结一下马斯洛理论的第一个重点。马斯洛理论的本意是：我们可能同时并行存在着多个需求，这些需求之间并不存在依赖或层次关系。如果这些需求得不到满足，那么它们各自会诱发机。但动机有优先级，且具备抢占性质。所以任何时候，只有一个动机在主导着整个人的意识和行为。
站在马斯洛的理论上来看，许多企业经常挂在口上的“拥抱变化”的价值观，其实是反人性的。这个价值观要求员工去接受一个他们本来认为是不连续的、不安全的、不一致的，甚至有可能是不公平的处境。有些企业认为文化宣讲频繁了，员工就会接受了，但至少马斯洛不是这么认为的。马斯洛认为除非这种内在的需求被长期满足了，才不再成为主导动机。靠外在的宣传，是没有用的。有底气的自尊也一样，这是发自内心的需求，不是说大家认为你应该有自尊你就有自尊了。而是你内心认为自己具备这种自尊，那你才会真的具备。
换个角度来说，对于一个员工而言，如果一家企业能满足他的自尊，让他感觉到自己是被需求的、被认可的，也会给他带来自信、成就感和工作的高度投入。
当生理需求得不到满足，那么源于生理需求的动机 1 就会处于主导地位，并且会屏蔽其他动机。只有生理需求得到满足了，那么处于生理需求之下的、未满足的安全感，才能诱发以获取心理安全感为目标的动机，然后成为主导动机。以此类推。
这种从共情出发，深度理解和尊重用户的做法，就是设计思维的精髓所在。之所以能提出
这个方案，主要在于我们拥有了另一种看待问题的视角：
到这里，在架构活动中考虑和顺应人性的必要性和重要性，相信你已经很清楚了。那么接
下来一个更为重要的问题就是：在软件架构活动中该如何顺应和考虑人性呢？接下来两节
课，我们会着重来讨论。
在这个信息过载的时代，超越他人的一个行之有效的办法，就是从源头来获取知识，从而掌握他人所看不到的规律，获得超出常人的理解，帮助指导架构工作，甚至是帮助我们实现超越性的突破。
划分微服务的粒度不仅需要考虑研发的人性，还要考虑服务本身的原子性、团队大小、团队人员的稳定性、服务的高可靠性要求等等。不过单从人性角度思考，如果你独立负责一个核心微服务的话，那么你的安全感和自尊都是最大化的。
从研发 ROI 的角度来思考微服务粒度的问题，我们还可以从微服务本身的设计出发来思考。微服务的核心价值在于以下几点：
- 粒度小，单个服务可以紧贴业务快速迭代；
- 去中心化组织和部署结构，减少不必要的协同；
- 数据和商业逻辑受同一个服务控制，从而在商业逻辑快速变更的同时，保障数据模型的一致性；
- 数据和状态独立封装，保障一个业务快速演变的同时，还不污染其他业务；
- 服务本身的独立部署能力使得容错和容量弹性最大化；
- 细粒度服务发布回滚和故障响应能够有效隔离，出了问题可以迅速降级或回滚。
一个架构师，如果你能尽早看懂看透你公司的用户心智，那么你就可以在技术上提前布局，从用户思维出发，扩大你的技术搜索空间，最终为公司创造更大的价值。
就像我们今天讲的，拼多多的心智也反向选择了供应链、供应商和用户人群，最终也选择了能够最大化这种心智的一群技术人。
所谓一入江湖，身不由已。你在暗黑生意中练就的生存技能，或许在光明心智下就不具备竞争力了。你进了黑道，如果再洗白，这个过程同样也是要付出巨大的成本。想换个行业，不是金盆洗手那么简单的。
三、架构活动在有限的资源下最大化商业价值
那么作为一个技术人员，本来是写代码做架构设计的，那你是怎么为公司创造商业价值的呢?从创造商业价值视角来看，你的代码和设计有三个作用:
- 实现一个商业模式
- 提升一个商业模式的效率;
- 加速一个商业模式的收敛速度。
也就是说，你作为一个程序员，主要通过上面这三个路径为公司赚钱
举个例子来说，你写代码实现一个电商平台的一部分功能，最终电商平台可以获取交易收入。或者是你实现一个算法，提升了买家转换率，从而提升了电商平台这个商业模式的效率。你也可以通过 A/B 实验的平台、数据仿真的功能等等，加速一个公司的商业模式收敛速度。这些都是为公司增加收入的办法，所以公司多赚的这部分钱就可以归因到你，也就是你为公司创造了商业价值。
或许你是一家企业里做软件基础设施的，比如说写云平台、自动化测试平台、财务系统和数据平台。那么当你通过企业内部用户来间接创造商业价值，通过提升用户的日常工作效率、产品质量、运营效率、决策质量和商业洞察的质量，这个时候，你同样也为企业创造了商业价值。
- 理解你所在的企业或团队的商业模式;
- 理解你在自己所处环境中创造的商业价值
- 保障架构活动的长期商业价值;
- 在架构规划中寻找扩大收入的机会;
- 在架构规划中寻找减少成本的机会。
有句话叫做“良禽择木而栖”，就是说你要选择能够最大化自身成长的工作环境。
如果你活在一个靠公司拨款而生存的部门，那么你学习到的能力是有限的，因为你们部门从上到下都不是在求生，也不是为客户创造价值，所以你也学不到真正的生存技能。
或许短期内，你作为一个一线技术人员可以不必担忧。但是你越资深，待的时间越长，你对公司的依赖性就越大，那么你的风险也会越大。因为公司遇到困难必然会收缩资金，公司真的到了生死存亡的时刻，就只能依靠自力更生的部门了。想想看，这种靠拨款才能生存的部门，还会有保留价值吗？
对于我们软件行业的从业者来说，价值创造永远是个衰减的过程，因为我们的经验会在信息扩散中迅速贬值。如果你不度量自己的增量价值，那就无法确保自己处在价值创造的前沿。你也不知道应该朝什么方向努力，才能最大化你未来的增量价值，更不能在一个相对未知的环境下扩大你的增值空间。
如何践行生存法则的？
第一，你作为一个架构师，在架构设计中要追求商业价值。
第二，想要创造商业价值，就必须不断度量你创造的增量价值，这样才能确保自己处在价
值创造的前沿。并且能够在一个相对未知的环境下，不断寻找自己的增值空间。
第三，作为一个架构师，要最小化整个架构活动的成本。你要做的是：
- 确保最终方案的可行性；
- 寻找最优的实施路径，确保最终能够完成实施；
- 试图最大化最终解决方案的结构性，以最小成本放大你的产出。
第四，做架构和做业务一样，都不能靠饱和攻击取胜，而要靠对阶段性精确目标的最大化
投入来取得进步。
第五，不断寻找通过技术手段扩大收入的机会。
第六，不断寻找通过技术手段缩减成本。
一个业务在高速增长的过程中，目标用户群体和用户心智，以及商业模式、供应链和运营手段，都在不断迭代。那么我们在快速奔跑的时候，最高优先级就是保障增长。哪怕增速慢下来，我们的优先级也依然是探索加速模式，重回高增长。而当一个业务到了成熟甚至是衰老期的时候，那就需要通过节省成本来扩大利润了。
四、架构师要考虑依赖的商业模块和技术生命周期
如何克服弱点，来提升追逐新技术周期的能力和勇气。其中我特别想强调的是，当你把自己的思考尺度从三五个月扩大到五年或十年，那么这件事情的价值必然会很大。这个放大思考尺度的动作，会让你用不一样的视角来看待技术。
所有的技术都像人类的生命一样，也有终结的一天。这是个自然规律
- 萌芽期(Technology Trigger):指的是技术被公开，媒体热度陡然上升，还没有成型1.的产品和商业应用场景。
- 至捧期(Peak of Inflated Expectations):指的是有了一些成功案例，当然也有失败案例，技术被吹捧到了极致。
- 低谷期(Trough of Disillusionment):这个时候，热度回归到理性，失败案例被放3.大。如果产品不能让早期受众满意，那么技术就会在这个阶段消亡。
- 灵感期(Slope of Enlightment):产品逐渐找准在行业的价值定位，二代三代产品出现，产品逐渐出现理智的商业用户和成功案例。
- 产出期(Plateau of Productivity):在这个阶段产品被主流市场认可和采用。
作为一个架构师，知天道不够，还是要顺天道，也就是说我们的架构要符合技术的自然周期。反之，为一个落后的架构注入新生就是不符合天道了。而想要抗拒这种行为，我们就要从用户思维出发。为了更好的用户体验，要舍得放弃任何曾经伟大过的技术。
- 怎么从硬件技术发展看软件架构的未来
在硬件生产一侧，规模效应和出货量的关系很大。其实这个关系非常普遍，几乎适用于各行各业。软硬件都具备规模效应，最终出货量最大的玩家会以更低的价格和更好的质量赢得市场，而硬件的发展往往会左右软件架构的走向。最终软件架构必须要利用好规模效应。
- 从“天神打架”看技术趋势
不过在技术层面，天神打架决定了未来的技术趋势。如果有机会看到这种场面，势必要睁大眼睛看清楚，这样才能在一众凡人中脱颖而出。
天神打架的玩法其实也逃不出竞争的普遍规律，不外乎我们老祖宗讲的合纵连横。
- 看清楚技术发展周期之后
当你发现了一个有优势的商业模式，就要立即去关注、思考和尝试做相关的技术创新。
顺便说一句，由于这些商业模式本身具有内在价值，所以它们的进化在其他行业也会被复制。最好的例子就是平台型商业模式和前置仓模式，几乎扩散到了其他各行各业。这方面的书籍很多，我就不做介绍了。
五、架构师为什么要关注技术体系的外部适应性
架构师能注入外部适应性
我特别要强调“外部”这个词。它表示适应性不是面向企业内部的，而是企业在外部环境发生变化时、在与其他企业竞争时所具备的适应能力。这是一个攘外而非安内的能力。
不同职能之间视角的差异性
业务同学通过商业和投资手段，来迅速捕捉外部的商业机会，从而为客户创造价值，为企业获取竞争优势。比如大公司通过兼并小公司进入一个新兴市场。
运营同学通过新场景迭代效率，来提升企业的市场竞争力和市场占有率。比如阿里的大促运营，就是通过一系列营销手段来提升获客效率和销售额的，从而扩大了市场渗透率。
产品经理通过不断打磨产品来提升用户体验，从而达到提升企业竞争力和市场占有率的目标。比如抖音创作者和用户端的产品优化。
技术同学通过打磨技术体系来支持产品和运营，从而达到提升企业外部竞争力的目标比如各个互联网公司都在打磨个性化算法、运营后台、数字化运营体系。
架构师是技术职能的一种，所以也是通过打磨技术体系来为企业注入外部适应性的。当然，架构师这个职能有自己的特殊性。首先，架构师与研发经理不同。后者具有人员管理的职责，因而可以通过人才招聘、培养和组织架构的调整来创造价值。
然后，架构师也不同于研发人员。研发人员可以通过优化数据模型、算法迭代、代码重构和模块升级来为企业直接注入外部适应性。而架构师仅仅可以通过组织架构活动与优化架构方案设计，来为企业注入外部适应性。
可以看到，我特别区分了几种职能所处视角的差异。为什么这么做呢？我发现，很多架构师把帮助他人创造价值与自身创造价值这两件事混为一谈，这样做，你就很难提升自己独立创造价值的能力。
业务、产品和架构师所处的技术视角，分别代表研发活动的三个不同层次。
第一个层次，研发活动由业务驱动，直接在业务人员的指挥下响应外部机会。我们把这一组研发人员称为业务线研发。在一些公司里，这些人一般直接向业务部门汇报。比较常见的是增长的产品和技术人员同时汇报给增长业务部门，以迅速响应新的业务机会。
第二个层次，研发活动由产品规划驱动。产品把业务活动抽象为一组产品，沉淀出产品矩阵，并通过产品运营不断打磨用户心智。在这个过程中，相应的技术人员会不断提升自己对产品的理解，并通过技术手段放大产品提供给用户的增值。
比较常见的产品有营销产品、供应链产品、物流产品等。除了产品特性本身外，一些纯技术手段，比如营销的资金池优化、反作弊、供应链优化、物流调拨等等，也会为产品带来新的增值手段。
第三个层次，研发活动就是由架构师主导的架构活动。架构师和研发同学对业务、产品做了一系列的抽象，最终形成由技术驱动的技术产品。比如工作流引擎、风控引擎、策略引擎、算法的特性引擎和标签引擎，都属于这一类产品。
影响技术体系外部适应性的因素有哪些
先从职能角度来分析。技术之外的同学，比如业务和产品同学，几乎不关注技术体系的外部适应性。一来他们不擅长，二来这也不是他们工作的优先级。遗憾的是，业务线的技术同学，以及与产品密切配合的技术同学，往往也很少关注技术体系的外部适应性。这里面的原因比较复杂，主要有三个。
- 第一，业务交付时间的压力。技术同学经常受到来自业务和产品同学交付时间的压力，这样一来，技术质量都很难保障，更不用说技术的外部适应性了。
- 第二，技术岗的供给压力。最近几年技术岗的供给比较缺乏，很多技术同学频繁跳槽，在一家企业的工作时间较短，因而他们在客观上就不太关注自己的技术口碑。
- 第三，考核的压力。不少企业把技术岗的考核内容、考核周期都与业务线牢牢绑定。而需要长期打磨的技术能力，既不能被关注和度量，也没有资源被孵化。结果就是短期效应非常明显，自然，技术同学就很少关注技术的长期适应性了。
了团队内部的压力外，企业也面临着不少压力。首先，时间对于所有的职能而言都是稀缺资源，大多数互联网企业都采用了小步快跑的迭代方式，很少有企业是先把问题研究清楚才入场的。大家都是边打边学。不论是业务岗、产品岗，还是技术岗，都是摸着石头过河，这就不可避免地导致所有职能都被自己的认知局限所羁绊。
比如你经常听到技术同学说“产品同学不靠谱，一天到晚改需求”。产品呢，则每天抱怨业务同学从早到晚变方向，朝令夕改。
事实上，这种行为在越是高速增长、竞争激烈的行业越是常见。等你完全看清楚一个行业，新的商业机会早就不在了。
在大多数风险投资充足的地区，尤其是中国和美国，大多数企业其实并不具备对外部适应性做长期规划的条件。因为一旦某个外部环境的变化被市场感知到，这种变化如果不能被已有玩家高速响应的话，那么资本市场，尤其是风险投资，必然会迅速入场。
就像在国内，很少有明显的机会能够在半年内都没被资本深入挖掘的。往往是机会一旦出现，资本会在一两个月内迅速集结力量做出响应。
六、如何鉴别文化环境是否有利于架构师的生存
我认为这就是一个架构师的做事方式：你从上节课里提到的技术洞察里产生一个商业假设，也就是你的期望你的技术能带来的商业价值。 之后你通过架构设计最大化你创造的价值。如果项目上线后你成功了， 那你预期的商业价值就实现了。 反之你发现问题，重新修正你的假设和设计。
我认为这和科学探索一样，最终能够持续逼近商业规律的真理的人，必然对真理有一种发自内心的执着。这种求真的性格和工作方式，有利于帮助整个架构活动产出更逼近真理的架构方案。
如何识别企业的真实文化环境
一个企业真实的文化，与他宣扬的不一定完全一致。举个比较极端的例子。美国历史上最大的财务造假和审计丑闻，就出自世界最大的能源公司安然公司和原国际“五大”会计师事务所安达信。财务造假不仅导致两家公司直接破产倒闭，更是在全社会引起了轩然大波，以至于美国国会迅速通过了《萨班斯法案》，来确保企业财务数据的真实性和审计的有效性。你可能没有料到，这个充满欺诈的公司，他们宣扬的价值观竟然是：“Respect、Integrity、Communication and Excellence（尊重、正直、沟通和卓越）”。显而易见，公司选择造假的真实行为，与其奉行的价值观完全背道而驰。
那么怎么观其行呢？我觉得比较容易的办法，就是在公司内部观察。具体而言，有这么三种方式，可以帮助你鉴定企业是否真正做到了“知行合一”:
第一，看行为方式的对称性。所谓对称，就是指企业用来约束员工行为方式的规则，是否适用于所有员工。换句话说，是否存在特权阶层可以随意解释、更改和超越行为约束的规则呢？如果存在，企业的规则就不具备对称性。 也就是说企业不是靠法制的。那么员工就不会把企业宣扬的法，也就是文化，当回事儿。顺便说一句，前面提到的排外的文化本身就是不对称的。 而包容的文化，有利于在有不同观点和背景的人群之间建立起更高质量的信任，可以是对称的。
第二，看最终的反馈机制。比如一个企业鼓励员工不唯上，要有勇气反对领导的错误决策。但真正有勇气站出来反对的人，他们的命运如何呢？是被晋升还是被打压了？反之，那些唯上的人呢？他们是被晋升还是被打压了？你只有从反馈机制看企业要什么、不要什么，才能获得更真实的信息。如果反馈机制与企业宣扬的文化背道而驰，就说明是反馈机制决定了企业文化。
第三，看企业文化的连续性。企业可以快速发展变化，但企业文化却要保障其内在连续性。因为文化约束力需要长时间的养成。如果文化不断被调整，证明这个企业的文化在生成过程中的决策机制，大概率是存在问题的。此外，文化的形成时间越短，就越难以被多数人认同。没有认同，那么文化对行为的约束就会失去效力。换言之，频繁变化的文化，不太会在企业内部产生足够的约束力。而真正产生约束力的，一般会是其他利益分配机制
架构师如何在小范围内打造一个友善的文化环境
答案很简单，那就是通过你的行为（Leadership by Example）来影响和打造。你的行为方式往往会影响身边人，甚至是参与架构活动的人。
你可能会问我，为什么很多人都在做自私决策的环境下要让我有良知？ 我认为你作为架构师这么做是有必要的。 你的角色有一个极大的特殊性：你是在代替许多人甚至是整个企业做决策。别人把他的领域的决策权交给了你，所以你其实预支了他给你的信任，从而获得了做决策的机会。这份信任和机会，是靠你的良知换取的。
如果你的决策是自私的，仅仅从个人层面考虑，那就破坏了向他人预支的信任，也毁坏了架构师这个角色的可以正常工作的前提。如果没有人相信你作为一个架构师的决策是对他有利的，那么你的决策将一文不值。所以，作为一个架构师，有良知是个必要条件，而不是一个选择。良知，有利于你与架构活动参与者建立信任，最终推动整个架构活动走向成功。
这里我特别强调一下，架构师有良知是个必要条件，却不是对其他架构活动参与者的要求，也不是你日常生活的要求。从上帝视角来看，自私是人的本性。只是我们架构师在行使决策权时，其实已经进入了一个事先拟定好的条约里。在这个条约之下，我们的决策必须是由良知驱动的，从整体利益出发，而不应该有任何自私的一面。
那么什么是勇气呢？ 我认为在一个架构活动中，有勇气是你在一个架构活动中敢于面对冲
突，敢于对不合理的决策表达反对意见。
我们已经提到了，由于认知的局限、不同职能在工作上的优先级、人性等等，在一个架构活动中，架构师和很多研发人员都会面临冲突。在冲突中，多数人往往会保持沉默，尤其是一个大公司里。
同样， 我认为勇气也是架构师这个职能的必须选择。架构师是一个组织里全局视角和长期视角的唯一代言人，沉默就可能造成严重后果，比如架构方案被完全扭曲。你的勇气可以帮助所有架构活动参与者认识到企业的全局利益和长期规划，最终帮助大家找到最利于整个企业长期生存的架构方案。
但是你作为一个架构师，如果参加架构活动的各方势力比你大，层级比你高，甚至决定了你的薪酬奖金和晋升。那么有勇气去表达你的看法，的确是一个非常不容易的事情。 我自己的职业生涯其实也因为有这样的勇气而最终可能损失了收入。但是我始终坚信这是一个架构师的职责所在。 一个人的判断力大幅提升就是要靠你在巨大压力之下做出不同与其他人的但是是最终正确的决定。这个判断力提升过程我认为只能靠你的勇气来换取。
生存法则的逻辑是什么
所谓信奉原则，就是采用相信过程正义的工作方式，用一组原则来指导行为和决策，而不是随心所欲地工作。过程正义，这个词源自法律领域。如果放在架构活动的情境中，就表示你作出决策的每一步都是公平（Fair）、正义（Justified）和可解释的（Explainable），而不是靠一两个人的强势来达成的。
我尽自己所能总结了适用于当下互联网环境的六个架构法则。我认为这些是一个架构师应该聚焦的思考和行动的关键点。不过也有人问我，法则为什么是六条呢？六条就足够用了吗？
答案是：肯定不够。准确来说，这些法则只满足了以下三个条件：
也就是说，我把我过去二十多年的个人观察总结成了六个法则，可以帮助我解除一些失败的根因。也意味着，除了这些根因之外，肯定还有其他根因存在。所以这六条法则具有一定的普适性，可以帮你躲开大多数的失败，但不一定能完全帮助你成功。因为这些法则是基于我过去多年的观察和学习，主要是 PC、互联网和移动互联网环境下的观察。要知道，技术和社会环境一直在变，所以这些法则肯定不是一成不变的。也就是说，它们“非常道”，你应该能找到更好的一组法则。那么为什么就是六条呢？我二十年就总结了六条法则吗？肯定不是的。我总结了不止六条，但是使用这些法则也是有成本的。我认为你不应该关注太多的法则。
1.它们适用于我的个人经历，以及我能近距离观察到的场景中（以百计）；
2.这些法则对我而言，置信度（Confidence Level）足够高（～90%）。
3.这些法则能把我的注意引向那些会导致架构失败的关键点上。
虽说这几个法则都是为了帮助你避免失败的，但是就像我们在课程中不断提起的：有时候环境没有那么尽如人意，你可能要被迫违反一个或多个法则，这个时候你就只能两害相较取其轻了。
