代码检查指南送给面对BUG的时候不知所措的你

Posted 2021-09-04 刘炫320

1. 前言

一直听说真正的工业界，真正的代码量占用了很少的精力，更多的精力都在其他的环节。
50%的精力在讨论、展示自己的想法和思路
20%的精力在造轮子、单元测试
20%的精力在写说明文档
10%的精力在真正写代码

还有100%的精力在改自己发现的BUG，自己没发现的BUG，别人发现的BUG。哎，不对啊，怎么总精力不是100%而是200%？没错，这就是程序员为什么需要经常加班的原因。

那么，当我们在面对程序出现了我们不能理解的BUG的时候，应该怎么办？

下面是几个准则，供大家参考。

2. 充分相信代码和机器

程序员第一要义，要充分相信代码和机器，就像战士相信自己手上拿的东西一样。
遇到最多的情况莫过于：“哎，明明我这样这样做了，为什么电脑不按照我的想法来呢？它总有自己的想法运行。”毫不夸张的说，如果真有电脑可以拥有自己的思想运行代码的，请联系我！

正经点，我们来看看这个问题所在，我们把整个过程分为4个环节。

第一，我们有一个想法
第二，我们把想法实现成了代码
第三，机器运行了实现的代码
第四，出现了预期之外的结果

现在就我而言，出问题的环节按照概率大小排序的话：把想法实现成代码>我们有一个想法>出现了预期之外的结果>机器运行了实现的代码。我优先考虑是我们的实现部分出现了问题，然后是我们的想法不正确，人的错误率是相当高的，而机器出错的概率微乎其微。

以人为本的考虑结果是：“这一定是机器出了问题，我肯定不会出问题的。什么，机器给我报错了，不，一定是机器错了。我不听解释，不听！”

机器可不是人，不会说，先点几下给你提示错误，然后看你不高兴了，再点的时候错误没了。机器能自己修复BUG吗？显然不能啊。

当然，你说，会不会存在机器和代码确实存在物理性的问题。这个不排除有，但是我们一般人遇到的可能性几乎为0。所以当我们遇到BUG时，应该优先考虑我们自己的问题，然后才能够解决这个问题。不然，你会寄希望于机器自己解决这个问题吗？

3. 避免灯下黑

一定要仔细检查那些你一致忽略的地方，80%的BUG都是我们自己的小失误造成的，而不是真的逻辑上有问题。这些小失误可能是命名不规范，重复赋值，引用不正确，多写了个符号，参数忘记传等等，基本上都是在容易想当然的认为这个地方一定会正确的时候，恰恰是我们最难以发现的地方。

4. 问题为导向

当代码出现与预期不符的时候，一定要先去思考，从逻辑上讲，这个应该是什么问题，而不是直接就跳跃到代码上查找。如果不清楚是什么类型的问题，当你面对代码的时候，就很容易无从下手。这就像去医院看病，医生先会问你出现什么症状，然后给你一个大致判断你这是什么病，病因可能来源于哪个部分，然后再根据需要，进行特定部位的检查和分析。没有见过医生等你来到就先给你说，做个全身检查吧，检查完咱再看哪里有问题。

5. 缩小观察视野

当预期不符合的时候，要学会倒推，看一下具体是哪个部分出了问题。不要有跳跃思维，一定要聚焦问题，才能够缩小观察视野，才能够发现问题所在。要把整个过程划分为具体的若干个单元，如果在第n个单元出现了问题，先去看它的前置单元第n-1个单元里哪些部分会影响这个出现问题的部分。然后再看一下是第n-1单元里哪个部分出现了问题，如果定位后，发现是第n-2个单元出了问题，依次往前递推即可。万万不要第n个单元出了问题，就考虑是前面所有单元出了问题，甚至断言是第一个单元除了问题。因为每个单元间的联系可能不止一条两条，所有出现问题的可能性可能早就已经超过了人工检查的能力。

6. 多看官方手册和源代码

问别人虽然能短平快的解决问题，但是多看官方手册和源代码才是最终提升自己能力的正途。因为官方手册是最正式和最正确的指南，从里面可以学习到很多精细化系统化的知识，从而对于整个系统有更清晰的认识。而观看源代码会让你对于思维到实践的映射有一个直观的认识。看完源代码你会恍然大悟：“哦，原来这里是这样实现的，真巧妙。”

