.. Kenneth Lee 版权所有 2020
:Authors: Kenneth Lee :Version: 1.0
开发视图
这个问题在我之前不少文档中都讨论过了，但还是有无数人犯这个错误，我意识到很多时 候犯错误的原因和技术问题无关，我要正面讨论一下这个问题。
4+1视图中的开发视图（Development View）描述开发角度看到的软件。它是所有系统设计 或者架构设计的基础视图。我看到人们总是犯两个错误。第一个错误——没有。他们会上来 就谈“报文被AAA收到，进行权限过滤，然后分发给除重模块，然后发给下一层……”，完全不 提开发视图这摊子事。第二个错误——填空。他们会画一副UML图，花团锦簇的，很多模块， 概念什么的，然后“搞定——我有开发视图了”。至于这个开发视图有什么用呢？跟他们没啥 关系。他们只是来考试，所谓设计文档只是一张答题卡，你要的东西我都给了，就等着你 打分，至于这东西有什么用，他们是不关心的。
这两个错误都是：没有开发视图。
什么是开发视图呢？“报文被AAA收到，进行权限过滤……”这当然是设计，但我们首先要问， 你到底要交哪些二进制文件出来呢？是哪个二进制在执行这个AAA所描述的逻辑呢？你到底 要写哪些代码呢？哪些是外部引入的，哪些是你写的代码呢？
实际上，现代的大部分设计，你其实就不是重头开发一个东西。你要收报文，可能你原来 就有一个Linux上的Daemon，你新的特性只是在这个Daemon上已有的Socket中多收一种类型 包，然后再通过pipe转发给另一个Daemon进行收集除重存盘，然后再发给下一级……这种情 况下，你就面对一个问题：原来的Daemon叫什么名字？有哪些版本？你新加的这个Daemon 又叫什么名字？和谁共同发布？版本号怎么编？你的整个开发打算支持哪个版本？
这就是开发视图（或者更准确一些应该是“开发视角的描述”），开发视图讨论的是设计逻 辑中一个影响所有设计工作的独立逻辑：我的软件到底在开发上需要分成多少分支？何如 哪里，多个部件接口（版本）上如何配套。有了这个，你在多个模块间的那些关联才是有 意义的，因为他们之间有版本匹配关系。
没有这种设计，不过是做玩具而已。
很多人不做这种设计，有部分是没有经验，学生刚毕业，根本不知道商业上面对什么问题 。但还有更多的人不做这种设计，是因为这种设计“脏”！
“报文被AAA收到，基于决策树进行分类，然后做权限过滤……”，这多Cool，多牛逼。
“现在网上已经有的版本是a.v.1.0.1.4sp1，a.v.1.1.2，a,v.1.1.34sp3，b.v.2.2.34，和 c.v.3.33，……，配套关系是……，我们这次准备升级a.v.10.1.4sp2，和b.v.2.2.34sp1，其 他的支持不了，这个新版本可以和如下版本配合……，但有一个例外是……”这种东西谁肯说出 来？多丢人。但你不说后面就不用管了？关键是这个是最影响工作量的，这个不确定，设 计必然会偏离的，这个设计本身就不及格。
当然，并非每个设计都需要这么详细。如果你是个系统设计，可能你要细化到每个版本， 因为系统设计是针对一个项目的，这一波要动哪些交付，那是确定的。但如果是构架设计 ，它给出的就是一种原则了，是用来决定每波项目投资的原子。但即使如此，你还是得有 你这种“多轮交付之下，如何定义每个软件的部件，这些部件的版本如何发展”的定义啊， 否则等你描述逻辑视图的概念，部署视图的时候，你怎么说得清楚你怎么这些软件交付出 来，然后让用户、销售，支持用什么方式部署出去呢？怎么说得清楚你某个接口到底在多 少个而进程版本的Deviation中都能起作用呢？
所以，拜托，写个设计文档实际一点，少在那里叱咤风云，这流程那分层的，实际点，你 的代码写在哪里？改什么？哪些用已有的版本，哪些是新加的部分，两者什么关系？把这 些基本的脏问题面对好了再说行不？
再说一个常见问题：缺少系统总线。比如你有个一个Daemon，里面有5个模块。现在要看你 的抽象层次了，如果你这一层不打算展开这一层设计，你罗列5个功能就好了，你别来给我 提这里面的5个模块。因为你的逻辑链碰不上这个分割，这个分割对不对我们也无 法校验，你做这个分解我不知道可以说什么。这个分割设计不被本层的逻辑链所驱动，无 法校验这个设计对不对。
如果你觉得要打开它的，你就不要直接告诉我你有5个模块，然后就开始谈它之间的接口。 你先告诉我：它们是什么（“模块”并非可以直接被开发理解的概念）？怎么被启动起来的 ？怎么互相关联的？从开发层面，这是直接面对的问题。你可能在main里面都放一个初始 化函数，然后互相调用对方的函数，也可能没人创建一个线层，然后等着别人给你的pipe 里发请求。你要定义他们互相的驱动力（线程控制在谁手上）是如何分配的，谁调谁的函 数，才能谈其他的谁把什么信息发送给谁的问题。
这也是一个开发视图常见的问题。