让实践，而不是条文说话

                   昨天部门培训了项目规范，心里有一些想法，希望能跟大家分享讨论下。

                   当然，走向规范化，对企业和员工的发展都是一件好事。但是规范中的好多条文很早以前就存在，比如说需求分析要与用户交流，写出需求文档，进行评审，开发后如果需求变动了就要提出变更申请，批准后才能变更。其实像这些东西，老员工基本都是知道的，像需求分析、详细设计、集成测试、系统测试计划的文档在刚进公司的都是很认真地写的，但是为什么到了后来，就形同虚设了呢。

                   在我们这种公司，没有专门的需求分析人员，开发人员都是一条龙服务，从需求分析到安装维护都是一包到底（利弊暂且不提，目前也似乎只能如此），比如说需求分析吧，开发人员也不知道怎么去准确的把握需求，因为用户对需求没有清晰的认识，总在变化，而我们也没有应对这种变化的经验，即使这个规范强制执行了，想想，费尽巴力写出一个需求文档，东西也做出来了，再拿给用户一看，人家又觉得不满意了，好多都得返工。既然总在变化，而且只有我在用，我为什么还要写文档，做这种吃力不讨好的事呢，最终的必然结果，开发人员就会跳过这一步。开发人员不是傻子，如果需求文档给我们的工作带来了帮助，提高了工作效率，减少了工作量，他会不积极地做吗。如果规范只停留在条条框框的层次，而不能告诉开发人员为什么这么做，做了有什么好处，不做有什么好处，该怎么做，它恐怕也只能成为束之高阁的东西。

                  

                   这里有一些很小的故事跟大家分享下，虽然很小，但却还是有些东西值得思索。

                   之前做过一个 shell 脚本，用来维护 manager 。其中有一个功能，列出一些 manager 的模块，供用户选择来进行安装、配置、启动的操作。后台这种简单的命令行界面，当然不能像 GUI 那样，让用户一次点选多个项。开始时直接参照的 windows 复制粘贴多个文件时的 UI ，比如有 3 个选项，就得像这样操作

                   模块 1(y/n)?

                   [ 用户选择 ]

                   模块 2(y/n)?

                   [ 用户选择 ]

                   模块 3(y/n)?

                   [ 用户选择 ]

                   等到这个 shell 开发出来之后，我发现易用性很差，比如我要选择模块 3 ，我仍然得输入两次 n 和一次 y 。一两次使用还可忍受，用的时间长了，就成为一件痛苦的事。这时候我发现我应该这样设计这个 UI

                   1) 模块 1

                   2) 模块 2

                   3) 模块 3

                   [ 下面是用户输入 ]

                   1

                   2

                   [ 程序将会操作模块 1 和模块 2]

                   说起这件事，可能有些人会觉得很可笑，觉得用脚趾头想也不会这么设计（我的室友就是这么说的 ^_^ ） , 后来想想，我的感觉也是如此的，为什么犯这么低级的错误呢？我发现，开发人员在想做一个东西时，总是难免会将自己的注意力几乎全部投入到实现中（设计也是一种实现），而很难冷静客观地观察用户的感受，而这恰恰是需求中很重要的部分。当我在做这个东西，我考虑的只是怎么在 shell 这门我不太熟悉的脚本语言中实现嵌套条件判断的循环控制，结果我做出了一个连我自己都不满意的东西，并不得不返工，它的代价是巨大而令人失望的。

                   在另一个自动备份文件的脚本中，也犯了一个错误， shell 脚本将一些文件打包压缩后用 ftp 上传到一台远程服务器上，我自作聪明的给每次备份的文件名加上了一个当前时间的后缀（我当时想的是怎么把 unix 系统默认的时间“ Thu Mar 13 00:25:28     2008”转换成"20080313002528" ），以此来区分每一次的备份。但是等东西基本成形，并备份两次后，我发现我在备份服务器上有了两个备份，我意识到，程序部署后，备份很快会塞满服务器的硬盘。幸好，改正这个问题花不了太多的时间。

                   其实开发出一些经不起使用考验的东西，在我们的开发过程中还是很常见的。比如通道调度搜索很多 tc 后，用户要逐个点选尝试（每点选一个就会让后台验证并返回结果），才能知道哪些可用，哪些不可用，在找到可用的 tc 前，用户通常都回失去耐心并放弃尝试。还有通道查询界面中列出台站树的功能，它直接列出了所有台站类型和类型树结点下面的台站，因为数据很多，用户会等待很长时间，姑且不考虑这颗树的加载算法，为什么不是开始只列出台站类型，用户双击类型后才列出下面的台站，当树层次较多时，这对速度和操作易用性都有很大改善啊。比如老的 cs 数据维护要等用户录入一大半属性点击保存时才提示某个必填的没有填（都次用它录数据都强烈地有种想杀人的冲动） .....

                   其实这些问题，当我们换了一个观察的角度时，那就是测试者时，都常常不再是问题。所以测试驱动开发对我们这种分工不明确、经验也很匮乏的团队真的的很重要，当我们先以测试者的角度来推敲我们的功能，模拟一次测试的过程时（当然最好的情况是它们能成为代码使测试自动化，从而在频繁的代码修改中充分保证开发的质量，但具体实现起来常常有一些难度，所以有时候只能是一些大脑意识中的测试），我们会发现开发者先前的很多想法都是站不住脚的。因为需求把握不准而导致返工是一个很头疼却也非常频繁的问题，这耗费了开发者的很多精力，不得不引起足够的重视。

                   其实上面说了这么多，就是想说一件事，一定要让大家知道实施这些条条款款的原因，为什么做，怎么做，它才能真的对我们的开发起到决定性的推动。否则就像大人们总对小孩子说水火无情，可是小孩子们还是很喜欢玩火玩水，那是因为他们还不知道受伤时的痛苦。