.. Kenneth Lee 版权所有 2020 :Authors: Kenneth Lee :Version: 1.0 怎样写标准提案 *************** 引言 ==== 本文是为一个内部培训写的准备材料，因为以后这个培训迟早要对外的，我写在这里。本 文介绍怎么给标准写提案。 我会用一个和技术无关的例子作为类比。这是我在公开的地方写东西惯例。最早的时候是 为了保密，避免技术泄露。但渐渐我发现，这不但可以防技术泄露，还有更大的好处，它 可以让我们更聚焦Pattern（模式），而不是问题本身。 昨天晚上有一个读者私信和我讨论王守仁的“破山中贼易，破心中贼难”是什么意思，说我 也经常谈到这个贼，问我背后有什么深意。我就很好奇，我怎么就喜欢谈“贼”了？然后他 给我发了这幅图： .. figure:: _static/偷.jpg 我实在没有想过还可以从这个角度来发现我在“偷”方面这么有心得的。这是一个例子：你 要找Pattern，你怎么都能找到Pattern，要想突出你自己的主题，不是容易的事情，越是 用大家都熟悉的例子举例子，大家就越是看不到你想突出的Pattern，因为他们看见自己熟 悉的东西，总会忍不住想强化自己的熟悉的知识，这样反而离开你本来想强调的东西。比 如你用数据库举例说明接口定义的重要性，熟悉数据库的人会不断纠结于这个SQL语句 where中使用两个index查找性能不高，这反而影响了表达。 所以，我们还是用一个非技术的例子来说明我们的问题，但在关键的地方补上一两个技术 问题作为提示，这样的效果反而更好。 本文用一个连锁加盟奶茶店的认证标准来说明写标准提案的方法，笔者对如何运作奶茶店 没有任何认识，我们大家就用一般吃瓜群众的思维，来一起考量这个问题下，怎么看到标 准提案写作的问题。 什么是标准和提案 ================= 标准是一套有目的的，明确的要求。比如我们对所有要加盟同一个品牌的奶茶店进行认证 ，我们就会对它的店面形象，财务方式，原材料获取等等方面，提出要求。这就构成一个 标准。我们通常用一个标准委员会去控制这个标准，允许什么规则可以加进来，不允许什 么规则加进来。 一般标准委员会都是基于技术的，所以通常就叫Technical Steering Committee，简称TSC 。 提案是对标准做出增减的申请文本，用于TSC去决策是否接纳这个修改。在提案通过后，提 出者还需要给出明确的修改内容。这个具体的修改，称为一个Patch。提案是Patch的前提 。 理论上，我们可以认为标准的定义一开始是空的，第一个修改的人提出了第一个提案，然 后提供第一个Patch。但通常TSC是有人写了初稿以后才组建的，所以这里并非那么绝对的 。但大部分提案是基于一个已经存在的标准的，这是一个现实。 标准体现出来是一组原则，但背后是有目的的。比如我们在标准中定义一个要求，全部认 证的奶菜店都需要用绿色的的店面配色，背后可能就有“形成统一的视觉冲击，从而带来群 体效应”这个目的。在标准中不一定会写这个理由，在标准中可能是这样一个定义： “店面装修必须符合如下配色定义：……” 它不会说明：“这是为了形成统一的视觉冲击”。这一点不写在标准中，但提案中必须呈现 这个目标。（部分标准会包含一些commentary的段落，用于增强读者对定义的理解，这是 一个好的实践，我们也鼓励，但commentary不是标准定义的主体） 目标和防线 ========== 这样我们就谈到提案最基本的写法了。很多人发提案前，第一件事找我要Template（模板 ）。Template我有，但我一般不会随便提供Template，因为我担心要Template背后的用心— —你必须非常清楚，Template不是我们的重心，我们关注的是你的目标，和你为实现目标采 取的方法。如果你保证不了这一点，即使你填满了Template要求你写的每个章节，这个提 案都是不及格的。 所以，要写提案，别的先不管，请首先把目标大大地，清楚地，明确地写在整个提案的最 前面。TSC没有时间给你猜谜语，TSC成员都很忙，评审你的提案是因为这能增强这个标准 ，能让所有的参与者收益，所以我们首先需要判断的是，你给出的目标是否符合我们的期 望，如果这个目标我们不关心，从一开始这个提案就会被打回，我们互相不要浪费对方的 时间。 目标确定以后，后面的所有东西都是证明这个目标。这涉及到我们的第二个要求：请首先 保证你的每步证明都是“没有破绽”的，然后才开始进入细节。 所以，不要用写标准的写法来写提案，比如你的目标是解决加盟店互相竞争导致员工都不 能放假问题，不要上来就说：“所有加盟店都要星期二放假，如果当周有法定假日，分两种 情况，如果法定假日在星期二，则如此如此，如果法定假日不是星期二，则这般这般……”， 我们看提案，看到这里逻辑链就已经断开了，根本就没有兴趣去看你的细节。 正确的写法是：为了让加盟店员工都能得到有效放假，我们采取如下策略： 1. 统一开门和关门时间 2. 统一放假时间，避免互相竞争 这是你的第一层逻辑，我们从这一层开始就开始挑你的破绽了。比如说，有人会挑这个刺 ：如果这样做，我们统一放假的时候，竞争对手正好就在这个阶段填补我们的市场空白怎 么办？ 那这个策略就没有这么简单了，它需要变成这样： 1. 店面分成A、B、C、D四个时间段类别，覆盖不同客户群的要求 2. 根据地域分配A、B、C、D加盟店的类别，不同类别的加盟费用不同，同一个店面不得属 于两个类别 3. 不同类别加盟店必须严格按规定所定义的时间段类别营业，否则将按详细定义的罚则进 行处罚 这个定义也有可能有破绽的，而且不一定是暴露在这一层，可能在定义时间段的时候，细 节上触犯国家劳动法等等，所以，这是一个经验和权衡的工作，TSC根据自己的专业经验， 判断这一层的定义是否还有破绽，才会进入下一层。所以TSC才需要由来自不同背景和利益 体的人组成，这最后都是为了保证最后落实为细节的时候，这些原则仍可以成立。 所以，每层的逻辑定义，本质上是围绕目标建立一个防线，防住所有包括TSC成员在内的所 有标准成员的攻击，直到没有破绽了，这个提案才会被接纳。 所以提案可以分次提交，第一次提交的提案可以只包含一层逻辑防线，等你防住了第一波 攻击了，可以再补充第二层的逻辑防线。直到满足要求。当然，如果你对整个设计有信心 ，一次完成所有定义再拿出来讨论，这也没有问题。 简单总结：请保证明确定义你的目标和分层定义你的逻辑链，保证每层包含定义全集，不 要在某层定义没有覆盖全部可能性的时候，就开始进入细节讨论，因为在高层逻辑还有破 绽的时候，底层逻辑定义可能全部都是浪费的。 概念空间 ========= 这个小结我们讨论撰写的具体细节，第一个要求，请确定你使用的概念空间，减少使用你 自己专业领域的专用概念。标准本身也是一个逻辑链，只是不一定给理由。所以标准会定 义自己的概念空间。比如奶茶店这个问题，什么是店面UI，什么是配方，什么是一级加盟 店，什么是二级加盟店，什么是午餐类食物，什么是零食类食物，这都有定义。这些定义 在不同的上下文中，会形成非常细致的要求（比如“下午三点后不得在二级加盟店销售午餐 类食物”），它们的引入，都是为了解决之前提案中各个目标的问题。 所以，你要加新的提案，要尽量使用已经存在的概念，如果这些概念不够你用，你要加入 新的概念，就必须详细定义这个概念的意思。我们这里不是要求无限度去为定义而定义。 但如果你用到的概念涉及到和别人的定义相关的部分，你轻易不要引入你的概念，因为这 些概念已经和每个具体的要求密切相关了。比如你平常在店面经常把食物分成堂食和 Takeaway，这个甚至我们都知道，但如果你定义“堂食的零食不打折”，你这个怎么叫堂食 就不能随便用，因为我完全可以打包以后坐下来吃，这都不容易说清楚。但说不清楚就很 难确定这个设计到底是否可以接纳了。所以，事实中可以用的概念，不见得在“标准”中可 以用。我们不是要求你像老学究那样无限细化去定义所谓“严格”的定义，但你至少要知道 ，现有的定义已经被很多细节所控制了，它无法允许你随意去发明新的定义，特别是不允 许你的定义和已有的定义有半重叠，半区别的含义。 在有了概念以后，请注意描述一套原则或者设计的时候，不要切换主语。这是我经常看到 有人犯的错误，他们喜欢说“原料配送车从总部出发，先遍历所有一级加盟店，一级加盟店 接收原料后，交给后厨，后厨先加水放冰箱中存储……”，这个设计的主语一直在切换：配送 车，一级加盟店，后厨…… 这样的写法就会出现前一个小节我们提到的“破绽”问题，因为这样的表述方法下，要求每 个对象都是“乖孩子”，随时都准备好了支持你这个规则定义。问题是，每个实体都有其他 的规则在左右的，比如加盟店还要遵循放假原则，还是需要遵循清洁规定，不是等在那里 等你来送货的。 在真正的技术方案中，每个处理器，每个总线控制器，每个中间件，每个Socket，甚至每 个变量都是有自己的设计原则的，你的方案行不行，关键在于这些实体每个的状态机是否 仍可以维持自恰，不是单独你这个流程行还是不行。 我们可以看你某个流程，但在挑破绽的时候，我们是看每个实体的独立状态机是否仍能保 持原来的切换的。你不对每个实体单独建模，这个工作其实就是抛给读者了。这个提案相 当于没有完成，这种提案是无法被接纳的，除非你的提案带来巨大的利益，值得TSC给你投 入时间，帮你完成这个建模。 使用继承和泛化 =============== 每个提案，都是一个设计，每个设计，就会破坏一组已经存在的原则。一个相对成熟的方 案，里面包含大量的细节，修改这里面的原则其实是非常困难的。 所以轻易不要发明全新的概念和原则，而复制已有的概念去做变更。比如说，我们给出了 一级加盟店和二级加盟店的概念，这背后有利益平衡的问题（多给钱多收益，少给钱也能 收益），也有法务的定义在里面（多少保证金才不会被认为非法集资），也有财务的定义 在里面（如何操作资金才会最少）。所以，如果你想改变利益平衡，你尽量不要再定义新 的概念，比如“金牌客户联盟”，然后定义一组新的原则给它，这样你原来定义好的财务和 法务策略就全都没法实施了，这个成本非常高。这种定义对架构是毁灭性的，这样的提案 很难被接受。 所以，更应该考虑的是增加一种“0级加盟店”，这是一种特殊的“一级加盟店”，这样，就比 较容易加入到原来的概念空间，而不会产生巨大的冲击。 用好继承和泛化来在名称空间中增加细节和独立逻辑，这是能正常增加新概念到标准中的 基本方法。 撰写Patch ========== 撰写Patch其实就是写标准本身。我们首先要求写作者先下载最新的的标准版本，因为在你 发出提案的时候，其他人也在准备提案和修改标准。所以，保持你在提案的邮件列表中， 我们不要求你阅读所有的提案，但请知道谁和你同时在修改相关的部分，请提前和他沟通 ，保证你们的修改是不会冲突的。 同时，请仔细阅读一次当前的标准描述，保证你知道标准作者所处的立场。你写提案的时 候，你是站在你自己（和你的利益相关方）的角度来写你的观点的，但当你开始写标准， 你是站在整个领域的领导者的角度来写这个标准的，保证你的修改仍保持这个角度，保证 这仍是一个人的文档，而不是一个“七嘴八舌”的大杂烩。 写在最后的话 ============ 最后，欢迎大家都提交提案。但也请大家主意，提案的折损率是非常高的。每个提案提出 来，需要面面俱到分析很多很多的场景和细节，到最后写到标准中，很可能仅仅是寥寥几 句话。而且也许你的提案做了很多设计，但最后有一个细节过不去，这个提案就会被否决 。 但您的工作不会白费，一个成功的标准，就是大量这种“失败”的推演去支撑的，您的工作 是支持这个标准成功的一份力量。我们备份每个提案和相关的讨论（所以我们要求所有正 规的讨论都必须在邮件列表中），TSC非常不愿意否决一个付出巨大工作量的推演和分析， 但TSC为架构成功负责，不敢收入会动摇整个定义逻辑空间的或者限制未来发展的提案，这 需要每个提案的作者理解和支持。 Welcome to join the party!