应用系统的可维护性主要表现在三点：
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. 新功能的添加；
转载请注明出处。谢谢！ 🙂