说到功能和体验,正好昨天就软件的日志功能说过一串话,现在赶紧整理总结一下
一个软件,没有日志功能,也能用
但是,如果有偶尔的异常现象,则不好跟踪,因为人不可能老盯着,而盯着的时候它也不一定就会重现
所以,需要日志功能,日志是一直写的,事后分析日志,按发生时间定位日志,还是可以接受的
写日志又有2种,1种是编译出2个版本,一个是不写日志的发布版,一个是写日志的调试版
这种,需要跟踪时,需要更换程序版本,才能进行,不需要跟踪了,又需要更换程序版本
1种做法是程序支持一个选项,以此决定是否写日志
这个选项是重新运行才生效还是运行时都可以随时切换,又是2种做法了
而且,日志是关注对象是不是可以分级(错误、关键事件、普通事件、调试信息等),又是一个方面的做法了
但是日志文件的输出方式,又有很多做法:每次输出一个不同的日志文件,还是连续输出到一个相同的日志文件
前者会导致小日志文件非常多,后者比较整洁,但是写的过程会复杂一些
如果是后者,就还有一个附加问题:日志文件很大了怎么办?
应该规定到一定大小就换个文件,这里又有2种做法了:大小限制固定为一个数(如100k);大小限制也是通过配置决定
当然,后者这个配置似乎没有必要运行时调整了
每100k换文件了,单个日志文件的大小不会无限大了,但是文件的个数又会无限的多了(如果日志写的频繁的话)
所以,又需要一个功能:每天把当天的日志转移到一个压缩文件(以日期为文件名)
当然,如果每天一个日志压缩文件还嫌杂乱的话,可以每月一个日志压缩文件,或者每次运行结束生成一个日志压缩文件
所以,写应用的,没有写内核、底层那么高深,但是,它的软件功能和用户体验,也还是无止境的,不应该那么受轻视。。。。。。。。。
同时,也说明写软件是一件多么靠程序员积极性的事情。
除非你能把这些“精深”的需求都写清楚了,否则就完全靠程序员的积极性、良心了
国内的软件项目,(数量上的)大多数应该都不可能把需求预先写的这么“精深”吧,除非是外包
如果领导不能完全信任、放手,那么就准备好把需求预先写的这么“精深”吧
这些事情(功能的“精深”程度的确定),本来也许是项目经理、架构师的事情,
但是国内的实际情况往往是落到程序员的头上,尤其是第一次需要这样的功能的时候
用一个决策树来表达,就是:
软件的日志功能
├没有日志:如果有偶尔的异常现象,则不好跟踪,因为人不可能老盯着,而盯着的时候它也不一定就会重现
└有日志:日志是一直写的,事后分析日志,按发生时间定位日志,还是可以接受的
├|编译出2个版本,一个是不写日志的发布版,一个是写日志的调试版:需要跟踪时,需要更换程序版本,才能进
│|行,不需要跟踪了,又需要更换程序版本
├程序支持一个选项,以此决定是否写日志
│├如何切换
││├重新运行才生效
││└运行时都可以随时切换
│└日志是否分级
│ ├日志对象不分级:要写都记,要不写就都不记
│ └日志分级(错误、关键事件、普通事件、调试信息等):可以通过设置决定记哪些
└日志文件的实现
├每次输出一个不同的日志文件:会导致小日志文件非常多
└连续输出到一个相同的日志文件:比较整洁,但是写的过程会复杂一些
├日志文件很大了怎么办?:规定到一定大小就换个文件
│├大小限制固定为一个数(如100k)
│└大小限制也是通过配置决定:这个配置似乎没有必要运行时调整了
└是否每天/或月把当天/或月的日志转移到一个压缩文件(以日期为文件名)