.. Kenneth Lee 版权所有 2019-2020
:Authors: Kenneth Lee :Version: 1.0
架构设计的粗与细问题
最近做一个架构设计的同行评审，我看完设计以后给了这样一个评价：“你们这个根本不是 架构设计”。
对方很纳闷：我文档里，你说的4+1视图都有了，怎么就不是架构设计了？
我说，我就问一个最简单的问题，你们这个产品是要支持全球市场呢？还是大中华地区呢 ？还是深圳某个客户呢？这些人的组网是一样的吗？他们的网络节点上跑的什么硬件？什 么操作系统，你的软件能运行在这些硬件和操作系统中吗？
对方疑惑：这不是细节问题么？我们这层设计不需要考虑这个问题啊。
那我问了：那你们设计了什么？
你连所有开发需要的依托的下层抽象都没有定义出来，你有可能有设计吗？
很多人觉得做这种设计太难了：承认自己对全球客户的情况不了解这件事，说出来好像就 不用做了，不说出来又说我“没有架构设计”。去调查清楚全球客户的情况，有精力支撑这 个工作量啥事都不用干了。而且，这些用户有规律吗？能抽象吗？
所以，承认吧，架构设计是个专业技能，不是你写几年程序就是“专家”的。你以为也会跟 着说两个专业术语，就懂架构设计？
是的，抽象全球用户的规律是很难的，但架构师仍有办法处理这种复杂度。他会假设，而 且他有办法保证他的假设成立的可能性很高，这才是功力。
比如这个全球网络抽象，在没有进一步调查前。我可以这样抽象：所有的这些网络，都是 计算机组成的，这些计算机会被联网，其中的数据流和管理流会被分布到两个网络平面上 ，可以实现互相独立隔离。每个节点上会有操作系统，这种操作系统的版本可能很多，但 基本上都会是Windows和Linux。而且作为靠谱的商业运营商，他们的主要节点的操作系统 的版本一定会更新到最新的版本，所以和最新Windows和Linux的版本不会超过5年。我还可 以假设我可以在他的网络中增加我加入的计算集群，里面的硬件、OS版本都可以被我控制… …
你看，这样我们就建立了一个设计的基础概念空间了。我们可以为这些操作系统写Daemon ，可以通过JS提供服务，可以通过管理平台网络进行通讯……我们还有很多假设，不一定是 真的，但有了这个基础，我们下一步可以开始针对性地进行调研了，我们可以通过走访大 量的一线技术支持去找具体情况了，这个过程会补充我们的逻辑。做下一步设计的团队可 以基于这些逻辑开始决定有多少Daemon，多少Client，支持多少种系统。匹配多少第三方 软件了。
这些才是架构设计要进行的设计，架构设计的依赖确实很粗。但架构设计的工作本身可是 很细的。架构设计是要找出最影响成败和工作量的逻辑出来优先设计啊。那么有多少种具 体情形，做多少个OS的支持，适配这些OS的哪些版本，这些严重影响后续工作量的事情， 你能认为是“细节”吗？
简单说吧，大部分不考虑自己有多少个版本的架构设计，基本上都是外行。工作量全在这 里呢。你架构设计的人不定义这个，工程师肯定只保证实验室那个组合可以跑起来啊。这 样交付出来的东西，你卖啥？怎么卖？你甚至保证你有一套源代码的交付，卖给每个具体 的用户的时候都重新移植和落地一个版本，那也是办法（这个后期维护的成本极高，想想 你在主版本上发现一个Bug会怎么样。这些直接左右你怎么组织你的维护过程，甚至可能为 了维护要开发一个维护系统），那也是你架构设计要考虑的。因为这会改变交付模式和你 如何对客户承诺交付时间啊。难道你避开这个问题不谈了，这个问题后面就不会出来的？
被评审的团队听了我这个解释，给我这样一个解释：明白你的意思了。不过我们这个文档 不是给实施团队看的，而是给领导看的，领导只关系What，不关心How。所以我们重点是给 他说清楚这件事情有意义。
我说我明白了，那这个问题不要找我评审，你们应该找客户关系管理专家来评审，要把重 点放在领导关系维护，领导个人爱好调查，“FBI看人的32种方法”这种问题上。
但我也奇怪：假设你们成功搞定领导了，不用担心后面怎么实施的？
当然，我也就是装奇怪而已。我太清楚背后的逻辑了：只要拿到钱，领导就变成债主的。 今时今日这个时世，借钱的才是大爷呢。第一笔投资成为沉没成本后，领导就只能追加投 资了，有钱就有更多的工程师，不行也能搞到它行，物理上不行，声誉上都可以行。毕竟 ，项目成败的第一控制要素是钱呐。——真聪明。
但做架构设计的，在这种问题上聪明，在架构上（或者在做成这件事上），就不可能聪明 了。
总结起来，架构设计还是设计。架构设计的粗，体现在他的抽象范围很大（也很难）上， 架构设计的细，在于他的抽象有多精准。所以架构设计没有样子看，因为准不准这个问题 ，你不大规模卖，都是很难判断的。希望看架构样子，希望控制架构设计怎么做，都只是 被人骗的命。