.. Kenneth Lee 版权所有 2017-2019
:Authors: Kenneth Lee :Version: 1.0
知不知上——控制调查范围
这又是一篇我说不清楚到底属于“架构设计”还是“道德经解读”的讨论。
《道德经》说“知不知上，不知知病”（吐一句嘈，道德经大部分话，用普通话念好难听， 还是用我们本地土话念出来押韵。我中学的语文老师杨宝霖老师是研究我们本地语言发展 的，他说我们的本地话是“唐音的嫡音”，所以我的古文背诵基本上都是用本地土话来背的 。我说这个，是要告诉你，其实道德经大部分话都是押韵的，只是你不一定会念），不知 道有没有人考量过背后的意思？
为什么是“知不知上”，而不是“全能全知上”？这个问题只有神棍才会问：），因为根本就 没有“全能全知”。自称全能全知的——如果你能看见的话——除了在你面前装神弄鬼或者扮清 高，啥事儿解决不了。所以，关键问题不在这个上面。
关键在于“不知知病”，我们觉得有问题的，是我们“不知道”“我们想要知道的”，这样我们 才认为是“病”（有问题）。换句话说，只有我们有“要解决的问题”，我们才知道我们有什 么“病”。这才是知不知上的关键。这是战略设计，也是软件构架设计的关键问题。战略设 计阶段，就好像玩2048游戏开始的阶段，你有无数的自由度，这个阶段你用“能解决问题 就好”，“能运行就行”来定义你的设计，后面很短时间内就会“数穷”，要让自己不那么快“ 数穷”，让自己的软件或者战略“天长地久”，就要“慈”，“俭”，“不为天下先”。也就是用 最小的筹码，实现所有想达成的目标。
所以，没有目标，无所谓“俭”。“俭”是解决了问题，但花的代价比其他解决问题的方法花 的代价少。
然则，全知就不“俭”，因为这花了巨大的代价，解决的问题却很少。要知知，要病病，前 提就是有目标。没有目标就无法知其所需知，也就无法病其所以病。所以，其出弥远，其 知弥少。要知知，就要回到问题的本源。所以贵“食母”。
我二十多年前入行，开始做驱动开发，然后做子系统的SE（系统工程师），然后做版本的 SE，然后做产品线的构架师，然后现在做产品系列的架构师。我发现我写的设计越来越短 。在我做SE的时候，我基本上都是用IEEE-1471-2000指导自己的设计的，其实IEEE1471对 构架的定义已经非常宽泛了，它是这样定义的：
.. The fundamental organization of a system embodied in its components, their relationship to each other, and to the environment, and the principles guiding its design and evolution.
翻译成中文大概是这样：
..
（构架设计是）一个系统的基本组织，和对它的设计和演进的基本指导。所述的
“组织”包括这个系统的部件，它们之间，以及它们和外界环境之间的关系。
这个通用度已经相当大了，无论系统是大是小，终究是个分解，聚合的过程。
做模块设计的时候，我可以设计关键数据结构，核心算法，状态机。到设计版本的时候， 我要设计部件选型，关键接口选型，考量开发和运营成本。到设计产品的时候，我就只能 关注总体人力投入，市场竞争力，所有依赖部件的生存能力，供应商和我们的关系等等。 到我现在设计“生态”了，我写下的设计，几乎就只剩下选择哪个需求做，那个需求不做了 。
这样，到了开发“生态”这个级别，IEEE1471也不够用了，我现在还没有找到比道德经更能 解释我现在为什么要这样来做设计的理论。
高级别的构架设计，其实很核心的一个工作是定义“我们不做什么”。因此我写的构架设计 常常通篇都是这样的东西：
某某某特性我们不做
某某特性让客户自己做
某某特性怂恿某开源社区和友商做
很多人表面可能不好意思说，其实背后会质疑：你玛怎么通篇都是“不做”，你到底做什么 ？哈，我就做那些被我发现“你”不做的：）这就叫为天下溪。
所以，构架控制其实是非常累的一件事，离远了，你控制不了（神棍就特喜欢这个，他们 喜欢说“人家到深山里去了，不和你们玩了”，不玩就死远点嘛，叫条毛啊？），离近了， 你破坏系统。不使力，成不了，使力了你自己变成竞争者。到最后，只剩下“就事论事”一 个可以比较长远的策略了。构架设计，也就“需求分析”是比较靠谱一点的（也不怎么靠谱 ），其他的，能长远比较难。
所以我通常都跟我的领导说，你别用我怎么干来评价我，你用产品的进展来评价我，因为 构架设计没有样子看的。这种逻辑其实也适合其他的系统控制。你的自信要建立在成败上 ，没有“成败”，说啥都是打嘴炮，打嘴炮最后就是看谁的嗓门大，有意思么？
但我这里不是要讨论这个，我要讨论的是，如果你的设计到最后变成了“不设计”，你还如 何控制系统向你期望的方向发展？构架设计首先是“设计”，是一个“有”，不是一个“无”。 那么，构架设计过程中，具体应该“守”什么？
我的一般观点是：
维护一组当前承认的需求
定义一组被承认的分支，并保持一个可以被自己控制的分支
对当前每个大的特性定义一组模型，说明整个结构和合作关系（这主要用来推演miss 了什么）
为当前偏离的发展方向，在特性设计中添加原则
然后，架构师就可以投下去做拜访客户，试用产品，写某个模块这种具体的工作，半年再 回来Review这些设计了。
如果这种方法不适合你的产品，不妨告诉我。
.. vim: tw=78 fo+=mM