Keep It Simple and Stupid

最近灵感爆发忙着画各种各样的图（对架构师而言画图其实就是在脑子里做设计），计划了很久的收尾题目没动手写，确定了一阵的水文也仅仅写了个标题。趁着有空有心情有体力，把这篇水文写完。 从艺十几载，一直很自信自己的设计能力，细想下来主要是因为相对于还在就事论事碰到某个问题解决某个问题的朋友们，我做设计的的时候有自己坚持的原则。不管现实结果怎样，有信仰的一般都瞧不上没信仰的。但是原则具体是什么？说起来也不外乎下面四点： 1. 先拆散了识别，再抽象并归一化。拿到一个工作，首先要做的是把工作拆解成各个独立且明确的子任务，然后根据任务的特征（数据流、交互方式…）再把它们归纳/归一成几类不同的任务，并且在这个过程中识别主要目标和主要矛盾。 2. 做芯片设计本质上是trade off，要坚持有所为有所不为。一个大而全且面面俱到的设计，即使做下来了也必然是毫无竞争力的产品。识别key point，把资源都堆上去做到95分；不核心的地方做到60分就行了。 3. 代码是人和机器都需要读的语言，70%是给人读的，30%是给机器读的。所以相比于所谓的PPA更优的代码，单位里的各位阿姨在咖啡聊娃之余也能随随便便就看懂的代码更有生命力和价值。 4. KISS，Keep It Simple and Stupid，做逻辑简单的设计。算1+1快还是12345*6789快不言而喻，哪个更容易做错也不需要判断。把复杂的工作做的很简单其实是件很难的事情，相反把原本该simple and stupid的工作变复杂到是很容易且具有很强的诱惑力，这也是很多比较有经验的DE最容易踏入的陷阱。 很多人做不到KISS的原因是他分不清到底什么是Simple and Stupid，所以接下来讲讲我理解的Simple and Stupid。所谓的简单绝对不等于设计的少或者代码的短，恰恰相反的是复杂或者over optimize的设计倒是经常能展现出简洁的表象。Simple and Stupid首先必须意味着思路的直接。碰到一个要解决的问题时，与其冥思苦想各种奇赢巧技，不如按照常见的方式按部就班的做。大道不出奇，守正才是正路。其次simple的设计一定是功能明确边界清晰的，stupid的设计一定流程确定缺少变化的。这和功能的多少、接口的大小、流程的长短是没有关系的。举个简单的例子，一个cnt类型的有1000个状态的状态机是个简单设计，一个只有4个状态但是每个状态之间都会根据不同条件相互跳转的状态机是个复杂设计。最后，一般而言积木的组合由于其灵活多变性导致它既不Simple又不Stupid，但是用于组合的积木本身不管它有多少种颜色和形状，它的用途都是单一固定的所以是简单的。 KISS从某种程度上说是对复杂功能的取舍和归一，可惜不能用最近遇到的例子介绍下什么叫KISS，最后总结： 1. 所有的设计都可以被归纳为解决问题，Simple and Stupid的解决方案一定是可以靠直觉想到的，不需要冥思苦想的方法往往才是好办法 2. Simple and Stupid的方法一定是不给意外机会的方法，HW设计请忘掉复杂的状态跳转和条件判断，把它留给软件吧 3. HW要做的一定是功能明确、边界固定、关注点单一的单元，调度是软件的活，HW要做的是提供合适且高效的调度方式 4. 要懂得隐藏细节，细节只体现在模块内部，模块间只能看到固定的接口，说白了就是解耦 5. 能用一种类型就别分两类，多项性差异只在真正用到的点上处理 6. 不要过度优化，也别过早优化 7. HW是积木，SW组合积木搭图案 8. 除非是对PPA有极致要求的场景（譬如几毛钱的iot芯片），否则自觉远离全硬化方案，给软件留点活让软件有机会爆肝演出，给硬件留点留点work round的余地