软件开发与文档

       在学校里加入的那个项目差不多也进行了有半个月时间了。

       这半个月时间体会到最为深刻的，便是软件文档的重要性。

在项目开始前，我们就被要求用一个月时间熟悉自己负责的模块-----整个软件分成了很多模块，当然我个人觉得我们这个项目很容易模块化---客户端和服务器端不可能在同一模块---熟悉过后，需要每个人写一分概要设计的文档。这分文档需要描述模块大致的功能。

项目开始时，组内有个小子被叫去听一个持续一星期的软件工程课程。讲课的是一个公司里的。大致内容，就是用7天时间开发一个管理系统，那人把文档分发下来时，-----一分详细设计文档，被分成N多分，每人一分，每人负责几个窗体，文档里把设计描述的太清晰了，几乎清晰到一个窗体上的一个按钮应该执行什么操作的程度。听几个老师说，在公司里就是这样，很多时候程序员也就是单纯地敲代码而已。

后来有一次又说到国内的对日软件外包，据老师说，日本人给中国的软件设计文档，也足够详细，详细到伪代码程度，基本上一句话就能对应一句代码！真够夸张！

项目进行了一周后，项目老大把我们的概要设计文档全推翻了。--事实上我觉得也该推翻。然后他起草了另一分文档，关于客户端的，所有窗体，每个窗体大致的行为，虽然没有上文说的那种文档的详细，但是也足够做为编码的指引了。----照着文档编码，确实很容易。而且很利于项目总体的和谐。

在我自己写游戏代码的过程中，虽然早就在写文档，但始终没达到上文那些文档的详细程度。以OOP方式编写程序，我觉得我渐渐忽视了一个东西， 那就是程序真正的逻辑！以前用纯碎的面向过程的方式写程序时，思路全集中在程序的主要逻辑部分，写代码时就针对着解决这个逻辑写。这样写出来的程序，可以算做一个DEMO，但是真正扩展起来，却真的是很困难。相比而言，用OOP的方式写，扩展性的优点就显得很突出了。我想，这也算作面向对象的一点好处。但是慢慢地，在设计一个OO系统时，我把重点都放在了设计类，构件对象上，真正的逻辑部分，反而被忽视了。这正是在组装所有对象时变得困难的原因所在。

也许，找一个系统点的方法来做这一切，会更容易一点。是时候系统地接触软件工程方面的知识了。