混乱开发，既伤身体又伤感情

   这几天读了些UML用户指南和设计模式面向对象开发，由于写了很长时间的程序，突然发现体力劳动越来越严重，情绪有些低落和凌乱。

   实现虽然已经结束，可是竟然在不知不觉中留下了一丝软件开发的阴影。这几天很不情愿去写代码，于是重新投入到软件工程方面的知识的研读和思考。很久以前一直在学习这方面的东西，而且很愿意投入自己的工程中使用。然而这次团队合作我们却陷入到深渊。

    3GCRM系统Android应用开放算是告一段落，就此刻的心情可以对这次开发做一个总结就是：失败的组织，混乱的开发，没有统一标准，团队软件工程的思想匮乏，工程进度控制不当，缺乏人性化，总之没有一样值得称赞。

    对这些问题想了想。

    首先团队合作出现问题：队员开发能力参差不齐，面对Android应用开发这个新的技术没能很好的接受；分工明确但是缺乏执行力；个队员开发速度不一致，存在了开发时间的浪费。

    其次,最重要的问题还要从软件开放的工程化思考。

    总体上这次项目开放实在混乱中进行这，最后我在进行模块组织的过程中并没能较为轻松的合并，而是参与了很多的代码的修改，错误调试等等。归结了一下主要存在这些问题：

    1.在需求分析已经做完整的前提下团队开发没能严格遵守

    2.各个模块虽然独立编程和实现，但是仅仅停留在面向功能编程的基础上，直接导致的是项目中冗余代码达到40%

    3.项目开发没有用到合理的设计，没能面向接口编程，封装性差。

    4.布局文件和程序文件没能进行有效的组织管理和命名

    5.在项目开发中没有制定统一的命令规则，这导致不同人员在使用其它功能能模块的时候出现命名混乱，代码可读性降低很多

    6.开发时间和模块开发顺序安排上不合理，致使开发周期变长，队员自身要求不够，没能严格遵守开发组的约定

    7.各队员对开发模块测试不完整，没能规定测试标准和测试要求，产生了模块组合出现错误的现象

    最后，从开放的状态和态度上，要求不够。细想，出现一种常见的现象就是：激动编码。共同存在的问题，遇到问题，总是第一时间想去编码实现和解决，这样产生的问题是问题解决了，项目中代码组织一团糟糕，失去了面向对象程序设计的基本准则和要求。

    激动编码也是混乱开发的一种普遍的体现形式。面对一个问题，可以通过思考和小的CASE测试来实现，但是这样的做法只能作为测试或者方法事例，绝不能投入到软件项目中去，试想如何每一个参与者都本着解决问题的心态去进行项目开放，结果可以想象，问题将会越解决越多。既然是工程就应该遵循规定和标准去做。

   遇到的问题还是很多，想想，看看然后真正的从软件工程化的角度去对待，可以激动，但一定冷静，毕竟编码只是软件开发的一个部分，不是全部。无论是从设计，还是使用，升级都需要而且必要合理和设计和规划。

   实习超乎寻常的累，就是没有重视软件开发的工程化，到头来精疲力尽而且感情备受打击，一团谈不上重用与健壮的代码，非人的UI设计，简略的开放文档只能算是出了力，没落好啊！

   已经经历了，算做软件开放的一个新的旅程的开始吧！大道至简，我想软件也是如此吧。