对系统可维护性的理解

软件系统的大部分成本并不是在最初的开发阶段，而是在于整个生命周期内持续的投入，这包括维护和缺陷修复，监控系统来保持正常运行，故障排查、适配新平台、搭配新场景、技术缺陷的完善以及增加新功能，以及后续同学对系统的维护等，基本上可以分为以下三个方面，软件可维护性（软件可维护性侧重于代码的可维护性）、系统可维护性（系统可维护性侧重于系统后续的运维）以及系统可扩展性（对增量变更的快速支持）。

软件可维护性

技术架构一般解决的是系统的并发性、可用性、一致性、稳定性、安全性等一系列问题，可以参考https://blog.csdn.net/maoyeqiu/article/details/124053993

而业务架构解决的是可维护性、可扩展性、可复用性等一系列问题，虽然这些词经常挂在嘴边但理解程度和可操作性并不高，希望通过一系列的学习总结能够加深这方面理解。

首先是第一个词“维护性”，与可维护性相关的是“可理解性”或者“代码可读性”。直观上理解：系统架构设计简单，接口简洁，表数据关系清晰；老人离职，新人接手，无需很长时间就能厘清代码逻辑；系统功能不耦合，改一个地方不会牵动全身；系统某些模块即使时间久远，也有人能厘清内部逻辑；或者可根据修复一个问题所花的平均时间和修复正确的百分比来衡量。

影响维护性的有四个方面，一是个人的理解能力，二是对项目代码的熟悉程度，理解能力越强，越不容易觉得维护成本高；对项目越熟悉，哪怕是屎山代码，也会觉得重构后可维护性并不会提高；三是业务本身的复杂度，业务本身越复杂，维护成本就会越高，因为信息量不可避免的增大；四是代码质量和文档，代码质量体现了技术对业务的抽象，抽象的好，复杂度曲线就会比较贴合业务真实复杂度，抽象的不好。

因此如果是提高系统的可维护性就从代码质量和文档能力入手，如果是想要提高自己对系统的维护能力就要提高自己的理解力、硬啃代码和熟悉业务。为了提高系统可维护性，代码上需要做哪些工作呢？

第一，代码一定要有注释，特别是关于if esle，每个条件到底意味这什么，一定要有清晰的描述，开发人员在写代码时，必须认识到，代码不是给你看的，是给维护人员看的，如果你的代码没有注释，一会让维护人员疯狂；

第二，清晰的系统结构和命名规范，如果当看到一个页面或者按钮，维护人员可以立即定位到相关的java方法或者存储过程，可以加快错误定位的速度，提高维护的效率。

第三，千万不要写无用的debug信息，在第一条强调中一定要写注释，因为有总比没有强，但是一些debug信息，有跟没有都一样，不但浪费维护人员时间，甚至给出错误的引导。一定要在关键的地方加上debug信息，方便维护人员遇到问题，能查看相关的信息，便于定位问题原因。

第四，友好的错误提示信息，友好的错误提示信息，可以帮助用户自己找原因，自己维护系统。

第五，完善的系统配置管理，在项目开始之后，就需要进行，直到项目结束之后，维护工作中，仍然需要不断更新系统配置信息。按模块对系统进行配置项的划分，对系统每次维护工作，都进行记录，留待将来检查

第六，系统版本管理，保证系统生产环境能找出对应的版本库中的源代码

系统可维护性

有人认为，“良好的操作经常可以化解软件的局限性，而不规范的操作则可以轻松击垮软件。”，因此对于系统层面的维护，能够：提供对系统运行时行为和内部的可观测行，方便监控。支持自动化，与标准工具集成。无状态设计，避免绑定特定的机器，这样在整个系统不间断运行的同时，允许机器停机维护。提供良好的文档和易于理解的操作模式，诸如“如果我做了X，会发生Y”。提供良好的默认配置，且允许管理员在需要时方便的修改默认值。尝试自我修复，在需要时让管理员手动控制系统状态。行为可预测，减少意外发生。其核心是可监控、可排查和可修复。

系统的可维护性还可以从设计的层面继续深化，如简化系统复杂度、让系统变得容易改变，这个层面的内容可以从系统的可扩展性的层面考虑。

系统可扩展性

这是一个非常复杂的课题，后续再专门开一片文章总结一下。

参考：

https://juejin.cn/post/7017611136455409695
https://zhuanlan.zhihu.com/p/336242688
https://www.zhihu.com/question/354121319
https://www.cnblogs.com/ymym/p/12495943.html
https://blog.csdn.net/weixin_44997802/article/details/109840158
http://blog.itpub.net/24722484/viewspace-1051471/