走过，经历过，思考过——图书馆维护系统

随着这个暑假的开始，我也开始了合作开发的道路——图书馆维护管理系统，严格来说是我第一次合作开发。开始还是蛮期待的，毕竟万事开头新鲜哈。经历差不多半个月的时间，结束了，随着今天米老师的同意，我们可以放下这个系统了，开始我的机房收费系统的合作开发了。下边我说说在图书馆维护系统，自己的所经历，所感。自己感觉是合作很宝贵的经验。

图书馆维护管理系统，是我第一次做的B/S项目，虽然小但是五脏俱全。也是我的第一次合作开发，虽然时间不长，但是锻炼很多，收获很多。下边，我从这五个方面来讨论一下。



一，从项目的流程上说：
大家都知道，项目的最基本流程都是：1，项目规划
2，项目需求 3，概要设计（详细设计） 4，代码编写
5，测试完善 6，测试发布 。我们几乎也是从这几个方面来进行的，但是却把重点放在了代码编写和修改上，忽视了很多东西。

首先，项目规划就是非常重要的一方面，而我们算是略过了吧。直接进入了需求。这样导致我们做一天算一天，没有压迫感，没有计划性，要不是贾琳师哥给我们做个大概的时间计划，不断的催促着我们，估计我们还不知道怎么样呢！
思考：规划对于一个项目时非常重要的，就比如公司接到项目，从开始到项目交工，必须要有个详细而合理的计划：每个人什么时间，完成什么任务，达到什么样的效果，而且这个规划必须以文档形式体现出来，让每个人清清楚楚。这里推荐甘特图的使用。

2，需求分析，经常听大家说“需求为王”，这就体现了需求对于一个项目的重要性。弄懂了需求，也就是弄明了目的，有目的的前进，怎么也比盲目的前进有效率。这个项目，由于有个前版，而且是我们自己内部使用，所以简单商量后就匆匆开始了下各阶段。导致真正做的当中，需求不断改变，不断的增加，甚至有的改变会引来很大的工作量，例如数据库表的添加，会引发每一层的添加代码。
思考：需求为王，需求为王，做项目一定要把需求搞的特别明白，有人会说需求是处在不断变化中的。那我们就努力把项目需求的可能改变想到，尽量的多想，并使代码对于这些需求的改变处于扩展上，容易修改上。这样，这个项目基本就掌握在我们的手中。所以了解业务，分析需求是整个项目成败的关键。

3，概要设计（详细设计），这是阶段是建立在需求的基础上的，当时由于需求分析的不是很好，导致设计时，对于拓展性设计的不是很好，导致系统的总体架构很难应付需求的改变。
思考：既然我们学习了面向对象，就要试着设计，如何使系统更加面向对象，如何能够更好的应付需求的改变，需求的增加这两项重大改变。

4，代码编写，对于功能的实现，我们都通过各种途径实现了。但是我们命名规范，注释等等却做的不好。
思考：项目功能的完成不是项目真正的完成，后边还有维护，还有版本的改进，做好代码规范，文档对应，文档齐全，这是对于后期维护工作非常有帮助的。这个必须在项目的前期做出文档的来规范，因为人都是有惰性，都喜欢随着自己的想法来，所以文档的规范，才会是一个系统更加大众化，更加合理化。

5，测试完善，这个当时我们完成了功能，就找了项目测试组来进行测试，结果出了很多很多，超出我们预想的Bug。为什么呢？
思考：自己负责自己的模块，自己昨晚以后可以自己先进行测试，或者让自己的队友给自己私下测试，使一些能够发现，能够避免的错误降到最低，这样对于开发组，对于测试组都会减少很多任务的，相应的减少支出，提高了效率。

6，对于项目的发布，这个由于是组长自己做的，没有太多想法。但对于测试时的发布项目，测试组测试，项目组修改Bug，感觉比较乱。导致测试组得不到最新的版本，开发组得不到及时的反馈。 思考：很好的协调，测试组测试和开发组修改Bug,还有最新测试版本的发布也是非常重要的。

二，从项目人员上来说，大家看我上篇博客：项目经理？项目成员？

三，从项目分工来说，这次项目分工不是太合理，导致闲的人没事干，忙的人抱怨。
思考：
1，分工要明确合理，要以文档显示：这个需要项目组长根据需求的模块，和模块的难易程度，还有组员的技术水平，来综合考察，进行分工，不可能完全合理，我们尽可能即可。通过各种分析，工作分好了，也必须要文档显示，每个人要完成什么任务，这个要比项目规划中的更加细致，因为需求已经有了，有了完善的文档，我们就可以按照文档进行了。
2，分工了，不要忘了，分工是为了更好的合作——要必须有联系，一个系统做完以后不能让客户看出是不同的人做的，这就需要分工后如何联系，使彼此之间即分工明确，又有联系。例如：界面的风格要必须统一等。

四，从项目人员沟通上来说：项目开发沟通是非常必须的，更有上次温欢师哥说过的敏捷式开发。这次合作开发项目主要是大家坐在一起，有什么问题就一起商量。 思考：
1，沟通要有计划性（突发性的沟通尽量少），这是为了使大家更加有效率的进行工作。做项目中问题是不会避免的，但是不能遇到问题就让大家处理，这样就把每个人提前计划好的时间，全部打乱了，我们可以有计划的进行沟通，处理问题，例如：每天晚上定时开会10分钟，汇报问题，组长解决，或者组长安排人解决，第二天早晨开会十分中，说说大家需要增加的任务，或者任务的变动。
2，开会要高效性，合作开发很多人一起开会是避免不了的。但是如何使会议高效性是非常必要的。这就是谁组织开会，谁主持开会需要做的工作。例如：次会议有没有必要召集大家来开，会议的目的，会议的流程，会议要达到的效果，这都是需要考虑的。千万不要一出现事就召集大家开会，结果问题也没有解决多少，反而浪费了大家很多时间。

五，从项目的学习上来说：这次项目结束了，但是对于我们这些菜鸟，项目的学习还任重道远。
思考：
1，学习的重点：a,对于合作开发，学习合作人员身上的优点，品质（这一点感觉比较难，但是三人行必有我师焉）。b,对于一个项目必要经历的部分，例如：如何分析需求，如何设计数据库，文档如何编写，分工如何管理，每一层的封装，实现功能的事务线等等，这些都是每个项目必须经历的过程，通过对这些的学习，我们可以很好的将一些经验运用到其他新的项目中，这样在通过不同之间的对比，我们的经验就丰富了。而对于具体模块，具体功能的实现是次要的，自我认为了解即可。

2，学习的方式，除了在项目实践中多多观察，就是项目后的总结，对于各个方面的总结。总结才是消化吸收，真正提高的过程。


综上，为项目结束后的一些感想，算是思想篇的总结吧。虽然出现这些问题了，但是觉的还算正常，毕竟第一次合作B/S么，好好积累吧，这样才能是以后的合作中做的更好！在接下会给出其他方面的总结，学习总结项目中……