日志的重要性

一个项目除了服务版本或数据库模型版本跟前台不对应以外.剩下的问题就是前台或者后台服务编码的问题.前者的情况通常比较容易发现和解决.
要解决后者的问题.我的建议是前台后台建立统一的日志规范.出了问题,首先看日志.别老想着推卸责任.
前台:记录访问后台服务的句柄,通常是一个服务的标识和一个服务名称,为了安全起见.给后台的服务类和方法都边上编码,比如EmailServce (srv-1),send(Message msg)(m-1).然后再加上一个时间戳,起码精确到秒.然后前台调用这个服务的时候就打印:
2015-10-27 9:02:10 srv-1 m-1
等等我调用前台的哪个方法才打印了这个.如果很多前台的地方都调用这个服务,我怎么区分?
好吧,把前台调用的地方也打印一下,我觉得应该打印一下前台的这个调用方法或者事件的所在文件的路径,然后就是这个方法或者事件的名称,这个打印了也不会造成安全问题,因为srv-1,谁知道是啥?.于是有了:
2015-10-27 9:02:9 com.xxx.EmailAction sendEmailClickHandler
2015-10-27 9:02:10 srv-1 m-1
一旦出了问题,我就知道,我是操作了前台的哪个类的哪个方法或者事件,调用了后台的那个服务的哪个方法.
等等.srv-1到底是啥,这个就需要前后台有个统一的规范了.
比如后台的程序员写这个服务的时候,可以把服务先按模块进行一个规则的编码,比如有10个模块,就编码0-9,然后里面的个方法,我都从0依次编码.srv表示服务,m-1表示方法
然后给出一个定位的api,格式如下:
srv-0 m0 m1…..
srv-1 m0 m1….
编码的方式任意组合创造,只是为了定位.
这个文档只有程序员之间可以看.于是前台程序员根据这个对比查找.最终知道自己前台的操作调用了后台的那个服务的那个方法. 告诉后台程序员,嘿,你的xxx服务xxx方法报错了.

这个时候写后台的去找到这个方法……

再等等,我咋知道这个方法报了啥错.
这个时候后台服务员也可以再这个服务方法里面写上一点日志
如果这个服务和方法是这样的:
public class Service{
public void send(T t) {

} 

}
我首先可以去把方法名打印出来,然后把参数的值给打印出来,(java可以重写model的toString方法做到.前台可不敢赤裸裸的显示数据啊.) 这是一个INFO级别的日志.写在方法体的最前面.看起来是这样的:
2015-10-27 9:02:11 com.xxx.Service.send(T t) t = {a = 1,b=2……}

接下来,方法开始运行逻辑,各种调用…..咯噔,出现异常了.服务器会自动记录这个异常的日志.这个日志就比较复杂了,时间,然后是异常的方法调用堆栈.例如:
信息: XML validation disabled
([localhost].[/o3] 3714) Error configuring application listener of class com.o3eie.util.SessionEventListener
java.lang.Error: Unresolved compilation problems:
The import javax.servlet.ServletContext cannot be resolved
The import javax.servlet.http.HttpSession cannot be resolved
The import javax.servlet.http.HttpSessionEvent cannot be resolved
The import javax.servlet.http.HttpSessionListener cannot be resolved
HttpSessionListener cannot be resolved to a type
ServletContext cannot be resolved to a type
HttpSessionEvent cannot be resolved to a type
HttpSession cannot be resolved to a type
……此处省略N+1个字

这个时候,后台程序员就可以分析问题了.首先看数据是不是预先想要的.如果数据没有问题.就根据跟踪堆栈看看是哪个地方抛的异常

等等,如果是多个服务,多个方法再一个方法里被调用呢? 答案是所有服务方法被调用的时候都打印一个日志.

然后看看哪些没有打印,哪些打印了,再结合跟踪堆栈大概就能定位是那个方法环节出现问题.然后进一步看看是什么导致的.基本上都可以找出问题.

好了到这里找到问题的效率应该是比较高了,也比较安全.方法就是统一一个日志规范.
如果统一了日志规范之后,甚至可以做一个专门管理日志的应用,更方便查找和管理.

出了问题,如果是前台的数据不对,后台就叫前台改.如果是后台服务写的不对,就后台改服务.别纠结,也别推卸责任.日志记录的一清二楚.

这个建议如何,也许很多公司只能表示无奈吧.