谈Web应用系统的可维护性

标签: web 应用 系统 | 发表时间:2013-09-04 02:00 | 作者:shuqin1984
出处:http://blog.csdn.net

 

       每一个软件开发人员都十分清楚, 当软件构建得越来越复杂时, 可维护性就成了一个很突出的问题。 如何在构造软件系统的过程中始终保持可控制的可维护性呢?
 
        一、 整体组织
 
       首先要从整体组织层面进行规划,基本方法是分层和模块化。
       比如, 一般 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 表示普通用户),  前端与后台的交互通信模式, 等。 为所有技术点确立一个良好的解决模式, 将大大简化后续的开发和维护工作。
 
       六、 对维护敏感
 
      你还需要对维护工作敏感。 究竟是哪些变更和问题导致你需要进行维护? 为什么这些变更或问题会导致你的应用系统需要随之变更?  是不是原有方案不够彻底, 不够灵活? 还是大环境发生根本变化, 无可避免?  对这些问题进行归纳和总结, 管理这些事项, 可以提高维护效率。  
     
     我所遇到的情况主要有如下几种:
          1.   原来的方案不够灵活, 静态配置和读取数据库, 当新添数据库配置时, 不得不重新启动应用和发布;
          2.   数据库域名的IP地址发生变更, 而 JVM 具有 DNS 缓存作用, 导致不得不重新发布;
          3.   数据订正, 手动配置数据库;
          4.   以不正确权限启动应用, 运行一段时间后崩溃, 或者监控报警;
          5.   应用所在的物理机器出问题了;
          6.   应用所在的网络环境、权限系统发生变更;
          7.   编程实现的不仔细和不彻底导致缺陷或重要错误,需要修复;
          8.   应用依赖的外部服务进行了变更发布;  
          9.   新功能的添加;    


作者:shuqin1984 发表于2013-9-3 18:00:25 原文链接
阅读:85 评论:0 查看评论

相关 [web 应用 系统] 推荐:

web-scale OLAP系统应用解决方案

- - 冰火岛
为了支持linkedin在线应用“Who’s Viewed My Profile?” 和 “Who’s Viewed This Job?”等等. 构建OLAP 一个可伸缩和快速的serving system called Avatara to solve this many, small cubes problem.

谈Web应用系统的可维护性

- - CSDN博客系统运维推荐文章
       每一个软件开发人员都十分清楚, 当软件构建得越来越复杂时, 可维护性就成了一个很突出的问题. 如何在构造软件系统的过程中始终保持可控制的可维护性呢.         一、 整体组织.        首先要从整体组织层面进行规划,基本方法是分层和模块化.        比如, 一般 Java Web 应用系统会划分为 Controllers - Services - (Dao , Network) - Model - Constants - Utils - Result 等层面和模块.

从 Newsstand 到 Web 应用

- - 爱范儿 · Beats of Bits
本地应用和 HTML5 谁将主导的争论持续了好几年,目前本地应用依然是绝对主流. 因此英国《金融时报》上周宣布将在 6 月 撤下 iPad 应用,完全依赖 HTML5 Web 应用的消息引来不少关注. 早在去年苹果宣布订阅政策时,《金融时报》就开始着手准备 Web 应用以绕开苹果 30% 的大刀.

从 Web 站点到 Web 应用程序,第 1 部分: Web 站点还是 Web 应用程序?

- iworm - IBM developerWorks 中国 : 文档库
您构造的是 Web 站点还是 Web 应用程序. 一般来说,Web 站点主要提供信息,而 Web 应用程序互动性更强,但二者的界限已越来越模糊. 构造好的站点的最佳实践与构造好的应用程序的最佳实践不尽相同. 通过本文了解 Web 站点与 Web 应用程序之间真实确切的差异,然后分析您自己的站点. 以一种能帮助您改进设计和可用性的方式探索您正在管理、设计、编码的站点.

Java Web应用Web层异步化应该考虑的问题

- - 企业架构 - ITeye博客
        之前做了一个项目,要用到web层的异步化技术,在实际实现中,遇到了很多问题,作为教训简单罗列下. 1、app 容器/J2EE框架对异步的支持.         在tomcat5、jboss4的时候,每一个请求都用了一个app容器线程来执行,app线程必须一直处理完或者等待别的线程处理完,才能拿着请求的链接把结果写回到客户端.

Web开发者必备:Web应用检查清单

- - ITeye博客
想做一个高质量的Web应用,前前后后要做的事情非常多. 国外开发者 Ata Sasmaz 为 Web 开发者制作分享了一份检查清单,包括应用开发、性能、安全、分析、可用性、可靠性、转换策略、竞争策略这些方面需要注意的事项. 清单内容可能不全面,欢迎大家在评论中补充. JavaScript 允许捕获异常.

基于HT for Web的Web SCADA工控移动应用

- - ITeye博客
最近客户采用 HT for Web图形界面组件,实现了油田燃气管网和供水管网等工控SCADA的HMI人机界面,并将系统运行在平板和手机等Android和iOS移动终端,在此我们在技术支持过程中的一些知识点进行些梳理和分享,希望对有志于Web SCADA领域的伙伴们提供些帮助. 移动终端呈现方面,HMI界面布局应用和游戏领域有类似的问题,一般对横版或者竖版会有更好的布局效果,例如有些游戏只支持横版的玩法,这对于采用Native的App应用来说不成问题,可将App配置成只能横向或者纵向布局,但对于移动终端浏览器就有点尴尬,目前大部分终端你是不能限制用户旋转平面导致布局变化.

优秀的WEB应用程序

- DayuLu - 互联网的那点事
今天我们将分享给大家一批优秀的WEB应用程序. 比如,大家可能用过在线的调色工具,Adobe也推出过在线的Photoshop软件. 这些程序或许就是未来软件程序的基础. 随着云处理和网络速度的飞速发展,这将是个好的趋势. 人们只需要一台在线的电脑就可以找到需要的应用程序,而不需要在自己电脑上安装复杂的文件.

Web应用程序的开发步骤

- xxg - 月光博客
  如今已进入了web2.0高速发展的互联网时代,各种互联网的Web应用程序如雨后春笋般出现. 那么作为一名Web开发人员,怎样去开发一款优秀的Web应用程序呢. 这个问题没有一个简单的答案,甚至那些教育机构都未必能清楚的知道. 所以,像大多数在这个领域里的web开发人员一样,我们只是通过去做,去实验才学会了这些.

提升 web 应用程序的性能

- pathfinder - IBM developerWorks 中国 : 文档库
作为 web 用户,我们知道页面加载或刷新的速度对其成功至关重要. 本文将帮助您更好地理解影响 web 应用程序性能的因素. 学习识别这些问题并且找到客户端内容的瓶颈. 探索 JavaScript、DOM、CSS 和 Dojo 小部件的性能问题. 将通过一个例子展示使用 YSlow 和 Firebug 适当调整 Dojo 小部件.