架构每日一学 2：架构师六个生存法则之一：架构必须有且仅有一个目标（一）

本文首发于公众号：腐烂的橘子

在这里插入图片描述

为什么有的架构活动没有正确的目标？

在每个架构活动启动之前，必须有且仅有一个正确的目标，这是架构设计的起点[1]。何为正确？正确就是要与公司的战略目标相匹配。否则系统会变得复杂和无序。

架构活动为什么需要目标？

看看下面的情形你是否遇到过：

公司一口气干了很多项目，喊着口号，上班时长也变长，作为普通程序员，只能加班加点干，不知道这个项目最终能产生多少价值
有的同学很积极主动，会一些与公司主流技术栈不同的语言，还未全面评估就引入当前系统中，由于其他人不懂这个语言，所以大部分工作由他负责，等他离职了这个项目就被慢慢弃用了
项目初期，有人认为某个系统不应该“过度设计”，应该保持“极简”，随着业务不断发展，业务复杂度也极速变高，只能在原有简单的系统上不断堆叠，老的代码也不敢修改，最终整个系统臃肿不堪

注意第 3 点不是宣传“过度设计”，设计的复杂度要结合项目本身和业务来综合评估。以上 3 点都是缺乏统一的目标造成的结果，缺乏目标会导致“心力”的流失。“心力”是企业力极其有限及宝贵的资源，一旦架构尝试失败，心力耗尽的同学可能会选择离开，加速企业心力的流失，所以企业也是经不起“内耗”的。

除此之外，没有目标的架构活动会导致整个系统复杂度增加，这是一个“增熵”的过程，维护的成本，开发的成本都会增加，进而浪费企业的研发资源。

所以，制定一个目标，且与公司的战略目标匹配，这是架构活动中首先必须要遵守的法则。

为什么会目标缺失？

我们可以从技术和业务两个维度分别讲述。

技术：缺少全局视角

技术上缺少全局视角，主要有三个方面：

第一个方面，是开发者对于技术强烈的好奇心。由开发者发起的项目容易产生这个问题，如果开发者对技术的追求更多而对项目价值的思考少，就会产生这个问题。比如团队里的几位专家发起了一个平台的建设项目，这个平台引进了新技术模块，且架构方案也比较新，大家一起干完之后，使用方表示并不好用，于是慢慢就弃用了。这种“技术自嗨”只是让其他开发者觉得“这个系统很牛”，但对于使用方来讲，可能体验并不好，也并不是他们理想中需要的系统。

第二个方面就不太光彩了，是开发者个人利益。这个个人利益为了完成某个 OKR、KPI，或者自己不愿意动旧代码，就重新写一个新系统，但最终发现可能还需要用到老系统，所以两个系统同时运行，增加维护成本。开发者的个人喜好、技术能力、和同事的关系，都有可能决定是否引入一个新系统。

第三个方面的原因就是信息沟通不畅。比如公司有一个中间件的平台，已经承接了其他部门的很多业务，比较成熟了，但是自己部门由于没有做充分调研，大搞架构设计，费了九牛二虎之力搭建一个新的平台，重复造了很多轮子。还有一种可能就是前面谈到的，总觉得这个平台不适合我们的业务，有点过度设计了，认为我没有这么复杂的场景，于是也重新写一个新的 MVP 版本从 0 开始。

事实上往往你的场景简单，是因为你的业务还没做起来，等两到三年后业务够到业界水平了，你发现当初平台的那些模块一样也没落下，只能再用专业版本来代替。

业务：目标太多不明确

业务上导致架构活动没有正确的目标往往是目标太多且不明确。比如，业务方很多情况下不知道这个需求能产生多少价值，往往会制定多个策略，做 AB test，最后选择业务效果好的模式。多个策略就会产生多个需求，甚至有时这些需求在架构设计中完全是相反的。结果就是开发觉得开发了半天业务也没用到，耗费了心力；系统中增加了新的复杂度，导致整个系统无序。这时就需要做架构治理，让系统重新回到结构化的状态。

总结

在架构活动中，我们必须有且仅有一个符合公司战略目标的目标，这样能保证系统的结构化，不至于“烂尾”，系统的复杂度也会合理，也能避免开发者的“心力”的流失。在架构设计前我们可以经常这样问自己：这个架构规划为什么能给企业带来生存优势？它有什么价值？通过这样的反复提供，在我们面对众多项目时，根据给企业带来生存优势这个角度，我们也能判断出哪些项目是值得分配精力去做的，哪些是不重要的甚至应该被“砍掉”的。