2007-09-02

毕业设计项目开发体会

关键字: 毕业设计
整理资料时无意中发现以前写下的一些文字,现辑录下来,算是对以前生活点滴的一种记念吧!
 
      首先,这次的项目设计能够获得优秀毕业设计是对我们全体项目小组成员一个半月努力付出的肯定,在此我要感谢为我们提供需求分析的袁经理以及在项目的开发过程中给予我们技术帮助的指导老师们。本人有幸担任这次项目设计的组长,在项目开发的过程中也经历了一般软件项目过程中遇到的难题和挑战,现在回过头来想起开发过程中的点点滴滴,虽然这个项目算不上一次成功的开发过程,但确实让人体会深刻、收获颇丰,愿写出来与大家共同分享:

交流方式

        很多人都知道交流在项目开发中的重要性,却往往不知道什么样的交流才是适合的有效的方式。在项目一开始我们就通过定期讨论、各种工作文档进行有效的交流,后面发现执行效果还是不尽人意,因为发现有些组员不善于口头表达自己的想法,于是又组建了QQ群组进行即时沟通。我们利用面对面的讨论,解决很多细小方面的误解;有效地使用QQ群组,来弥补一些在讨论中无法取得的效果;而对系统的全面的理解则通过各种系统文档。三种方式交错进行来确保每个组员对系统认识上的一致性。

完美与放弃

  在《人月神化》中有一名为”The Tar Pit”的章节,翻译过来的意思是“焦油坑”,这是一个很形象的比喻,在这一章中Brooks大师用简短的篇幅,描绘出整个程序世界的苦与乐。在这次项目开发中,有两个苦恼体现的比较明显。
        首先,必须追求完美。“因为计算机是以这样的方式来变戏法的:如果咒语中的一个字符、一个停顿,没有与正确的形式一致,魔术就不会出现(现实中,很少的人类活动要求完美,所以人类对它本来就不习惯)。实际上,我认为,学习编程最困难的部分,是将做事的方式向追求完美的方向调整。”很幸运,我是个力求完美的人,而且我也一直认为程序员应该具有这种本性。在编写程序的时候,甚至对一个变量名我都要反复斟酌,直到选择一个我认为可以精确表达这个变量意思为止。我并不认为这是在浪费时间:一是有助于对程序的理解和维护,好的程序本身就是注释;二是减少错误发生的可能。这次开发因为时间短,我尝试采用设计->编码->编译的方式来写程序,经常把一个代码模块写完之后才开始调试。效果不错,因为对设计考虑的比较充分,基本上都是一些拼写上的错误。然而,这种追求完美的思想放到项目开发中却有可能导致项目的失败,在系统功能和及时交付之间我们必须面临痛苦的抉择,于是苦恼接踵而至:项目开始的时候,我们把系统定位在智能排课上,于是没日没夜地查资料,各种实现途径遗传算法、退火算法、专家系统甚至神经网络都找来囫囵吞枣地消化了一遍,后面才痛苦的发现那些算法根本无法实现系统那些毫无规律可循的需求,折腾了一周,头脑中最后只剩下两个字:“放弃”。

        其次,是来自他人的设定目标、供给资源、提供信息。

        对于程序员而言,对其他人的依赖是一件非常痛苦的事情。在一个项目中,每个项目成员必须依靠其他成员的程序,而往往在自己看来这些代码设计得并不合理,实现拙劣且不完整,或者文档记录得很糟。所以,有些时候不得不花费时间去研究别人的代码,而它们在理想情况下本应该是可靠完整的。追求完美的心态再次让我们陷入无尽的苦恼之中,这时候你会怎么选择,重写一遍别人的代码吗?答案是 “NO”,我们得学会向他人妥协,整个项目才能按照既定进度不偏不倚地进行下去。

        程序员要学会放弃一部分乐趣,整个项目也一样,这是我完成这个项目后感触最深的一点。

负起你的责任

        软件项目的完成,需要团队的齐心协力,相信这是大家都有共识的。我想说的是在我们这样一个项目团队中,每个人都是潜在的项目负责人,为什么要树立这种意识呢?原因是我们是一个学生团队,不具备严格的工作规范和约束力,我们不能确保团队中的每一个成员都负起了他应有的责任,这其中包括与他人协作、规范化编写代码和文档以及测试代码的习惯。有些成员的想法只局限于自身负责的系统模块,只顾一味发挥自己的创造性埋头写代码,结果就可能象上面提到的那样,自己认为很得意的程序在其它人的眼里却成了一堆意大利面条,理不清、看不懂。在项目中我们难免会遇上这种情况,我的做法是尽量引导成员从项目的角度来观察系统,因为只有把自己摆在项目负责人的位置,你才有可能从系统整体甚至无关于系统本身的角度去思考这个模块应该怎么编码才会与其它的模块无缝地结合,给他人提供便利。这一点非常重要,想象一下我们以后投入到实际的项目开发中去,我们还能象现在做学生项目这样率意而为吗?所以越早树立这种意识,就能越早适应以后的工作,并让自己极具竞争力。(借以自勉)

不要让你的团队出现不同的声音

        严格来说,这是这次项目的教训而不是经验,作为一个需求不很详尽的系统,我们所能做的就是边做边摸索,尽可能地进行重复迭代来减少风险和完善系统,这时问题出现了:很多成员适应了传统瀑布式的软件开发流程,认为需求的变动会导致重复无用的工作,分歧的出现要引起高度的重视,因为一个团队中出现两种不同的声音是一种很危险的标志,我们这时要做的是通过各种方式尽量消除不同的声音,让团队保持高度一致,这样项目才能顺利地开展下去。
        另外在这次的项目开发过程中还有一个小插曲,我们组唯一一个女生在做窗体的时候总是喜欢在控件的边框加上与众不同的边框颜色,各位认为这是个小问题吗?可能有些人不以为意,外观不一致又不影响软件的功能。的确,外观确实不影响功能的实现。那么我请问,如果你作为一位软件用户,天天看着这些外观不统一,风格不协调的软件界面,你作何感想。总之,尽量让你的团队保持一种声音,一致的发力方向,这是确保项目按期完工的保证。
 
保留激情

  从上面的分析可以看到我们存在很多问题,但尽管有很多不如人意的地方,我们还是把项目开发完成了。因为我们有一个法宝——激情,激情可以战胜任何困难。
 
“我们来自五湖四海,各自为了心中的梦想在软件的世界里寻找自己的坐标。也许是缘分,也许是偶然,也许是心中共同的信念和梦想,让我们走到一起;共同努力,相互帮助,默默奉献着自己的力量,在技术的天地中贪婪地汲取养分,渴望成长,渴望强大。”“感谢上帝让我成为了为数不多的那些开开心心地做着自己喜欢的工作的人之一”。
 
回想这一个半月里的日日夜夜,是一种骄傲与自豪。有人问我这么辛苦是为了什么?我也常常问自己,为谁?为钱?都不是。因为我年轻,因为我有激情,因为我从不后悔。在网上曾看到一段话,值得回味:
 
  无情的岁月让我们一秒秒地老去

  慢慢地封存在发黄的照片里……
          在回首过去的时候……

  在那渐渐被遗忘的岁月中

  我们应该要为自己的人生留下感动的回忆和汗水……
 
       最后,要对我们全体项目组成员说声谢谢,正因为有了大家的共同努力,才会有今天这一小小的成绩,这一荣誉属于我们其中任何一个人,我爱你们!

评论
发表评论

您还没有登录,请登录后发表评论

lee5593
搜索本博客
最近加入圈子
存档
最新评论