工作2年，干了一年ARM平台嵌入式，一年后台，总结下这两年开发中调试的经验。我把调试手段分成2种：打印日志和用工具分析。因为平时主要开发在Linux平台，就以GDB为例
一、打印日志
1. 合理设置日志级别
一般的日志库都会有日志级别，合理使用能避免因线上环境的日志打印过大而导致的磁盘占用过高，搜索日志耗时太长，因为日志大小超过设置值，导致一天打印日志数过多等问题。线上环境的日志一般需要以下级别：
Info，表示业务走到关键点时候的变量信息，队列消费数目，等待处理数目这些用于定位业务是否正常，分析程序性能所需要的指标信息
Warn，正常情况下程序不应该出现这种状态，但不是致命错误
Error，程序异常了，或者已经挂掉了
而测试环境，功能测试时可以把日志设置成Debug级别，最后代码提交时，可以带有Debug级别的日志，但务必保证留下的日志精简，明确。一个精简的调试日志，可以替代大部分函数内注释
2. 善于运用内置的调试宏
c++提供的几个宏：__FILE__ , __FUNCTION__ , __LINE__ 帮助定位代码位置
void Foo(){ //error here Log.Error<<__FUNCTION__<<" is errors in Line["<<__LINE__<<"] varable is "<<var<<endl; }
当然，有的库自带了这些信息
3. 日志划分
多线程下，一个模块可能有多个业务流程。日志划分时最好按照业务，或者模块划分。比如数据库操作的一个日志，和消息中间件通信的一个日志。便于日志归档管理
最后在说下日志精简的问题，第一年做嵌入式开发时，基本上来说，打印日志是唯一的调试方法。每改一次代码，就需要编译，再烧到设备上去看日志信息，所以高效率的日志是非常有助于定位问题的。一个日志需不需要打，我们可以倒过来想，当开发的功能出问题时，我需要哪方面的信息？这些信息中，哪些是必要的，而有了这些信息，我就能定位到问题代码大概在哪里。那么剩下的就是不必要的信息