我今天所讲的不是如何构建日志系统，也不想过多的纠结于应该使用何种日志工具，何种日志框架，而是从一个设计者或者用户组的角度来看待日志系统的。
我不是一个经验丰富的人，但是，每个项目都会将日志系统作为一个系统/项目最为基础的模块/部分。这是毋庸置疑的，特别是对于我们这些经验不咋地的
程序员来讲。
一、程序员的日志
当我们处在程序员的时段时，我们发现自己是多么的菜鸟，是多么的无知。可是这就是过程，在这个过程中，我们不断的在自学，在向前辈们讨教经验，这
段时期是程序员的成长期，而在这期间，我们发现，一个好的日志系统对于这类的人是多么的重要。
当一个新手进入这个世界时，只知道System.out来看自己是哪里错了，我就见到并自己经历了这样的事情，我们当时也已经知道log4j这类的东西了，但是
我们没有去使用它的经验与想法，我们自己固执的一直System.out着，一次次的，一行行的在输出每一个字段，每一个变量，每一个返回值，每一个循环。我们
看到自己的输出界面是多么的杂乱，但最终的结果是：我们可能需要System.out几十甚至上百行，并跨越不知多少个方法，类，才能找到一个Exception,甚至
在没有try…catch的function中，我们只能干等着问题的出现。
并不是说一个新手，特别是像我们自己这类人就一定是没有思维，没有逻辑的，只是我们没有去尝试解决这样的僵局。直到我们真正意识到“记录”这两个字
知道我们发现了debug，直到我们真正决定使用log4j，知道我们被一个用户问道，这个问题是哪行代码出现的问题。
工具永远都是帮助于人的，日志不光在维护，同时也在程序员。特别是像我这种新手、菜鸟的阶段。我觉得，我们需要一种“记录”的想法来教育和提醒我们去
做到如何是后期，如何是维护。也许只有我们在真正体会到“维护”的时候，我们才会意识到日志对于我们是多么的重要。哪怕是一个复杂的庞大的文件，或者数据库
的值。
二、用户的日志
用户永远不想也不应该知道我们程序的运行，他/她们可没有功夫来扯这些，一出现问题，只想知道结果，过程与实现是他/她们所不关心的。
这点是我们都应该去面对的。毕竟，我们也是一种“服务”行业。呵呵…
用户看到的日志可以是一部分我们程序处理过的通俗易懂的文字，或者提示。特别是对于系统管理员来讲，跟他/她们罗嗦这数据库日志系统显然不是特别现实的。
把用户那边的IT太当回事了也不好。界面永远是用来呈现的，用户的日志就在里面，哪怕是给他现实登录失败，也别来个error,或者Exception，这恐怕会让他们疯掉的
同时，这也是给我们软件服务提供商的一个要求。
有部分的软件系统都会自带日志系统的界面显示，这些内容一部分来自数据库存储，比如一般的系统都会有用户登录、注销日志的，这我们一般都会选择在数据库存储，毕竟这类数据可以是安全级别的，有时候还是需要永久保存。然而内容的另外一部分是来自文件了，但是文件的好处是可以读取方便，也方便存储，现在存储技术那么
发达，数据文件的大小已然不是问题。然而，这种文件方式也会有时候造成文件丢失的，有时候由于人为因素，从安全角度考虑，一般都很难控制与预料到，不过相对于
数据库的方式，这种显然更适应目前社会市场的便利性要求，这也是我们很多都选择文件方式保存日志的原因之一吧。
界面永远是用户的直接体验方式，页面日志的现实也比较多样化，可以是实时的现实，也可以是按时间段来显示。
三、系统设计的日志
项目/软件在需求与设计的时候，很多设计人员都会将日志设计其中，并作为最后的设计，因为，日志的内容范围可以说完全依照需求来定，当然，设计者也完全可以
只注重基本日志的考虑了，这完全依照个人。我觉得日志系统的重复性可以说是很大的，至少基本的是可以的。不过在系统设计初期，除了侧重数据库的操作日志，也可以
适当的放宽范围，是的程序开发人员能更好的掌握开发时的处理方式，与日志系统的结合。所以我觉得，日志可以放在需求设计后期来进行最终的设计，并且这需要和程序
开发人员达到完整的统一，毕竟，真正的维护与执行者还是这些辛苦的程序开发人员们。设计者也应该将日志的详细设计与程序开发人员讨论并达成共识。
我只是一名很菜的开发人员。我只想记录我们自己的积累，未来的路很长，我们慢慢走…
