58ee3d6d55fbb2fb185bb7ff4e4a20a44723dcef.jpg
调试从哪里来？
调试被称之为“黑客之瞳”，程序的对错通常都不是证明出来的，而是需要我们去观测验证的。调试是程序员的工具，帮助我们发现、解决程序问题。在什么情况下，我们会需要调试呢？这里可以把调试分为两个点：
- 发现问题
- 解决问题
怎么有效率地进行调试
1.出问题了，消息是否可靠？
通常，我们是在知道程序有问题以后才去调试。从这里开始，我们得到了关于程序出错的信息。这个信息可能是测试人员告诉你的，也可能是用户告诉你的，因此第一步是确认这个信息。也许会急着自己重现这个问题，其实我们不用这么急躁，我们需要先判定这个信息来源是否可靠。如果认为是真，那么就跟着这个假设往下走，不浪费时间亲自重现错误。
2.定位问题，是否需要验证问题？
如果代码你非常熟悉，而且有把握预测写下的代码会有什么行为，那么直接修改问题就完了。对于熟悉的代码，应该最起码能够预期代码行为，并且经过profile等等测试，才能成为合格。
3.如果定位困难，但是很熟悉代码
可以动手调试，数据断点、查看内存、代码断点、日志、转储文件、查看汇编代码、抓网络包这些方法都是你的好朋友。
- 代码断点大家肯定很熟悉，这里讲一个数据断点的例子。有一次我发现别人的代码中出现了内存泄漏，虽然我对他的代码不是非常熟悉，但我作为框架设计者，很快就了解具体代码。然后我跟踪单个泄漏对象的生命周期，就是通过对他的引用计数进行数据断点，每次增加引用与释放引用都看得一清二楚，最终发现其实是一个很隐晦的，在Lua中重写了父类释放引用计数导致的。
- 查看内存有时候作用也很大，比如说在使用google protobuf中遇到bug，直接人肉decode来得更快。
4.如果代码不熟悉，那么用二分法
最简单粗暴，直接注释某些功能，直到筛选出问题代码。看上去很慢，其实很快就能发现问题。
5.如果连业务都不熟悉
或许应该让别人去解决，如果一定要解决，那么请从设计开始了解，不要马上就钻入代码里面，否则很危险，而且浪费时间。也许重写也是一个好方法。
- 比如我发现cocos2d-x v3.x字体模块很糟糕，于是去看看怎么解决问题，但是字体逻辑却不是很了解，但团队又需要你去做，那么我就只要从字体的排版设计上去学习，花了半天看完freetype的设计思路。不久之后重写整个模块，不仅把原来字体特效的问题解决，而且整个字体模块只需要2m内存就满足整个游戏的字体需求。
问题之外再问问自己
- 问题是什么？用户的期望与实际的差异有哪些？
- 为什么会有这次问题？是数据结构设计得不好吗？是数据与显示没有分离吗？
- 这是谁的问题？谁认为是问题？
