拒绝形式化的软件工程文档
最近在一个软件公司实习，这是一个小型的公司，承接政府和事业单位的一些工程项目。 我在这个企业所遇到的所有事情相信在中国绝大多数地方和绝大多数软件企业中尤为重要。
我已经在很多次的公开场合批评过形式化的软件工程，就是将书本上所要求的软件工程实践内容不经过任何具体化的措施和方法直接形式化套用。 这个做法的后果是极大的浪费了时间和资源，打击了开发者的积极性。
文档的本质是什么？为什么要写文档？什么样的文档才是有用的文档。
大多数的程序员没有主动写文档的习惯，这个可以接受，因为并不是所有的文档都有用，大概九成以上的文档是实际上的多余。
大家应该仔细考虑文档所处的位置和作用。 ——为什么不剪裁？ ——因为我们不知道哪些信息是有用的信息，所以没有办法建立“有用”的文档。 在开发工具和开发模式高度发达的今天，我们还在用“手工作坊”的方式写着文档。
我们的开发是进步了，可是我们的文档化却没有进步。 我对软件工程一直秉持着实用化的态度。这个和RUP的原则也颇为类似。
作为一种可以剪裁的软件过程方案，RUP在实际的应用上已经远远做到了我们现在还没有做到的境界。
从需求、设计、实现、编码、测试的一系列过程。我们需要的是“准确记录”，而不是文字堆砌的卷宗。
文档的本质就是“记录”，而记录的方法却有多种多样，“我们没必要用文字成篇的去描述，而一两个图形或者图像更有表现力”，UML如是说。 而我在前篇文章所说的带着一部DV去做需求，还是因为在需求的过程中需要采集需求，进而就需要记录。
而文字的表达能力是有限的，你不可能把一部人性化的软件交给一叠冷冰冰的纸张。因此，我们需要广泛的采集需求的信息。这时我们是在同客户分享一种感觉，一种用软件的感觉。 说到需求的分析，用例图给了一种改进，但不是里程碑式的改进。微软的开发过程就充分的体会到这样的问题，所以提出了一些改进的措施，可能是因为微软所做的软件并不是管理系统的原因吧。 到了设计和开发，作为结构最主要的表达——图形发挥了很大的作用，目前为止应该是最丰富的表达方法。
然而我们却乱画一气……不根据变更的需求去变更设计……设计文档又成了一种形式。我在很多地方都看不到设计文档，因为这个依靠想象力和创造力的领域变化的太快，文档跟不上思维。而我们需要的是一种可以经过反复讨论的设计思路，我们需要统一的设计规范——设计模式。它告诉我们在什么样的情况下需要什么样的设计。而Gof-23模式甚至不够用，他们只是遵循了某种面向对象的原则。
但是AOP是否有这样的模式呢，据我了解，是有的，只是很少有人总结。我希望很多专心于AOP的人可以像专心于OOP的那样总结出一些设计模式。 编码阶段的文档——这可能是大多数软件工程实践中最成篇累牍但是最没有用的文档了。 我所提倡的是良好的设计，良好的设计可以让编程人员（无论是专业还是非专业）对于实现可以做到一目了然。类似于一种模式，例如某个地方需要冒泡排序，我们就知道代码如何实现的。而不用考虑它是怎么实现的。
设计文档就要做到这一步，能够很轻松的告诉编码者整个框架是什么，整个结构是什么，而到了具体实现需要怎么做。而到了这一步，我们所需要的文档可能很少，甚至——没有。 编码阶段一直提倡的是自文档化的代码。这样的代码不光极具可读性，而且极具格式和规范性。我们所需要的可能仅仅是一份编码规范。剩下的，交给注释吧。
或者可以说：文档即是代码，代码即是文档。 这是编码文档的理想境界。但是这是需要很好设计才能做到的。而这样的设计是需要长期编码-设计，设计-编码训练才可以达到的境界。
而代码规范，便是这个阶段最重要的因素了。好的代码规范会早就高可读性的代码——这是我们不需要在编码阶段另写文档的重要原因。因为这样不光可以节省了时间和资源，还提高了代码的质量。
关于测试阶段的文档，这应该是及其重要的一环。如果是使用的RUP的软件过程，和现在通常使用的螺旋模型的话，当然类似的模型可以。这类软件要求测试对需求能够有一个反馈，这是大家常用的模型的特点。
而测试文档在这里所扮演的角色不光是记录，更多的是一种报告。包括从各种测试得出的分析及分析的对策。就像资深会计师对公司的运作情况和未来发展给出的分析一样。
资深的测试人员一定会对整个软件从需求、设计、到编码有最全面的把握。 所以，测试在软件工程中有很重要的位置。而不是所谓的简简单单“质量保证”或者“验证”，因为，质量是没办法保证的。测试不可能也没有必要穷举。因此测试文档不光要找出问题，更要有清晰的思路，因为新的需求会从这份分析报告（文档）中给出。这往往是大多数测试人员忽略的一环。
这些仅是我的所思所感，欢迎与我讨论。
我的原则是，软件工程一定要实用，要切实的有用而不是为了点缀而做的形式上的工作。 拒绝形式化的软件工程，拒绝形式化的文档。