软件功能和用户体验

说到功能和体验，正好昨天就软件的日志功能说过一串话，现在赶紧整理总结一下

一个软件，没有日志功能，也能用
但是，如果有偶尔的异常现象，则不好跟踪，因为人不可能老盯着，而盯着的时候它也不一定就会重现
所以，需要日志功能，日志是一直写的，事后分析日志，按发生时间定位日志，还是可以接受的
写日志又有2种，1种是编译出2个版本，一个是不写日志的发布版，一个是写日志的调试版
这种，需要跟踪时，需要更换程序版本，才能进行，不需要跟踪了，又需要更换程序版本
1种做法是程序支持一个选项，以此决定是否写日志
这个选项是重新运行才生效还是运行时都可以随时切换，又是2种做法了
而且，日志是关注对象是不是可以分级（错误、关键事件、普通事件、调试信息等），又是一个方面的做法了
但是日志文件的输出方式，又有很多做法：每次输出一个不同的日志文件，还是连续输出到一个相同的日志文件
前者会导致小日志文件非常多，后者比较整洁，但是写的过程会复杂一些
如果是后者，就还有一个附加问题：日志文件很大了怎么办？
应该规定到一定大小就换个文件，这里又有2种做法了：大小限制固定为一个数（如100k）；大小限制也是通过配置决定
当然，后者这个配置似乎没有必要运行时调整了
每100k换文件了，单个日志文件的大小不会无限大了，但是文件的个数又会无限的多了（如果日志写的频繁的话）
所以，又需要一个功能：每天把当天的日志转移到一个压缩文件（以日期为文件名）
当然，如果每天一个日志压缩文件还嫌杂乱的话，可以每月一个日志压缩文件，或者每次运行结束生成一个日志压缩文件

所以，写应用的，没有写内核、底层那么高深，但是，它的软件功能和用户体验，也还是无止境的，不应该那么受轻视。。。。。。。。。

同时，也说明写软件是一件多么靠程序员积极性的事情。
除非你能把这些“精深”的需求都写清楚了，否则就完全靠程序员的积极性、良心了
国内的软件项目，（数量上的）大多数应该都不可能把需求预先写的这么“精深”吧，除非是外包
如果领导不能完全信任、放手，那么就准备好把需求预先写的这么“精深”吧

这些事情（功能的“精深”程度的确定），本来也许是项目经理、架构师的事情，
但是国内的实际情况往往是落到程序员的头上，尤其是第一次需要这样的功能的时候

用一个决策树来表达，就是：

软件的日志功能
├没有日志：如果有偶尔的异常现象，则不好跟踪，因为人不可能老盯着，而盯着的时候它也不一定就会重现
└有日志：日志是一直写的，事后分析日志，按发生时间定位日志，还是可以接受的
├|编译出2个版本，一个是不写日志的发布版，一个是写日志的调试版：需要跟踪时，需要更换程序版本，才能进
│|行，不需要跟踪了，又需要更换程序版本
├程序支持一个选项，以此决定是否写日志
│├如何切换
││├重新运行才生效
││└运行时都可以随时切换
│└日志是否分级
│ ├日志对象不分级：要写都记，要不写就都不记
│ └日志分级（错误、关键事件、普通事件、调试信息等）：可以通过设置决定记哪些
└日志文件的实现
├每次输出一个不同的日志文件：会导致小日志文件非常多
└连续输出到一个相同的日志文件：比较整洁，但是写的过程会复杂一些
├日志文件很大了怎么办？：规定到一定大小就换个文件
│├大小限制固定为一个数（如100k）
│└大小限制也是通过配置决定：这个配置似乎没有必要运行时调整了
└是否每天/或月把当天/或月的日志转移到一个压缩文件（以日期为文件名）