运行日志应用场景
原型迭代过程
该场景下，一定需要日志输出。原因很显然，因为是个迭代过程，整体结构模型并不明确，一些逻辑都不是很可靠的，故需要提供一个侧面可供观察程序运行动态。
二次开发
二次开发一般也是采用一种原型来迭代完成的。即便不是基于原型迭代变化，那日志观察则更是需要，至少依赖平台的一些调用我们需要观察。程序员一般对于不是自己定义的逻辑都是不能完全信任的。除非有可靠评测数据。
对于有单元测试的依赖项
有单元测试，那就是说有可信可靠的评测数据。对于这部分依赖项，同二次开发说明的，那我们只管应用层逻辑的日志输出即可，而最好能够屏蔽这些可靠依赖项的输出。因为的单元测试保证，所以我们不希望依赖项内部输出而膨胀我人瓣观察范围。
输出法则
日志作为程序运行的内侧面，是写给人员看的，不同形式输出日志给程序员的体验就不一样。因此我们需要一种规范日志，流程清晰，以观测某些关键信息。以下总结了三条规则以定义我们的开发过程。
流程日志
什么时候需要流程日志，这看函数块的对其他块的依赖性；
最简法则就是，发生某调用前，对于调用函数名及入参有较关键的日志记录。
出口日志
说到这里了，流程日志只关注对别的函数调用的发生记录。那么出口日志就是关注本函数块目标输出；
最简法则就是，函数返回前，对本函数的返回值及出参作比较关键的日志记录。
一个古老的问题真算解答了，结构化设计有一则单入单出的模块设计原则。这就是为什么尽量要求单出口，方便跟踪记录！
入口日志
又到了这里说明了，既然有出口日志自然考虑入口也打印个记录了。莫急莫慌！这一条是有讲究的。
不对外提供的函数模块，不要产生入口日志。为什么，因为有流程日志作前置声明的，所有上下文流程会在日志里体现的一清二楚。
最简法则就是，导出与其他工程目标调用的函数块作好入参的关键记录。
那个模块设计原则，一个入口一个出口。在函数体上下文中，入口始终都是唯一一个。我只能嘿嘿了！
结果
有了流程日志和出口日志作保障，我们就能很方便观察程序运行的上下文出入了。
对于以上三项法则有个前提注明，一条日志记录，最基本需要有时间戳，函数名这些信息，有了函数名我们才能清晰的看出完整的流程运作！
遵循此规范来执行迭代开发，程序设计的好不好，就很明显的能够在日志输出中反映了。设计良好则可以从日志体现出流程清晰、层次分明的特点。
工程操作
这里的工程只讲说代码工程。每一个工程由若干编译单元组成，同时包含一些依赖项。
工程目标
可执行文件
应用程序及应用程序扩展。
静态库
完成目标链接所需的依赖项。
工程组
这里要说就涉及到功能目标及人员分工相关。
一般会按不同功能划分工程目标，然后再分组管理不同的开发人员，即组织不同的团队完成不同的开发目标。