日志
调试随想
热度 1 |
昨天晚上等软件编译完成, 写了一个日志, 结果网络系统备份, 不能提交, 而且不能退回到原来状态. 系统的设计者粗心大意, 就会惹来用户的满腹牢骚.
好在这不是什么惊天地泣鬼神的大作, 我再写一遍就是.
最简单的调试手段-运行看现象
适合最简单的功能, 比如继电器开合, LED闪烁. 没有额外的调试手段的情况下,只能这样调试. 最早期的先驱者这样开发程序的, 但是一旦有更好的调试手段应该抦弃对这种手段的依赖.
稍为进步一点的手段-打印中间结果+文本log
比如某函数:
int funcA(int a, int b);
没有获得预期中的结果, 程序员可以再funcA的函数体中增加中间结果的打印. 这种方式需要额外添加代码, 另外需要一个文本输出界面. 纯逻辑/算法的程序可以使用这种调试方法,但是对时序要求严格的代码, 如无线通信协议,PID控制则需要增添log,在事后查看. 即使这样也需要在原代码的基础上额外增加输出函数, 对原程序的影响不可避免.
最后是输出接口, 串口是最常用的. 但是串口较慢,且串口经常需要被用作其他用途. 建议在有条件的情况下尽量使用其它接口, 如SWO, RTT, USB等等.
更进一步的手段-单步调试
代表作有GDB, 一步步解析程序运行的轨迹, 在任何一个时间点停下来查看关心的变量/内存/状态.
比较理想的手段-单步调试+GUI
增加了GUI, 打断点,查看变量/内存/状态的效率大大增强了. 而效率就是程序员最为看重的要点.
土豪级的手段-线程级别事件触发+指令跟踪+纪录
这种手段需要土豪们出手购买昂贵的仪器, 但是如果承受的起这种价格的话, 最好是不要省这个钱.
不管多好的调试手段, 不能代替程序员本身的思考, 经验. 更不是说买了壕贵的调试设备就意味着bug自动消失了. 聪明的程序员会利用起这些有利条件, 更好更快地完成任务, 然后直奔下一个任务.
不管大公司小公司的程序员, 归根结底就是要追求效率, 更快的将软件质量提升到一个预期的可接受的水平. 意味着少接班,少操心,少在发布后应对各种难堪的局面.
