不像发达国家，我们现在还在处在软件开荒时期，不断在开发着新的软件。但随着软件已经成为各行各业中的重要的基础设施，我觉得软件维护这个话题将变得越来越重要。
据统计，可能80%的维护人员都不是以前的开发人员。所以，软件维护首要面临的是对当前软件系统的理解，这次我就这个话题说一下我自己的理解。目前只能想到几点，希望大家能够补充。
那么应该从哪几方面来理解呢？我觉得主要是理解业务，理解依赖，理解架构，理解设计，理解代码，理解Hot Spot。
1）理解业务。
问题1：这个系统是干什么的？ 功能
问题2：谁使用这个系统？ 角色
问题3：主要流程是怎么样的？流程，一般用泳道图
问题4：有哪些主要概念？glossary，词汇表
问题5：概念和概念之间的关系？概念模型，领域模型。
问题6：业务所涉及的专业知识有哪些？ 可以找专业知识学习，比如理解财务系统需要会计知识。
2）理解架构。
问题1：逻辑上系统是如何组织的？逻辑架构
问题2：系统主要用了哪几种技术？技术架构
问题3：系统如何部署的？部署架构
3）理解依赖。
问题1：系统依赖外部哪些系统？
问题2：系统被哪些系统所依赖？
一般用系统用例图表示。
4）理解设计。
问题1：数据库是如何设计的？ER模型。
问题2：主要有哪些模块组成？概要设计。
问题3：模块之间的关系？概要设计。
对遗留系统，设计文档一般是过时的，过时的文档就像鸡肋。
5）理解代码。
问题1：有哪些主要类？
问题2：有哪些主要接口？
问题3：继承层次？
问题4：关系？（关联，组合，聚合）
问题5：职责？类的职责？接口的职责？
问题6：依赖？依赖哪些包（组件层次），依赖哪些类（类层次）
问题7：单元测试？有吗，跑跑看，单元测试是一个很好的视角，我阅读Spring的源码就是从单元测试开始。
6）理解插座上的孔。
问题1：业务上，系统本身可以满足哪些扩展？ 比如可以通过配置，支持新的功能
问题2：技术上，可以满足哪些扩展？比如可以继承哪些类，实现对新功能的支持。
标记这些Hot spot（热点），使你对系统的可预见性有充分了解。
7）理解你想要做的。
问题1：本次修改，主要是对哪些业务的修改？
问题2：本次修改，会影响到哪些模块？
问题3：本次修改，要修改哪些类？
问题4：本次修改，会影响哪些类？
问题5：本次修改，会修改哪些方法，有什么影响？
问题6：到底要不要改？
问题7：修改哪些文件？配置文件，.java文件，数据库等。最好列出checklist。
总之一句话：就是尽可能的获取信息。
简单把上面的总结一下，就认清需要 （了解你想要的，到底想改什么），然后外面看看 （系统角色，外部系统依赖，架构，概念模型），里面看看 （类图，依赖关系，调用关系，数据库表，配置文件），到处摸摸 （试用一下功能，跑一下单元测试，debug一下）。