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