谈谈咱们的合做开发

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

    接到任务的第一天，你们作到一块开始商量合做开发的事宜。制定了一下咱们合做开发的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导出网页版的图等等技巧都是本身所须要锻炼的。不怕不知道，就怕不知道，如今我已经知道了，剩下的就是去实践。

版权声明：本文为博主原创文章，未经博主容许不得转载。