谈谈我们的合作开发

合作开发算是暂告一段落了，算算从开始接到任务到完成居然过了近半个月，不过收获也是不小的。

接到任务的第一天，大家做到一块开始商量合作开发的事宜。制定了一下我们合作开发的Schedule，然后开始了我们的合作开发之路。待组长画完用例图，我们一起讨论，一起敲定系统的具体用例，当然免不了有争论的地方，不过也正是这些争论让我们更加深对信息管理系统的理解。用例定好了，开始一起攻克数据库。根据用例，来设计数据库，规范字段名称，认真讨论字段类型，按着“三范式”将一个个表确定下来。然后为表添加各种约束，主键、外键、Check约束、Unique约束、Default值、Identify自增值等，并建立的数据库关系视图。包图一起确定了，然后开始分工，D层+Factory层+接口层1人，Entity层1人，B层+Facade层1人+组长，U层1人。

通过方才的分工可以看出，本次开发我们采用了三层架构，应用了抽象工厂模式+反射+配置文件和外观模式。在我自己做的机房收费系统中没有用到外观模式，感觉在处理多表操作的时候（比如下机），只用B层的话就显得有些力不从心了。所以我在第一次的机房收费系统总结的最后也提到了这个疑惑（ http://blog.csdn.net/xiaoxian8023/article/details/7168878）。这次用外观模式，虽然代码又多了，不过思路却比以前要清晰很多。外观模式将B层繁多的类进行了封装，对于U层而言，不需要了解那么多的细节，外观模式为U层只提供了一个简单的接口，U层其实都是那些粒度较粗的用例，只需要调用Facade层的方法即可，有Facade层来整理具体的逻辑，既满足了U层的需要，也隐秘了数据。所以外观模式这个“中介”对于我们来说还是很有帮助的。

当然我们也用到了策略模式，这个主要是用在下机结算时，根绝不同的卡类型，使用不同的计费方式。理解的比较浅。向七期的前辈请教，说其实刷卡上机和下机也是一种策略。当时没怎么明白，不过现在有些理解了。上机和下机也是两种不同的策略。刷卡时，要检测卡的上机状态，根绝上机状态的不同，实现上机和下机两种不同的策略。

这次有点遗憾的是观察者模式。在处理强制下机操作时可以用到。将在线的全部加载到一个列表中，然后通过触发强制下机操作，遍历列表，使列表中的每一项都执行强制下机操作。是一个很好的方法，只可惜这次由于种种原因没有加上，师哥遗憾。

不过这次的开发给我的感觉不像是同步开发。这次我们想自己动手敲代码，没有用UML图来导出代码框架，所以我们由下层写出框架，然后提交，再由上层根据下层的代码提示来写，这样一般不会出错。不过想想，图都给出来了，其实不用等着下层的提交框架也可以写。一个好的设计，有完善的图和文档，我们完全可以根据这些来完成自己的工作。

本次合作开发给我最大的感觉就是一个合作才是软件开发的正道。当然成功的合作，取决于项目的设计、分工的合理性及每个人对待自己任务的态度。项目设计的好坏可能直接影响到你的项目是否能够完成。如何更加合理的分工，我感觉应该是每个人做自己擅长的那一部分，可靠性会增加很多。态度问题，每个成员都应该尽力尽快的完成自己的工作，不要因为你而使得整体项目计划延迟。

有个问题想了半天，还是感觉说说比较好，我们有一部分成员把重点只放在了经历合作开发，而项目本身有些马虎了，感觉这样不好。我觉得，虽然合作开发的主要目的是为了让大家更好的理解三层，培养合作开发的意识和能力，但是，我们不能对于系统太过草率了。在我看来，每一个项目都是一个生命，生命不应该是残缺的。对自己的任务完成度要求要高，这也是一种锻炼，同时也是一种职业素质。

当然在合作开发过程中，也发现了自己要学的东西还很多。比如快速画图，数据库表直接转化为实体类和UML图，SVN的熟练使用，Rose导出网页版的图等等技巧都是自己所需要锻炼的。不怕不知道，就怕不知道，现在我已经知道了，剩下的就是去实践。