合作开发总结

合作开发从开始的兴奋到后来的迷茫, 到云层渐渐的散去, 到万里晴空,  到系统最后的竣工.  切切实实的感受到了软件工程这一的过程些许的韵味.  

人员分配方式.

因为小组人数是三人 , 所以此次合作开发是人员的分配是面向包的 ,  而不是面向层的,  是一个人负责几层. 

此次开发依照原则.

做了这么多遍的机房收费系统了, 不能再是开始那样 "搭鸡窝" 了, 合作开发的目标和原则与开始第一次接触不同 .  开发过程中,有些平衡就是要我们程序员来衡量了, 有些逻辑, 粗粒度和细粒度的问题 , 我们要根据实际情况来看, 系统要从系统长远的价值上来看,不能只是看到一时,或是贪图一时的省时省力,  但系统一旦有改有动时不会省心.   此次系统要遵循可修改,可维护,可扩展,可复用原则. 

在系统架构的选择. 

组长考虑的周全,我们与以往的开发方式不同,而是按照角色把系统分成了三个子系统,可以说是按照功能分类的,这样子每个人画自己那部分的子系统, 从自己那部分子系统感受宏观方面的控制 .当然这样做的目的是为了系统的扩展方便,虽然会增加接口还有B层和D层的类,但是综合机房收费系统合作开发锻炼和系统扩展的双向考虑我们选择了这样的方式. 

文档驱动项目.

为什么要文档驱动呢,  文档就像接口 , 好的文档是,  任何程序员可以实现这个接口 .  文档如果写的详略得当 , 写代码的人员可以很少的沟通, 就可以根据文档和文档中的图来完成整个工程了, 作为" IT民工"分工更加明确 ,缩短了开发周期 ,提高了开发效率.  就像生产车间, 由手动生产到机器化大生产,生产产品除了机械化就是工人的流水线作业了.  而软件工程这个过程, 恰是利用一些软件开发CASE工具, 加上流水线工作, 且是同时进行的. 

CASE工具的使用.

感受到了EA(Enterprise Architect)强大生命力 ,又进一步熟悉了EA建模工具的使用.

文档之外的交流.

虽然合作开发中是文档驱动,通过文档的交流来开发, 但是初次文档驱动 ,虽是很熟悉的系统需求,但也避免不了每个成员想法的差异,  每个人对问题都有自己不同的见解,  这就需要交流了 .    我认为想法没有对错, 在说一件事情时都要看与这件事情本身相连接的环境.  一件事情的对与错要在一定的条件下来看待 ,虽然总是想说服对方,但是尊重更是万岁.系统怎么开发好，要看系统的外界条件。就像三层不是适合每个系统的. 

设计模式的理解。

合作开发加上的是抽象工厂，外观模式和单例模式，主要理解了一下外观模式，在个人版本的两次重构中， 我的B层第一次是对应这窗体的，或是说对应的功能的. 二次个人重构，B层是对应的每个实体的功能, 是对每个实体功能的操作。到这次合作开发，组长安排我写B包,对外观层的理解是这样的，业务逻辑包的外观层的功能是粗粒度，业务逻辑包中的b层是细粒度，b是只针对每个表的功能操作，只要是对一个表的操作，我们就放到b中，而外观是每个b的操作。

这样分逻辑是从系统扩展 维护 复用 修改的原则上来分的，把每一层当作一层抽屉，假设我们的系统要加一些功能，或是减少一些功能，这样b是可以重复使用的，不至于系统加功能改动的太多。有些时候可能b中的类会多些，这是弊端，但是扩展维护的角度来说这就是上上策了。

 

代码

写代码所用时间较短,就是前期画图设计的时间很长. 代码要按照命名和注释的规范,遵守提高班.net命名和代码注释规范. 

异常处理.

解耦解耦,三层的目的就是解耦, msgbox小窗体只能在界面上, try catch 要用的得当, 该抛异常要抛的得体, 提示信息要友好. 异常抛出设计总是不完美, 本次是界面捕捉异常, 外观层细节提示. 还有一种方法是定义自己的异常类, 去调用.  

 

调试

调试过程中,问题百出,  各种Bug满天飞 ,  各种照妖镜 ,调试的时间都大于编码的时间了.

测试.

简单测试.

合作开发初期的迷茫加上个人版机房收费系统的验收和修改, 加此次合作开发拉的战线很长,不过体验了一把 软件工程思想 实践的这一过程.