读书笔记 | Design Rot - 2

书接上回。

读书笔记 | Design Rot -1

管理的事情不太懂就不多说了，还是接着聊Design。

设计边界

设计边界这个概念，应该是被广泛认知和接受的，毕竟大家都是从module designer开始的。一个设计模块是有边界的，简单来说，一个模块的输入和输出应该都是预先被定义好的。

不出意外的话，大家在做模块设计的时候，也应该都碰到过模块的Spec不得不进行改动的情况。改动在项目早期是难以避免的，在项目中期的时候出现也还好。如果在项目快收尾的时候，让你的模块增加个不大不小的feature，那一定是痛苦不堪的，加班加点不说，而且很多时候这个feature 都可能变成一个潜在的bug。

当然，一个设计可以是弹性十足的，扩展性很强，随便集成一个即便是八竿子打不着的feature 都很容易；也可能是逻辑耦合非常紧密的，在这种精简巧妙的设计风格下，别说增加feature 了，就是减少一个feature 都比登天还难。

在设计边界稳定的情况下，一个模块的设计质量是可以预期的。因为边界稳定，对于设计来说就有了一把可衡量的尺子。设计的输入、输出确定了，内部即使再复杂，毕竟也是一个有限的空间。假以时日，这个设计空间就会在设计者的大脑里构建出来，反复推敲，百般琢磨，日臻完善。

如果设计边界不稳定呢？举一个不太恰当的例子，本来是准备盖个平房，快盖好了，又想再加一层改成个楼房。

PM：客户需要的是楼房，不是平房。 RD：平房改楼房不简单啊，先来两个星期评估一下。 PM：不就是加一层嘛，把原先的平房copy-paste一份，摞起来不就成了吗？ RD：时间不多了，摞起来看看！没楼梯！怎么办？ PM：工程快收尾了！没时间在一层屋顶掏洞做楼梯了。 RD：干脆，二层窗户外面竖个梯子吧。打完收工。 （大风一来，梯子被刮跑了。困在二楼的PM于风中凌乱。）

稳定边界 - Architect

怎么才能稳定设计边界呢？首先必须要依靠清晰合理的芯片架构了，如果有芯片架构师的话。为什么说如果呢？

因为在大量的中小型芯片设计公司里，很少有专职的芯片架构职位，大部分都是芯片的Design Leader 兼任。

他不但要面对产品、市场部门的进度压力，同时还要对设计团队内部的任务分配和开发进度进行平衡和跟踪。这种类型的任务可以归类为粗粒度的事务型任务，它需要的是高瞻远瞩、八面玲珑、水磨拉锯。

具体到芯片设计的任务，无论是架构设计，还是模块分解，都可以归类为细粒度的逻辑型任务，它需要的是缜密严谨、耐心理性、灵光乍现。

作者无法期望在某次热火朝天的会议中就能讨论出一个复杂设计问题的最优解；同样无法想象，面对一千页的文档枯坐几天就可以做出整个设计团队的进度安排。

Architect和Leader这两个角色之间，应该有一个清晰的边界。

尊重边界 - 信息对称

在小型芯片的开发和维护中，往往有一两个STAR Engineer，从需求、架构、设计，到验证、流程、维护、客服。。。一肩承担。在某个阶段、某种程度上，这当然是合理的，高效且低廉。

随着芯片规模的增长，不可避免的要引入更多的人员，形成相应规模的设计团队。原先的STAR模式在往新的团队模式的切换过程中，就会存在一个信息流的过滤问题，无论是惯性的、被动的，甚至有时候是主动进行的信息阻断。

作为模块的设计者，天然需要从需求到产品、客户反馈等各个阶段的信息。充分利用这些信息，才能完成和完善设计。设计边界需要扩展到从立项到客户反馈的多个维度，保证信息流在这些维度上都畅通无阻，在设计的生产者和众多消费者之间都达成信息的对称和平衡。

Architect和Leader这两个角色，至少在一个目标上是统一的，那就是尽量减少设计边界内外的信息不对称。

（待续）