从软件维护中学习

最近刚接手一个大牛开发的软件，但是在我手上就是跑的不畅快，频频出现问题。

经过一个多星期的源码学习和故障排查，在郁闷和纠结的心态中思考：一个好的软件或者说方便维护的软件应该具备什么样的气质

首先，如果这个程序要保证7*24小时运作，那在升级、重启的时候就要做到顺利切换多台服务器。在重启任一台机器的时候，其他机器都能抗住流量，保证服务正常提供。

其次，不会丢失数据，即便是机器挂了，也能恢复。如果程序突然停止，或者需要升级重启，但还是有数据还没有处理完，必须有方法在恢复后继续处理。

例如把一个程序分成两部分：A和B，A程序接受用户请求，发送给B程序处理 ——

user ->A ->B.

A可能接了很多用户的请求，B需要成批处理。程序突然中止了，或要重启了，那B就有可能没处理完数据。

一个可行的办法就是把要待处理的数据都写到文件，B程序通过读这个文件输入。

A.sh > data.time

B.sh < data.time

这样，无论在什么时候宕机了都还有记录可查，在程序重启后，可以手工或自动去读取待处理的数据文件。

第三，只提供核心接口，降低影响力。

为了加快开发速度，为了少造一些轮子，一个程序依赖的程序越来越多，也被越来越多的程序依赖。但我认为，一个软件跟人一样，做好核心的功能即可，其他的接口应该尽量少的开放，被他人依赖的越多，除了证明这个软件的功能强大之外，也带来了维护的成本。

这个图是这样发展的：A程序在开发过程中需要一个B功能，顺手就开发了B接口。后来发现B在其他程序中(A3 \A4)也用的到，导致越来越多的程序依赖A。

如果有一天B出了故障，但不影响A的主要功能，A1、A2都能正常工作。但要修复B的话，A必须重新发布，那样A1，A2都会被牵连。

所以，最好的办法也是最简单的办法，就是把B从A中分离出去，各自管好自己的一亩三分地。

第四， 日志里的错误信息要有帮助。log里除了记录stack track，还应该有当时的参数，错误信息的整理、归纳，方便快速定位问题。要不然除了知道是这还代码出问题之外，不知道是在什么样的情况下出的这个问题，bug无法重现。

————————————————————————————————————————————————————————————

ps： 不要轻易地相信人家。调用别人的接口注意时判断是否正确返回，exception是否全部catch。

这次遇到的是中文乱码问题，原因是线上和线下测试环境不一致，悲催的我过了一星期才知道，白忙活了一星期。

 …