当前位置: 代码迷 >> Web前端 >> 道Web应用系统的可维护性
  详细解决方案

道Web应用系统的可维护性

热度:306   发布时间:2013-09-06 10:17:17.0
谈Web应用系统的可维护性

 
       应用系统的可维护性主要表现在三点:
       1.   可理解性:  是否很容易地理解软件的行为, 理解系统的功能是如何实现的;
       2.   可识别性:  当出现错误时, 是否很容易地定位到错误的源头;
       3.   可变化性:  当修复问题或扩展新功能时, 所做的修改和影响是否局限在更小的范围内。 
 
       每一个软件开发人员都十分清楚, 当软件构建得越来越复杂时, 可维护性就成了一个很突出的问题。 如何在构造软件系统的过程中始终维护可控制的可维护性呢?
 
      一、 整体组织
 
      首先要从整体组织层面进行规划,基本方法是分层和模块化。
      比如, 一般 Java Web 应用系统会划分为 Controllers - Services - (Dao , Network) - Model - Constants - Utils - Result 等层面和模块。 Controllers 是控制层, 负责资源映射、参数传递和结果返回; Services 是服务层, 负责具体的业务逻辑实现; Dao 是数据访问层, 负责与数据库交互; Network 是网络层, 负责从外部系统获取服务, 通常是 HTTP 调用, Model 定义应用系统中的数据对象, Contants 管理应用系统中的所有常量及参数KEY,  Utils 管理应用系统中的实用工具类, Result 对应用系统中的结果进行管理。 
       进一步地, 还可根据各种业务模块进行细分。如果应用系统依赖于某些基础设施, 比如并发, 那么, 可以将这些基础设施单独组织起来, 提供简单而高层的接口。 最终的组织结构可能是这样的:
 Project      
        Constants              // 常量管理
        Controller              //  控制器定义
               ecs , slb           //  每种业务均有一个包
        ControllerImp        // 控制器实现
               ecs , slb
        Service                   //  服务定义
               ecs , slb
         ServiceImpl          //  服务实现
               ecs , slb
         Dao                       //  数据访问定义 
               ecs ,  slb     
         DaoImpl                //  数据访问实现
               ecs ,  slb
         Model                    //  数据传输实体定义
               ecs , slb
         Invoker                  //  外部调用接口定义
         HttpInvoker           //  http 调用抽象类
                EcsInvoker      //  Ecs 相关的调用实现类
                SlbInvoker      //  Slb 相关的调用实现类
         Utils                        //  实用工具类
         Result                           // 结果接口定义
               InvokeResult         // 外部系统的结果表示
               WebFrontResult    // 返回前端的结果表示
               ResultModel         //  结果中涉及到的实体定义
         MultiThreading          //  多线程设施模块
                callable                //   多线程的任务定义
                       ecs, slb         
 
        比较理想的情况是, 每段代码都应放置在它应该在的地方, 做它应该做的事情。
                            
       二、 逻辑分割
 
       提高应用系统可维护性的第二步就是分割系统, 将系统中的业务逻辑尽可能分割为相互独立、容易理解的微小工作单元, 即小方法/小函数。要坚持不懈地迭代这一步, 才能保证在项目开发过程中, 始终保证应用系统的可维护性在可控的范围内。具体方法有:
        1.  资源映射: 将不同请求映射到不同的逻辑单元, 这通常可以实现不同请求的逻辑处理是相互独立的; 这些逻辑处理单元尽可能不要涉及到全局资源的共享写访问;
        2.  将冗长的逻辑分割为若干段紧密相联的短逻辑, 每段短逻辑只完成一件事情;
        3.  将复杂的逻辑分割为多层, 每个层面完成自己的事情, 比如一个完整的Web请求处理: ApacheHttpServer 负责请求的负载均衡; Web Server 负责请求的转发和回调过滤器、监听器进行预处理; Spring 负责 Controller/Service/Dao 单例的构造、初始化和注入应用, 以及请求的映射 ;  Controller 负责获取请求的参数,传入 Service , 并获取处理结果 ; Service 负责具体业务逻辑的实现,可能依赖于 Dao 提供的数据库服务, 或者 Network 提供的 API 调用服务, 并将结果进行后处理, 传回给 Controller  ; Dao 提供数据访问服务, Network 提供外部系统调用服务, 将获取的结果注入到 Model 的实例集中,交付给 Service ; Utils 在其中做一些打杂的事情。
 
       将复杂逻辑分割为多层, 可能在某种程度上增加系统理解和维护的复杂性, 但有利于分工和团队协作。
         
      三、 细粒度措施
 
       细粒度措施通常是一些基本的方法和要求, 可以借鉴一些常见编程风格, 比如 K&R, Java 编程规范。
       1.  适当的空格, 比如 if (condition) { }  ;  callFunction(arg1, arg2, ..., argN) ;
       2.  适当的空行, 紧密相联的逻辑放在一起, 不紧密相联的逻辑用空行分开;
       3.  一致的缩进, 通常为 4 个空格;
       4.  一致的命名规范, 比如, 对于集合A, 一致使用下划线, 对于集合B, 一致使用驼峰式;
       5.  必要的注释, 对于一些依赖于前提的做法, 要做出注释, 比如, // 目前系统仅支持挂载一个ISO ; 
       6.  必要的引用, 比如, HashMap 的实现基于哈希表, 详见 XXX ;
       7.  遵循习惯用法, 比如,大部分情况使用 for (String elem: elementList) {},少量情况用 for (int i=0; i < len; i++){}
       8.  制定一些约束做法, 比如, 一个函数或方法最好不超过 100 行;              
 
       四、 技术决策
      
       技术决策也常常影响到可维护性。 比如, 你需要动态访问多个数据库, 并且随着业务的发展, 很可能添加更多的数据库配置。 如果采用静态的方式, 在应用启动时读取所有数据库配置, 那么, 当新添数据库配置时, 就不得不重启和发布应用; 而如果采用动态的方式, 在应用启动时读取数据库配置, 并且在新添数据库时发布事件来触发重新读取数据库配置, 就不需要重启和发布应用了, 这无疑是降低了维护成本;
       此外, 在大型互联网公司, 一个系统通常不是孤立的, 它处于一个更大的系统架构中, 常常存在多种决策。 是采用 直接访问业务数据库 ,  还是通过 API 的方式获取 ?  是采用 mysql ,  还是 OTS, ODPS ? 是采用本地服务, 还是云服务?  很多技术决策都会影响应用系统的可维护性。 这些都涉及较大的方面。
       即使是小的决策, 也会影响可维护性。 比如, 目前, 系统只支持挂载同类型的磁盘, 于是你在代码里写死了; 日后, 若要支持挂载不同类型的磁盘, 就可能要修改很多代码。 这就意味着: 对变化敏感。 需要评估: 哪些是变化频繁的,需要寻求更灵活的实现,便于将来扩展? 哪些是稳定的, 可以暂时保持不变?  现有的编程实现依赖于哪些隐含的前提条件?  当这些前提条件变化时, 需要多大的代价来应对这些变化 ?
 
       五、 一致处理
 
       需要提取出应用系统中的技术点并进行一致性处理。 比如, 应用中需要动态访问多个数据库, 需要访问多个外部系统提供的服务, 需要支持并发查询,  参数名、枚举常量放在哪里,  如何处理 JSON 或 XML 的结果, 前端的整体框架, 前端页面或窗口之间的传值, 加载和展示数据模式, 映射的统一管理(比如 0 表示管理员,1 表示普通用户),  前端与后台的交互通信模式, 等。 为所有技术点确立一个良好的解决模式, 将大大简化后续的开发和维护工作。
 
       六、  有效隔离
 
       对于一些特殊模块, 必须进行有效隔离。 比如, 对于全局资源的访问, 最好只保证共享可读; 如果必须写访问的话, 将其抽取到一个 GlobalResourceAccessUtil 的对象中专门进行写访问, 避免分布到系统的各处。
 
       七、  消除重复
 
       重复是可维护性的大敌。 每当意识到需要编写相似的代码时, 就要思考: 是否可以抽取到一处进行管理? 是否可以提供一个更灵活的接口? 比如, 并发查询单个虚机的信息和并发查询多个虚机的信息, 最初只是实现了并发查询单个虚机的接口, 初步的想法是编写新的接口来实现并发查询多个虚机, 分别地维护, 但是, 当查询到虚机后, 后续处理(查询虚机的其它信息,比如获取磁盘\IP等)都是完全一样的。可以将后续处理抽取出来, 供两个接口共享, 又或者, 直接做成一个灵活性更强的接口, 既支持单个虚机的并发查询, 又支持多个虚机的并发查询。
 
      八、 对维护敏感
 
      你还需要对维护工作敏感。 究竟是哪些变更和问题导致你需要进行维护? 为什么这些变更或问题会导致你的应用系统需要随之变更?  是不是原有方案不够彻底, 不够灵活? 还是大环境发生根本变化, 无可避免?  对这些问题进行归纳和总结, 管理这些事项, 可以提高维护效率。
      
       我所遇到的情况主要有如下几种:
          1.   原来的方案不够灵活, 静态配置和读取数据库, 当新添数据库配置时, 不得不重新启动应用和发布;
          2.   数据库域名的IP地址发生变更, 而 JVM 具有 DNS 缓存作用, 导致不得不重新发布;
          3.   数据订正, 手动配置数据库;
          4.   以不正确权限启动应用, 运行一段时间后崩溃, 或者监控报警;
          5.   应用所在的物理机器出问题了;
          6.   应用所在的网络环境、权限系统发生变更;
          7.   编程实现的不仔细和不彻底导致缺陷或重要错误,需要修复;
          8.   应用依赖的外部服务进行了变更发布;  
          9.   新功能的添加;