php架构师 知乎,把什么放入架构设计

昨天讨论一个架构设计的时候，为一个主题争论了有一个多小时，最后对方有没有真的接受我的观点我也不能确定。这个问题非常有趣，我在这里整理一下思路：

这个问题是：到底什么要放在架构设计中，什么不用。

我之前的博文中也讨论过这个问题，在那些地方，我经常用“架构师眼中的设计就是架构设计”之类的嘴皮子来说这个问题。

但在这个实际的讨论中，大家都是设计师，那么“我觉得这个东西应该放到架构设计中”，“你觉得这个东西不应该放到架构设计中”，那么，我们听哪个架构师的？这里有什么原则吗？

对于这个问题，首先我们可以达成一个前置的共同认识，就是架构设计永远都不可能完全规定代码是怎么写的，因为真正可以完整说明代码是怎么写的方法是把代码写出来。否则必然是不严谨的，这个问题的详细讨论我在这里也讨论过一次了：有没有人能画出《三体》里太阳系被二维化的概念图？。

每个架构师有不同的方法来选定需要约束的特征，这些特征哪个更重要一点，见仁见智，它又不是百分百控制了后续发展的所有逻辑，你说谁的可能性会高一点，能证明这东西的成本大部分时候都比等这个事情直接发生的成本还高。所以，如果最终两个架构师有分歧，那就只能是谁官大谁说话，或者一起找上级或者技术委员会之类的来决策喽。

但丢开这些管理性的逻辑，就从理智上，或者像在这里说的《in nek：诚其意》的那样，就自己和自己比，自己要决定把一个东西放到架构设计中和不放到架构设计中，我们选择的依据是什么？这个问题我也没有严格的定义对这个作出判断。

比如我们昨天讨论的问题是：代码必须开源，这个约束，应该放到架构设计的约束中，还是不应该放在架构设计的约束中？

有一方持的观点是“必须放”，我持的观点是：你要放也可以放，但我觉得“没有必要放，放了也是多余的”。(当然，我们的重点不是为了讨论这个问题，而是用这个问题引出其他更多的约束是否需要放进来)

对方的论据是：代码需要开源，这是不是个要求？答案是“是”。既然是“是”，为什么不明确提出来？不提出来执行的人怎么知道？

我的论据是：代码用C写的时候，写完必须链接，这个是不是要求？答案也是“是”。既然是“是”，为什么你写“开源”这个约束，而不写“C写完以后必须链接”。

你不要跟我说这是天然的，因为我完全可以源代码交付。比如Nvidia的Linux显卡驱动就是用的时候再编译的。

什么才是我们必须引入的约束？为了讨论这个问题，我选择一个更容易有共识的例子：比如我们打算去一趟省城，我们如果要提前准备，我们会在我们的记事本上记上什么东西呢？我猜大部分时候在这个问题上我们会这样记录：

去省城的车几点发车，必须赶上几点的车才能保证到省车站还有公共汽车

到了省车站以后坐几路公交可以到目的地

目的地有什么特征，从公交站台怎么走过去

我们应该不会选择记录这些事情：

去省城需要坐长途汽车

长途汽车每天发3趟车

公共汽车上有座就坐着，没有座就站着

……

后者也都是事实，或者需要执行，但我们的记事本上不记这些东西。那么我们选择的依据是什么呢？

我觉得有两个：

这是一个动态的信息，比如选择坐几点出发的车，到细节执行的时候再考虑具体坐几点的车，就没有决策依据了。

这个信息在细节执行中有需要。我们记事本上的那个推演，计算几点出发才能保证到达后还有公交可以坐，但这个车要走多久，这个信息在执行的时候是不需要的，这个就不在我们的记事本中。

这样分析起来，我和另一方的分歧看来是这样的：

对方认为的架构设计的信息是一层层的，每层都应该是下一层的全集：

他也不见得排斥高层设计只是部分的约束，但他认为每层设备应该把本层增加的约束和之前的约束的无损转化全部交给下一层。

而我的观点是这没有必要，已经在原始约束中的东西，下层设计直接去拿就可以了：

这还真说不上谁对谁错，但在实际操作上，我觉得对于大型产品，团队复杂，合作众多的产品，前一种方式，我觉得是过于理想化了。作为学院派的描述可以，但用来做产品，可能成本高企，最终落实不下去。

所以，我会认为构架设计并非把需求作为一个全集收录进这个设计步骤，然后给一个全盘的约束给下一层设计，而是一个独立的设计逻辑，它引入一个高层的的需求，然后对这个高层抽象进行设计，从而对下层设计引入额外的保障逻辑。这也是4+1视图希望达成的目标。