日志输出法则
来源:互联网 发布:javaweb考勤系统源码 编辑:程序博客网 时间:2024/06/02 01:26
本文转载自 鱼木博客,如有侵权,请留言,本人将删除。
日志输出法则
运行日志应用场景
原型迭代过程
该场景下,一定需要日志输出。原因很显然,因为是个迭代过程,整体结构模型并不明确,一些逻辑都不是很可靠的,故需要提供一个侧面可供观察程序运行动态。
二次开发
二次开发一般也是采用一种原型来迭代完成的。即便不是基于原型迭代变化,那日志观察则更是需要,至少依赖平台的一些调用我们需要观察。程序员一般对于不是自己定义的逻辑都是不能完全信任的。除非有可靠评测数据。
对于有单元测试的依赖项
有单元测试,那就是说有可信可靠的评测数据。对于这部分依赖项,同二次开发说明的,那我们只管应用层逻辑的日志输出即可,而最好能够屏蔽这些可靠依赖项的输出。因为的单元测试保证,所以我们不希望依赖项内部输出而膨胀我人瓣观察范围。
输出法则
日志作为程序运行的内侧面,是写给人员看的,不同形式输出日志给程序员的体验就不一样。因此我们需要一种规范日志,流程清晰,以观测某些关键信息。以下总结了三条规则以定义我们的开发过程。
流程日志
什么时候需要流程日志,这看函数块的对其他块的依赖性;
最简法则就是,发生某调用前,对于调用函数名及入参有较关键的日志记录。
出口日志
说到这里了,流程日志只关注对别的函数调用的发生记录。那么出口日志就是关注本函数块目标输出;
最简法则就是,函数返回前,对本函数的返回值及出参作比较关键的日志记录。
一个古老的问题真算解答了,结构化设计有一则单入单出的模块设计原则。这就是为什么尽量要求单出口,方便跟踪记录!
入口日志
又到了这里说明了,既然有出口日志自然考虑入口也打印个记录了。莫急莫慌!这一条是有讲究的。
不对外提供的函数模块,不要产生入口日志。为什么,因为有流程日志作前置声明的,所有上下文流程会在日志里体现的一清二楚。
最简法则就是,导出与其他工程目标调用的函数块作好入参的关键记录。
那个模块设计原则,一个入口一个出口。在函数体上下文中,入口始终都是唯一一个。我只能嘿嘿了!
结果
有了流程日志和出口日志作保障,我们就能很方便观察程序运行的上下文出入了。
对于以上三项法则有个前提注明,一条日志记录,最基本需要有时间戳,函数名这些信息,有了函数名我们才能清晰的看出完整的流程运作!
遵循此规范来执行迭代开发,程序设计的好不好,就很明显的能够在日志输出中反映了。设计良好则可以从日志体现出流程清晰、层次分明的特点。
工程操作
这里的工程只讲说代码工程。每一个工程由若干编译单元组成,同时包含一些依赖项。
工程目标
可执行文件
应用程序及应用程序扩展。
静态库
完成目标链接所需的依赖项。
工程组
这里要说就涉及到功能目标及人员分工相关。
一般会按不同功能划分工程目标,然后再分组管理不同的开发人员,即组织不同的团队完成不同的开发目标。
平台
应用
- 日志输出法则
- 日志输出
- 日志输出
- 永远吃不胖的法则 - Qzone日志
- log4net输出xml日志
- Restlet 输出日志说明
- tomcat 日志输出
- Restlet 输出日志说明
- jboss日志输出设置
- jboss日志输出设置
- 用log4j输出日志
- ACE 输出日志
- Log4j日志输出详细
- Xorg 如何输出日志
- Android日志输出
- Android日志输出、单元测试
- Android日志输出、单元测试
- 错误日志输出
- 程序员生存定律
- 常用系统配置和资源管理
- AES Java加密 C#解密 (128-ECB加密模式)
- HttpClient使用
- 软件工程课程设计问题总结——医院门诊系统(六):datetime timestamp 和String
- 日志输出法则
- 3991: [SDOI2015]寻宝游戏
- 【Docker容器的跨主机访问】-【使用网桥实现跨主机容器连接】
- C/C++·函数指针
- 欢迎使用CSDN-markdown编辑器
- vi命令修改文件及保存的使用方法
- 打开Xcode9 beta之后Xcode8.3.3模拟器消失不见了
- java中 Object转换成 int 类型。
- makefile下$^,$@,$?,$<,$(@D),$(@F)定义使用详解