你也能够学习到规范的代码风格以及编程思想，从而完成从观察者到参与者的转变。最后你就可以举一反三，真正的将别人的代码变为自己的代码了。这就是为什么面试的时候，别人总喜欢问，你看过源代码吗？因为别人并不是真的想问你源代码的细节，而是看你有没有这个习惯。因为工业开发中，你经常需要看别人的代码。

那么什么时候是问别人更合适呢？

1. 如果问题是比较精细的或者少见的小问题，询问有经验的人会更好一些。
2. 如果这个问题不在你的主流技术栈中，以后大概率也用不到。只是你现在临时碰到，但是需要快速解决的时候。
3. 如果这个问题是比较抽象的，并不能从现有的展示中直接获得答案的，需要高度凝练和总结的时候，可以询问有经验的人。

7. 理解编程思想而不是代码实现

写代码本身并不是非常困难的事情，因为它的本质就是思维的表达。就像是在写英语作文一样。我们写英语作文难在哪？为什么写汉语作文就容易很多？我们不知道要说什么，通常英语作文没有抒情文，也很少有记叙文，都是议论文为主。只要想好论点、论据，构思一下说明思路，只要单词过关，英语作文要比汉语作文容易。

写代码也是一样，只要记住某种语言的语法，本质还是要实现某些功能的思路和想法是什么。在计算机里，这个就是算法的一种体现。算法不仅仅是实现某种特定功能的一串代码集合，而且也是解决某一类问题的特定方法，显然学会后一种的思维方式比形而上的死记硬背一行行代码更加重要。

8. 举个栗子：深度学习模型构建过程中遇到的问题

以深度学习模型学习不到想要的效果，从整体过程上应该作如下考虑:

1. 本身这个问题是否可以被形式化为你执行的代码
   有些问题的解凭借样本是可以被学习解决的，但是有些是不能的。你待观察的特征与学习目标的相关性较小，或者基本上没关系。比如根据拍西瓜的声音、颜色等是可以判断西瓜的成熟度的。这个无论是人还是模型都是可以学习到的。但是你说观察一下西瓜的颜色，判断一下西瓜里包含多少籽，甚至预测一下给这个西瓜的人是男是女。那我觉得这种是无法被人学习到的，也无法被模型学习到。

2. 训练代码/测试代码是否正确
   训练代码是否正确应该检查两个部分，逻辑是否正确和数据处理是否正确。正确与否的判断取决于是否达到了你想要的目的。

   1. 逻辑是否正确
      • 是否按照了你想要的过程进行训练？
      • 训练过程中的参数传递是否没有出现误传、参数是否都已经填写齐全且正确？
      • 是否按照规范的训练流程进行的？如果没有，你的改动有哪些，那些部分会出现问题吗？
   2. 数据处理是否正确
      • 数据被处理成的对象是否合理？
      • 数据的内容和形状是否符合预期？

3. 模型选取是否正确

   1. 是使用别人的模型吗？别人的模型里的参数是否设置正确了？模型的输入是否符合它约定的输入形式？
   2. 如果是自己设计的模型，那么就要看一下自己设计的模型哪部分是移植过来的，哪部分是自己写的，自己写的部分能够保证一定正确吗？有无模型图的展示？

4. 及时反馈，深入思考
   出现问题先搜索一番，说不定有遇到同样问题的。有些时候模型的报错不是特别容易理解，很多时候都是一些编程错误，并不给你指出真正的问题所在，这时候你就需要推断一下。比如说有的说两个向量相加失败，一看定位，是在基础库里的。那显然加法不能出现问题啊，出现问题的只能是两个向量。两个向量为什么会相加失败呢？有一个原因是两个向量的形状不同导致的，那是哪个向量的形状不符合预期呢？这个向量从哪里来的？经过了什么样的处理？通过这样一个逐渐深入的过程，你就能定位到是哪里出现了问题。

9.小结

以上都是在日常调整BUG时遇到的一些小技巧，希望能够帮助我们更好的科研与开发。