我看QMP(2)

       QMP之后如何发展是我非常关心的问题。目前，QMP要好处也有毛病，好处是好歹也能用，功能还是挺多的，如果用户没有自己的特殊要求，也具有一定的容忍性的话，那咱们的东西也还是不错。
       但我们都是爱浪漫的人，都是有追求的人，我们不能做吃山空呀。因此，我们需要分析QMP的优点和缺点，特别是要改进缺点，以使得QMP更加复合客户的要求。
       那么，QMP到底应该怎么发展呢？三种选择：

   1. 直接到新版本吧。这个版本根据我们获取的需求做重新的实现，满足用户对灵活性的要求：过程定制灵活性，界面定制灵活性以及数据定制的灵活性要求。满足公司的产品规划策略，满足企业按需选择等等要求。而上面说的这些要求：可以说是非常重要的非功能要求以及约束，会对整个软件系统的架构产生非常严重的影响。因此，该如何做，三思而行。
   2. 维护两套版本的开发。一套人马专门做旧版本的维护，另外一套人马来考虑新版本的开发，新版本还必须要保证和旧版本之间的兼容关系。这个，不太现实。我们还没有力量，没有资金去做这个工作。
   3. 改革旧版本。其实说，旧版本也是按旧不旧，一方面，旧版本还是需要继续添加新功能，力争把整个功能都给做出来。另外一方面，也需要对旧版本进行渐进改革。这里渐进改革的意思是：不对旧版本进行大手术，咱们好歹先做点小修小补，整理整理，重构重构，将以前没有划分清楚的地方划分清楚，将以前没有做好的东西做好。这个估计是最现实的方法，如果做好的话，对后续的版本开发也是相当有好处的。

       根据一般的软件开发过程，总是经历从需求到架构设计，到详细设计，到编码，一直到测试，到发布的过程。那么，这里，我主要将渐进改革的步骤集中在我们研发团队可以控制的三个步骤：需求，架构设计，编码。

       为什么要考虑需求这个方面？因为考虑到一个比较现实的情况：咱们的需求主要来自于市场调研、用户反馈以及项目组内部的需求。但是咱们一般收集功能需求比较多，重视程度高，但是对于非功能需求以及客户提出的约束条件，重视程度不是很够。这样，往往做出来的产品不能满足用户对于安全性，稳定性，健壮性以及持续可用性，集成性等需求。这些非功能需求以及约束条件对于我们后续的架构设计以及编码实现都是有非常大的影响的。如果前期这些需求没有收集上来，或者权衡不当，会造成软件项目的失败。

       因此，第一个需要改进的地方在于需求收集和需求分析。
   
    在架构设计上：我们产品有个特点，在于产品并没有一个清晰的实际架构设计。并不是说我们没有架构，我们还是遵循的J2EE三层架构以及MVC架构的嘛:)，另外，我们还是有流程图嘛，那里头还是划分了系统的流程图嘛。OK。这些都是架构，但是没有真正能够导致项目开发实践的架构设计，这里也就是说的关于系统组件以及组件之间的交互接口，交互关系都没有描述。这个是我们缺乏的，要对产品进行渐进改革，好歹也把之前的架构设计给补全一下子吧。这个就是我们需要做的事情，尽力将系统现有的架构给描述出来。

       是骡子是马拉出来溜溜，总不能老是待嫁闺中吧。ps：终于看到最早的软件架构设计文档了，按照《软件架构设计》书的说法，应该还主要是停留在高来高去的层面上。所以，组件之间的交互，这个构成架构的两大最主要特性之一，就随风消逝了。

    在详细设计上：我们的项目当中缺少有效的详细设计文档。做维护的人以及后来需要做升级开发的人不能得到该模块有效的设计文档。要看设计，只能看页面跳转以及Struts-config文件了，造成了很多不必要的麻烦。如果现在没有的话，那么需要补全。如果现在没有确定的格式的话，那么需要确定。

       在编码方面：冰冻三尺，非一日之寒呀。项目中的代码形形色色，林林总总。把代码全部扔掉，重新写过。这不是我们第三种方式采用的做法。就像治病一样，刚开始的时候不能下猛药，要先条理好病人的身体机能，然后再下补药。那么，对于代码来说也是这样。我们不能一上来就改变整个软件系统的架构，改变系统的开发技术和框架。我们首先要做的事情，就是将系统中不良的代码重构，将烂代码变成好代码，尽量去除系统中隐藏者的各种BUG，增强代码的可读性，可维护性，建立良好的代码结构，做出良好的代码设计。然后，我们再看是否需要做其它的改良。


    总体来说：我认为，要对QMP进行渐进式改革，需要依次做到如下几点：
    1. 在代码级上做代码重构。整理目前系统的架构设计，整理目前系统的详细设计，并成档。
    2. 整理系统的需求，特别需要注意是否遗留了哪些非功能需求以及约束关系。同时，根据需求，编写用例实现，提取领域模型。
    3. 如果可能的话，对系统进行实际的架构设计，描述系统组件、确定组件接口、明确组件之间的交互关系。对需要更改的模块进行更为合理的详细设计，更为合理的进行OO设计。形成基于领域模型的业务层。（这个是我们系统最宝贵的东西）