.. Kenneth Lee 版权所有 2018-2020
:Authors: Kenneth Lee :Version: 1.0
从逻辑链问题讨论怎么做高层设计
有了这个逻辑：关于设计方案中的逻辑链问题。我们可以讨论一下更高级的“设计文档的写 作”问题了。
我见过太多的工程师不愿意写文档了，他们最喜欢说的是“李总，我来给你解释一下……”， 而不是“我已经在某某文档中对这个问题进行了‘定义’了，请基于那个来挑我的破绽”。谦 卑不表示你接受意见。
为什么不愿意写文档？是因为“懒”吗？——看你怎么理解这个“懒”了。给人一遍一遍“解释” 的时候他们也不懒。他们是“懒”得建“逻辑链”，建逻辑链要费巨大的脑力，但这玩意儿不 能“表现”出来。你写10页的文档，不考虑逻辑链，30分钟写完，考虑逻辑链，可能至少3个 小时，考虑清楚逻辑链，能让事情成，但不利于表“功”。那最好是让别人负责逻辑链，我 负责出劳力，事情成了——“明显是我的劳动成果嘛！看见那代码了吗？看见那文档了吗？几 千K，几百页呢！”（很多人觉得自己不是这样想，但其实是这样做的）
这是小聪明，我个人建议想要有所发展的工程师避开。一方面，你觉得这样你能占便宜， 这在这种文化的团队中，这个团队成功的机会很低，你在团队中爬高，团队在往下掉，你 高不起来。另一方面，这样的结果就是——你工作十几年，你在设计能力还是个渣渣，你跑 都跑不掉，只要行业一变化，你是首先被割草的。除非你的发展方向一开始就不是工程师 ，而是别的什么，那个我管不了。
回到设计文档这个问题。在前面索引的文档中我提到，逻辑链是分层的，有些逻辑事实如 果我们已经有共识了，在本层中，我们是不会细化的。所谓高层设计，是建立一个高层的 逻辑链，证明“目标”是可以成立的，从而保证我们后续做的“细化”工作，是最终可以达成 目标的。
这就是为什么我们不能用代码代替文档。两者解决同一个问题，但两者的逻辑链是不同的 。
这类似这样：
.. figure:: _static/逻辑链4.jpg
如果“A饭店近->要在A饭店吃饭”这个逻辑可以成为我们的共识（或者说成为你的设计信心 ），而且它的内部链条可以内部自洽，我们的设计中就不会细化这一层设计，而把它留给 下一层。这样我们才会聚焦会“建模”这个工作上，尽快确定大方向，然后就可以比较放心 地做下一层建模。否则如果我们把精力都已经消耗到底层建模上了，高层建模的意义就已 经失掉了。所以，在高层设计的时候进入细节建模，不是个锦上添花的问题，而是个错误 问题。有些工程师死要面子，非要把代码写好了再来交高层设计，该浪费的都已经被你浪 费了，现在再评估你的高层设计有什么意义？
由于工作原因，我常常需要和某个芯片架构提供商（就是他们定义一个总设计，每家SoC完 成自己的具体实现，他们负责通用部分，SoC公司解决具体问题。他们卖的是这个总设计， 参考实现和高层抽象代码）的系统使能团队打交道。我发现他们有一个逻辑：“我们的代码 只建立在被写成了Spec的构架定义了的逻辑上面，如果你需要我们改，请先说服我们的构 架团队，让他们把这个特性加到构架定义中，否则我们是不会基于你的实现来改的”。
举个例子，比如针对中断控制器，他们的架构定义团队定义：“下级中断控制器的中断信号 会在上级中断控制器中根据中断分配表分CPU进行排队，以中断信号和EOI为周期串行激活 CPU核的中断流程”，而在我们的某个设计中，高优先级的中断会自动调度给CPU0，并按优 先级排序（请注意，这不是真实例子）。这样做性能也被我们验证过了，性能是比较高的 。但你和这个架构提供商的软件使能团队讨论，他们是不会在他的软件流程中处理这种情 况的，他们的说法会是：“你对优先级的这个优化，我们‘看不见’”。
你看，“高层设计”非常重视这个“看不见”，你要抽象，就要有很多“看不见”。你“解释”能 解释得通是不够的，我们需要你重新定义你在高层这个层次，什么“看得见”，什么“看不见 ”。高层设计和底层设计认知的“逻辑事实”是不同的。我们需要做设计文档，就是要你在这 个层次上重新定义一套你认知的“逻辑事实”，并让用这个逻辑事实构成的逻辑链仍然成立 。
高层设计看得见的东西越多，细节设计的余地就越小，应对风险和演进的能力就越弱。我 们说“机数算尽”，也是一个意思，余地已经被你用光了，还怎么变化？但高层看见的东西 虽然少，但它的逻辑链仍然是必须的条件啊。不能说减少点东西，你就可以没有逻辑链啊 。
所以，比如你做一块单板的使能，你的代码可以仅仅在实验室里面那块验证板上正常运行 。而我要设计文档，你首先必须给我定义：你所使能的单板是什么单板（什么样的单板在 你的设计范围内）。它仅仅是你在实验室中的验证板，还是还在工厂中代号是XXX的整批单 板，它针对的是这个单板在工厂中没有烧efuse的状态，还是已经出厂的状态（如果这个事 实影响你的逻辑链的话，你也可以认为efuse的状态你“看不见”，只要你的逻辑链不断裂） 。
一旦你这样想这个问题，你就发现你的问题一点都不简单。你在一台服务器上装上一个 Redhat Linux，然后修改它的内核，让它能支持你的单板，这很容易。但你的用户将使用 这个版本运行在你几年内卖出的任何一块单板上（你不会要求你的用户每买你一块单板就 装一个特定版本的Linux吧？），这时你的逻辑链就断裂了。然后你的版本可能要用几年， 这几年你不升级吗？升级的时候又是如何保证仍然可以保持这个特性的？
所以，一个好的高层设计，什么叫“单板”，什么叫“软件”，什么叫“版本”，都是需要精心 设计和定义的问题，这常常不是个个人的工作，而是一个调查，沟通，达成共识的工作。 这是需要工作量的，你省这种工作量，我就认为你的设计没有做完。你别以为这是工作理 念不同，你这是怠工！你不要认为只要在实验室能跑，大量部署只是小问题。工程师和学 生的差别就在这里。实验室和工程落地，远得很呐。
很多人还有个误区，他们会解释说，我不定义什么是单板，因为这个事情是硬件部门的事 情，他们不说，所以我们没法说。你看，这又是“我没错”，好吧，你没错，但你的逻辑链 还断着呢，你没错，但你的设计没有做完，怎么你就敢安心编码去了？
这真是“道理说得头头是道，设计做得糊里糊涂”。
这里面其实也是有技巧的：设计总是有外部依赖的，你不可能控制对外依赖的方方面面， 所以大部分的设计文档的模板中都是有“Dependence & Assumption”这个章节的，为什么要 有这个章节？你可以假设啊，假设也可以成为“逻辑事实”中的一环，如果有人不同意这个 假设，至少我们可以就这个假设来讨论啊。
所以，你自己不肯抽象，你不要给我推托说“他们不肯说”，所有的“不肯说”都是你自己不 肯说，你要为你的逻辑链自洽负责，逻辑链是你的精神世界，别人可以挑剔你的逻辑事实 ，但没有人可以拒绝你把逻辑链建起来。
正确挑选最优的逻辑事实，基于逻辑事实建出无懈可击的逻辑链，这是写一个设计文档的 基础，没有这个基础，我们什么都讨论不了。