警钟长鸣
从师哥身上学到的东西：
关于如何解决问题？
1、沟通：有效的沟通，将问题描述清楚，让老师和师哥明白你出了什么问题，给出建议，很多时候一句良言胜过自己摸索很久
2、出现问题由浅入深地debug，首先出现问题排查的顺序应该是先代码，再理论。
在代码找bug的过程中，如果确定你某个程序跑的结果不对，不要再继续试别的，想要“撞大运”指望跑着跑着“自己就好了”是不可能的。解决问题的最好办法就是直面问题本身，解决这个问题。
3、解决问题的过程中，就是控制变量，一步一步来，控制变量是原则，不要急急也没用。体现在各个方面，比如参数固定，测试某个代码块，看是哪部分出了问题。比如从数据本身入手，数据没问题，看模型，是否是模型的问题，再看是否是训练代码的问题。
4、用指标来测试，比如检测某些指标，证明你这个程序是错的，设计loss，acc实验。
之前发现mean(0)的错误的时候用的直接输出某个变量，发现对不上，那肯定是有问题。
5、如果有baseline，运行原来baseline的代码是正确的，但自己改后就不正确了，那么溯源，对着原来的代码进行对照实验。比如用baseline的训练自己的数据集，如果没问题那么就是自己新写的训练有问题。
6、同一个问题能用两种方法实现，同时实现两种方法，互相印证。
这次bug就是通过原来baseline的代码实现了另一种方法，发现和一开始写的第一种方法结果对不上，那么就是一开始写的代码有问题。
7、你需要对自己的代码负责，出了任何问题一定是你来解决，让别人替你debug是一种耻辱。无论出任何问题，一定是你最后解决，一定是你，不要想着推给别人。写的是答辩，也得你来改。
7、Never give up
8、Be positive. Interesting, let’s see what happens.
注意python的缩进！注意python的缩进！注意python的缩进！注意python的缩进！
注意python的缩进！注意python的缩进！注意python的缩进！注意python的缩进！
如果你的时间都放到de一个bug上，那我觉得这实际上是纯粹的浪费，debug的时间永远是浪费了的，不如去打把游戏，所以每次debug都是在浪费生命，你要警惕自己在干什么。
失去的时间不可追回，这次吃大亏了，以后一定要严谨治学，以规格严格的态度对待每一行代码。
养成好的代码习惯，写过的代码一定是对的，至少没有低级的错误。
知来者之可追。
