转载说明：
本文是从公司内部技术支持论坛看得，作者不详。
作为对日开发的一员，应该多学习日方的长处，比如说文档。
=========================================================================
今天有幸拿到一份同行兄弟给我的对日外包软件设计文档，很平常的Excel文档，打开一看内容却感到非常不一般，以前听说过日本IT企业的“认真地死板”，今天算是感受到了。
这份文档分8个sheet，每个sheet明确针对不同描述领域，分别为：链接、版本修正、软件架构和业务物理模型、界面原型、界面原形元素设定（包含初
始化）、界面原形元素数据实现顺序、动作实现顺序、底层数据集描述和实现。怎么说呢？我算是看到过很多设计文档的人了，国内的、欧美的，这次加上日本的算
是全了70%了，我不想对日本发什么感慨，我只是想从这份文档本身出发谈谈看法。
1. 为什么要有独立的链接页面？
其实这个问题我不用多说，但凡是在IT行业做过的都知道这个行业有个很大的特色：早先没什么文档，自从CMM能增加企业光亮开始，文档一夜之间就铺天盖地
的出来了，甚至有段时间国内出现了文档容量攀比态度，各个公司之间，每个IT从业人员之间相互比对谁拥有的文档多，多意味着什么？专业啊！问题是文档多了
管理这些文档也麻烦了，不是丢了就是被某些糊涂蛋删除了，幸好聪明的国人想到了配置管理，我把这些文档分分类放到配置管理库那么就一切OK了。我曾经入职
过一家国内的大公司，第一天上班“师傅”就带给我一个10G的资料让我“学习”，我对这些文档的第一个印象就是支离破碎，看完这个刚有点感觉想看下面的时
候，找不到后面的资料了，当我找到后面资料时思想全乱了，一天下来头昏脑涨，这也是我看到的最讲究逻辑的行业做的最糟糕逻辑的事情了！
所以文档有个链接就非常好了，你可以让每个孤立的文档连成一个整体，让阅读者的思维通畅起来。回过头我重新看了一下RUP2000，里面的文档也是非常讲究相互链接的，不知道为什么这么好的东西到了中国就“消失”了。
2. 版本修正
我觉得国内只要是想正儿八经做IT的都会在各自的文档上加这个，只不过很多人没有考虑一个阅读的科学性，我以前的文档全是在目录后跟版本修正，这样的话如
果一份文档变动非常频繁，那么会造成页面下拉厉害影响视觉。有个细节是，这份日本设计文档的版本修订区是根据每个sheet做修订大项的，每个sheet
的细节分类变更包含其中，这样可以跟踪得很细。我们原来的文档着这方面却可以看出，细心的人写的细，粗心的人写的粗，总之在标准的文档也会有不标准的地
方。
3. 软件架构和业务物理模型
国内也有，至少我以前接触的文档就有这方面的内容，不过大多数是根据欧美风格来的，大框架的描述的非常精美，如果你想看细节架构和数据流就没了。这份日文
设计单独开辟了一个sheet专门描述着描述这件事情，选用的图形比较中规中矩，看了以后至少知道什么是入口，中间经过何等处理，最后的输出是什么或者什
么形式。看来日本并没有大规模推广UML语言，他们就是用了office提供的图形，我现在有些搞不清楚了，国内很多企业标榜自己的设计完全UML化，出
来的文档很专业，结果是少数人看的懂，也许在某些国人眼里，设计就是那天上的月亮岂能让凡夫俗子把玩乎？！
文档的细节是将模型中出现的文字都一一作了解释，有点词汇表的意思，但是没有RUP中词汇表那么大的作用范围。
4. 界面原型
原型这东西最能让阅读者快速理解，2000年开始国内很多IT企业就讲究
快速原型开发方法，但是至今我没看到过一份设计文档带原型，有的是有不过是后期开发完成后补的，这是聪明人做的事情。我看这份文档，到这里我已经完全明白
要做什么了，至少我不会担心我要自己设计什么稀奇古怪的东西。另外这个sheet标注了项目说明，这样结合原型我又能多理解很多东西。说BUG大部分都是
出现在需求和设计阶段，如果你能100%理解你要做什么了，怎么会让BUG穿透这么多层面流到客户地方去？
5. 界面原形元素设定
到这里我作为一个曾经的开发人员就要动手准备做了，本sheet详细描述了整个界面所用到的GUI元素，编程变量名称，类型，长度，格式例子等等，还有
GUI元素的坐标。其实我理解到了开发阶段，基本上就是光做不说的阶段，你还能指望有几个开发需要大量的 激情创造
才能生存下去？所以说，国内的开发吃欧美的编程天才的毒蘑菇吃多了，产生了愉悦的精神幻觉，要知道图灵只有一个他死在美国！
6. 界面原形元素数据实现顺序
这个要详细看看，其实这个sheet我理解的也不是很好，但是从含义来看是对GUI接收和反馈数据作的一个约定，哪些GUI元素是接收数据的，哪些GUI元素是反馈数据的，感觉就是很细节，是对前面一个sheet的补充。
7. 动作实现顺序
国内有个不好的习惯，习惯让测试人员最后写操作手册，我不知道这个是谁发明的并且第一个开始，我只知道这样的人在IT中对IT标准化是个莫大的嘲笑。这份
sheet详细描述了整个界面的操作动作，结合界面元素的不同组合详细写出业务可接收处理过程，如果你要写操作手册，只要结合VBS就可以快速生成一份
XX软件操作手册，何必再劳师动众让本已经疲于奔命的测试人员写呢？
8. 底层数据集描述和实现
这部分详细设计经过GUI收集的数据最终存储问题，国内很多都有这方面的描述，这一块日本作的实际了点，数据名称跟前太GUI元素作了捆绑指定，看了整个设计就通畅了。
最后要说明的是，这只是一份普普通通的日本软件设计文档，设计的内容是一个很小很小的资金查询，这样的东西以前我一天可以做好几个，但是到今天为止我做不出这么详细的设计文档。我觉得现在非常有必要反思一下我的测试用例设计文档 细节决定成败 我不愿意落在口头上。
今天的发文不代表任何含义，希望国内IT同仁们继续努力！
阅读(1091) | 评论(0) | 转发(0) |
