在学校里加入的那个项目差不多也进行了有半个月时间了。
这半个月时间体会到最为深刻的,便是软件文档的重要性。
在项目开始前,我们就被要求用一个月时间熟悉自己负责的模块-----整个软件分成了很多模块,当然我个人觉得我们这个项目很容易模块化---客户端和服务器端不可能在同一模块---熟悉过后,需要每个人写一分概要设计的文档。这分文档需要描述模块大致的功能。
项目开始时,组内有个小子被叫去听一个持续一星期的软件工程课程。讲课的是一个公司里的。大致内容,就是用7天时间开发一个管理系统,那人把文档分发下来时,-----一分详细设计文档,被分成N多分,每人一分,每人负责几个窗体,文档里把设计描述的太清晰了,几乎清晰到一个窗体上的一个按钮应该执行什么操作的程度。听几个老师说,在公司里就是这样,很多时候程序员也就是单纯地敲代码而已。
后来有一次又说到国内的对日软件外包,据老师说,日本人给中国的软件设计文档,也足够详细,详细到伪代码程度,基本上一句话就能对应一句代码!真够夸张!
项目进行了一周后,项目老大把我们的概要设计文档全推翻了。--事实上我觉得也该推翻。然后他起草了另一分文档,关于客户端的,所有窗体,每个窗体大致的行为,虽然没有上文说的那种文档的详细,但是也足够做为编码的指引了。----照着文档编码,确实很容易。而且很利于项目总体的和谐。
在我自己写游戏代码的过程中,虽然早就在写文档,但始终没达到上文那些文档的详细程度。以OOP方式编写程序,我觉得我渐渐忽视了一个东西, 那就是程序真正的逻辑!以前用纯碎的面向过程的方式写程序时,思路全集中在程序的主要逻辑部分,写代码时就针对着解决这个逻辑写。这样写出来的程序,可以算做一个DEMO,但是真正扩展起来,却真的是很困难。相比而言,用OOP的方式写,扩展性的优点就显得很突出了。我想,这也算作面向对象的一点好处。但是慢慢地,在设计一个OO系统时,我把重点都放在了设计类,构件对象上,真正的逻辑部分,反而被忽视了。这正是在组装所有对象时变得困难的原因所在。
也许,找一个系统点的方法来做这一切,会更容易一点。是时候系统地接触软件工程方面的知识了。