不加断点调试的程序员是好程序员
小李看完上一篇文章《先做个"键盘侠"， 再来写程序》以后， 每天晚上下班后回家不再打网游了， 开始苦练打字功夫， 熟记快捷键， 终于可以随心所欲， 双手如飞了。
但是真正下手编程序的时候怎么还是老卡壳呢，尤其是程序出了bug以后， 需要加很多断点， 输出很多变量来观察， 前面看看， 后边改改， 美妙的噼里啪啦键盘声就再也听不到了，严重的影响到了速度。
为什么旁边的小刘拿起圆珠笔一转， 计上心来，又可以接着噼里啪啦的敲键盘呢？ 还有旁边的小王， 把头扬起来想一会儿，马上就能继续了。
小李决定趁吃饭的时候问问小刘。
小李： 兄弟， 你是咋弄的 ？ 这么快就能找到程序的问题？ 你咋不加断点呢？
小刘： 我也不知道啊， 反正我一想， 问题就找的八九不离十了
小李： #￥%%…………&
其实小李的情况在很多程序员身上都存在，他们的共同特征就是在编程过程中， 一出问题就加断点调试， 甚至经常一步一步来， 输出很多变量，仔细观察分析， 看起来很专业， 花了1个小时发现是个if else 写错了， 很多时间都被浪费掉了， 非常可惜。
迅速发现问题并且定位问题所在是区分普通
程序员和优秀程序员的一个重要标志。
怎么样才能迅速定位问题呢？
关键就是： 你的脑子里得建立一个程序运转的模型， 程序要先在你的脑子里运转起来！
再讲个一直让我记忆犹新关于Rob Pike 的故事：
Rob Pike : 是 Unix开发团队成员，Go语言的核心人员
Ken Thompson : 是 Unix 和C 语言 的发明人
“在我加入贝尔实验室一年多后，我开始和Ken Thompson一起在开发一个针对由Gerard Holzmann设计的很小的图形化交换语言的即时编译器上做结对编程
。 我打字比较快，所以我坐在电脑前，Ken站在我身后看我编程。我们开发的很快，但经常会遇到问题，而且可以看出来出错了——毕竟这是一个图形化的编程语 言。当程序出错时，我本能的一头扎进问题，检查报错跟踪信息，添加调试打印语句，启动调试器，等等，但Ken只是站在那思考，完全不理会我也不查看我们写的出问题的代码。一段时间后我发现一个规律，Ken经常会比我先找到问题出在什么地方，而且会突然的喊一嗓子，“我知道什么地方的问题了。”每次他的判断 都很准确。我认识到，Ken已经在脑海里构建了代码的模型，当有问题出现时，那是他脑子里的模型出了问题。在思考为什么会发生这些错误时，他能凭直觉找到模型中什么地方不对或发现写的代码跟这个模型什么地方有出入。”
思考， 不看代码的思考， 是最好的调试方式。
道理很简单， 在大脑里边调试程序远远比你手工做调试要快得多。
添加断点调试， 变量输出其实是不得已而为之， 在你的大脑调试不出来的时候才应该尝试。
各位，我希望你能够经常做这样的练习， 把代码在脑子里运转， 初始阶段先尝试一个函数， 然后是一个单元模块， 然后到一个组件， 等你能把整个系统都在脑子里运转起来， 你就可以做技术总监了 :-)
扫描二维码， 关注 coderising
加入QQ群：135769418 和更多热爱编程的朋友交流