增强debug能力来提升工做效率

以个人观点来看：作出一个业务功能是件很简单的事，作好则有难度，高效的作好则是难上加难。抛开前期的架构设计、技术方案的制定不谈，单单是写好代码这一阶段就给咱们每一个人带来了不一样程度的挑战。以前还写过一篇关于代码编写阶段的文章《提升工做效率的工具“类”》，下面我就主要从代码debug的角度来谈谈个人见解。

---

• 尽可能写代码时避免bug，减小调试
  对于任何问题，先以预防为主。在团队中经常能够碰见这样的同事，代码写的很是快，但是天马行空的代码以后却让本身陷入了无尽debug的沼泽。我会给这样的同事建议：多花点时间作好代码结构的设计，写代码时常常进行review，另外就是老生常谈的细心。

• 利用好IDE和工具
  经常听到这样的见解，用vim，emacs的看不起用IDE的，以为vim..就是银弹，无论什么语言，什么平台只要你问他什么IDE最好，他必定回答你vim..。固然不排除有能把vim..用的出神入化的人，其余的大多数是在装X吧。你要记住，你的目标是完成工做，不是显示本身多高端，多牛X。gdb同理。合适的IDE有不少好处：错误提示、代码补全、丰富的替换查找、各类关联跳转，固然若是你不嫌麻烦，不怕不许确也能够对vim进行配置来实现相同的效果，但请先看看这篇文章再作决定《编辑器与IDE》,以上几个IDE带来的好处不正好对咱们上面提的“尽可能避免bug”有很正面的意义嘛。另外，IDE集成的debug界面友好也强大（用过gdb的朋友确定知道），断点，step over，step into，内存变量，调用堆栈...简直就是debug神器，至少我写程序读程序的标准步骤就是依靠这几步。(说点夸张的，可是我还确实遇到了很多人包括一些不少年工做经验的工程师居然从没有用过断点调试，彻底靠着printf行走江湖，个人“惊讶”如滔滔江水啊...)，在调试中其余工具的使用也可使debug事半功倍，好比内存泄露的检测工具，还有进行网络编程时的各类工具（wirshark，netcat，tcpdump...)

• 程序输出日志
  我认为日志系统也应该是一个程序的标准组成部分。其最大用处就是帮助咱们来梳理程序行为，准肯定位bug。有些朋友要问了，我能够用IDE来调试观察啊，问题是不少bug并非在你写代码测试时发现的，是在发布以后的用户那里，傻眼了吧？还有很重要的一点，多线程问题、还有一些依赖于具体系统环境或时间环境的问题是很难复现的，此次抓不住你就等着一直提心吊胆吧。我在工做中一直使用Apache的log4X系列，又一个强大的神器。但在有些环境下用不了log4X，好比在有些对程序所占空间大小很敏感的的嵌入式环境（log4cxx的动态库较大），你彻底能够本身利用标准输出封装相应的日志系统，而后运行时作好定向输出工做就好。

• 崩溃转储
  崩溃这种fatal级的大bug最让咱们头疼，在C/C++中十有八九是内存违例（段错误）形成的。这种bug和多线程问题同样也是最难找的，因此咱们必定要尽量的准肯定位抓住它，最有效的办法就是利用内存转储文件。在linux平台下开启这个选项后利用gdb core就能够进行定位分析。windows平台下较麻烦，得本身实现内存转储功能，推荐你们一个工具类mini_dump,一旦程序崩溃就会产生dump文件，以后使用windbg调试便可。

• google
  不少bug本身想了各类办法也定位不了或者没法fix，这时你就得请教google大神了。尽可能别用百度，若是中文搜索条目不多或没有，换成英文搜索，也许会有更多的收获。

• 问
  我给个人团队成员提了这么一个建议：若是一个问题你本身尝试了，也google了，可是没法解决。一旦超过一个小时耗在这个问题上请大胆的寻求外部帮助吧，问团队中经验较丰富的成员，也许他曾经遇到过，也许他会给你提供好的建议或者思路。

• 深刻学习
  其实这点排在最前面比较合适，先去深刻学习再去作相应的工做。可是咱们实际工做中偏偏相反，每每是遇到了问题再去深刻学习，我以为不少bug的造成是咱们对知识的只知其一;不知其二甚至一无所知形成的，咱们要尽可能抛弃那种临时抱佛脚式的学习，而是要在本身的职业生涯中持续不断学习，深刻学习。

以上就是我对提升debug能力的一些见解和实践。