.. Kenneth Lee 版权所有 2016-2020
:Authors: Kenneth Lee :Version: 1.0
架构师具体设计什么
前面说了，架构师是做设计的，而且做的是“他自己眼中的设计”，那么，他眼中的设计到 底是应该是什么？
提到这个问题，想想已经写好的这些文本，我突然想起来，其实我写的这些内容，基本上 都不是给学生看的，学生看了也很难有共鸣，我这些文本，是给有架构设计经验的读者来 争鸣的。不过我的初衷确实是让还在学习的学生一个窗口理解一下实际工作中到底软件生 产在考虑什么问题。所以，我想我这里要修正一下我的写作思路的介绍：我的写作，是以 有设计经验的设计人员作为读者的，但文章本身的目标读者仍包括软件相关专业的学生， 我不指望您认同或者理解描述的主要问题，但希望这个描述的相关内容能给您一个软件生 产是怎么样的印象，从而帮助您更好理解你现在正在学习的知识。同时，这里说的“学生” ，包括刚入行的程序员。程序员不见得要成为架构师，但程序员不能不理解架构师的工作 。就好像乐队的乐手不能不理解乐队指挥的工作一样。
另外，有人私信我，说我的内容写得比较乱，不知道我在说什么。这个问题我这样看，首 先，我认为我写每个主题的时候，逻辑性还是很强的，但我不是像写一个教程一样，严格 地从头开始给你介绍架构设计第一步干什么，第二步干什么，我是认为你已经有了一套基 本的架构设计（或者简单说设计）方法，然后我提起一个主题，告诉你，在这些方法中， 你要知道你可能有什么误区，如何避免这个误区。比如在《什么是软件架构》中，我重点 就是强调出，架构设计是没有固定方法的，也没有结束点的，从“学习”的角度，这个听起 来好像和学习怎么做软件架构设计没有关系，但实际操作中，这是一个非常重要的判断， 因为我们很多设计师因为这个问题而做了很多多余设计，写了很多无效文档，或者错过了 关键的设计没有做，把设计的压力推到编码阶段。所以，我其实是认为我说的都是架构设 计中的关键问题的。你要把这个观点放到你的设计实践中，才有可能理解这个主题的重要 性。
第二，对我来说，非常重要的判断，在你的场景中就不一定，我这里说的都是原理，如果 你觉得不能理解，则你需要直接来讨论，把你的场景说出来，我就有可能针对性来讨论这 个问题，否则我也无法解答你的疑问。
言归正传，我们回来讨论架构师到底重点关注什么问题。有人认为，架构师重点应该关注“ 关键设计”，对关键设计应该亲自编码。这是一个比较靠谱的实践经验，但这不是核心的判 断模型，在很多场景下用这个来判断也是会错的。
如果读者有实际的架构设计经验，你就会发现，无论你怎么努力写代码，你的代码只是很 少的部分，你想像一下，你手下有30人，前面设计阶段你可以进行一些设计工作，我假设 你编程能力很强，代码可以写到每天100行（我认为设计阶段的代码可以不做单元测试，也 认为设计文档一定程度上可以当作是代码，这个值，只是作为一个比喻），你的团队的能 力比你弱，每天可以写50行代码。后面我会谈到编码阶段的工艺问题，但我们这里可以先 放一个结论：就是无论你的能力多强，你每天的代码量，都不会比你的团队成员高太多的 。
好了，你可以想像一下，一旦整个团队进入全速运转，你的团队每天会产生1500行代码， 一个月就有37.5K的新代码产生，按六个月为一个项目周期，每个项目会在你面前凭空产生 225K的代码。
而你自己，抛开别人的代码不用你检查，你也不过写15K代码，不值一提。 如果你聚焦在 你的代码上，你的架构设计基本上就毁了。
但软件不是有代码量就可以工作的，代码量是工作量的限制，但如果设计方向错了，所有 的工作量都扔水里了。所以，你必须在你的设计阶段，就可以准备好一个水道，当洪水来 临的时候，你能控制这些水让你可以发电，或者用来浇灌农田，而不是把你淹没。水道的 挖掘，才是架构设计的核心。
从这个角度理解架构设计，我们也许就应该明白，架构设计，是架构师加予每个团队设计 人员的约束，基于这个约束，当每个成员开始展开他们的代码的时候，要有办法限制住这 些代码最终是为设计目标服务的。
所以，架构师的工作不是指导每个开发人员怎么工作。因为指导是无限度的，就如同我在 《什么是软件架构》中提到的，设计文档可以写到无限接近代码，但如果有时间把设计做 成代码的水平，你还做什么架构设计？
所以，架构师的工作是“限制”每个开发人员怎么工作。而且，作为架构师，你的一大素质 就是要“无为和不争”，你本来就是要用工程师的脑子来为你（也是为团队）完成你个人无 法完成的设计，你还天天跳出来说这个设计好帅，那个代码好关键，然后想自己来把这个 设计做了，你强，你的团队就弱，你要了团队的名，你的团队就没有名。这就叫“夫礼者忠 信之薄而乱之首”，求礼的领导者失去的就是整个团队的成功。这样的领导者是最差的领导 者。这些听起来牛逼哄哄的设计师，都只是样子货。高明的架构师只会让整个团队成功， 让成员成名，而自己隐身其中，无人可见。
这样，我们就得到所谓“决策派”的结论，架构设计，是一组设计决策，架构师通过这组决 策约束所有的开发活动，从而最终得到符合要求的软件。
但是，描述约束，是描述“道”，而“道”要通过“名”来描述，我们需要名称空间来描述约束 。名称空间是什么？呵呵，就是“组成派”的观点了：架构设计，是对组成系统的组件，以 及这些组件之间关系的描述。
你要说明“虚拟机间必须通过OVS进行网络交换”这个设计约束。你就要说明，什么是虚拟机 ，什么是物理机，什么是OVS，什么是物理交换机。然后你就会有这样的定义：
.. figure:: _static/构架例子.png
这本质就是定义名称空间。所以，所谓组成派，决策派，都是同一个东西。关键在于，你 要明白，架构的核心不是这些图，不是这些决策。而是架构师如何去分配自己的工作精力 ，决定要约束什么东西。剩下的事情，就是约束的技巧，也就是说，构架师工作要考虑的 问题是：
如何正确定义约束，保证给每个设计者最大的设计自由度，但不会偏离你的设计目标。 这是设计方法问题
如何把你的约束传递给你的工程师。这是设计编档问题。
如何控制工程师不会偏离你的设计。这是设计管理问题。
如何在新的信息不断加入的时候，调整你的设计以不断聚焦你的设计投资。这是设计变 更管理问题。
我后面写的技巧，基本上就是在这四个方面的具体工作技巧了。