摆脱跳大神的debug

调试《erlang程序设计》构建基于OTP的系统的示例时，在windows下运行shell_for_testing函数死活不成功。

使用appmon:start()看进程树根本就不是示例的状态，好吧臆测sellaprime_supervisor的start_link函数时unlink那个地方的问题。其实不知道发生了什么事，那就姑且假设是环境不支持好了。

在stackOverFlow上搜到似乎有人问类似的问题，三种解决方案。其中一种是用application，好吧，接下来的内容就是使用application配置打包。

结果使用application还是报错，area_server能启动并响应请求，但崩溃后死活不重启。这不就说明监控树失败了嘛！检查了关键的supervisor一百遍，确定init返回的参数结果没有问题。
鼓捣了半天发现prime_server运转正常。就知道又来了，一行一行对，终于在昨晚到今天中午耗了好几个小时的情况下，发现了那个猪一样的bug……area_server的start_link方法我写的是：gen_server:start。正确的应该是gen_server:start_link({local, ?MODULE}, ?MODULE, [], [])。

我擦。没跟父进程关联，死了谁管你啊！！！
OTL真弱智。

其实如果运用解决bug的推理，这个问题不应该拖这么久才解决。因为指向问题点的证据已经很充分了，子服务启动成功，说明supervisor的init没问题。接下来就应该聚焦在子服务本身上，第一时间就应该看对照组的状态，但我没做。最终墨迹了好久，还是运用了对照组。
代码很简单。但两个server对照了半天，还是没发现错误。（我真是够了）
其实重头想想，就知道问题一定是出在area_server:start_link上。一个进程通过父进程启动了，但没在监控树上显示，但又能响应请求，显然是野进程，没关联注册成功啊！！这不就是start_link和start的区别吗？
修复了之后shell中也能启动成功了。windows没有错，错的是我。想也是。OTL。

希望下次能再理智一点，运用推理早点发现问题点。还有快点去死啦这种不谦虚的态度。

反省最近debug的状态。
其实解决问题更多是用直觉，就是以前遇到过问题的积累等。
但学新东西时没有这种直觉，如果有相似可以类比的对象情况还会好些，但在全新的领域，尤其是多个bug重叠时，面对稀奇古怪的错误信息，一无所知的茫然会让我觉得自己和手无寸铁的小孩没啥区别。

这种心理影响下遇到问题很难保持理智与冷静，而心理状态会直接影响解决问题的速度。

盲目自信，不相信自己真会犯那么弱智的错误；
心浮气躁，轻视系统自带提示，不认真看报错信息，只凭经验瞎猜；
急功近利，希望顺顺利利最好没问题，有问题也只有一个或者一下子解决掉。如果不顺利，又开始迷信，觉得什么破玩意根本调不好，怀疑是环境缺陷（其实心里也出现这种情况微乎其微，仔细想初学都最常规的操作，如果有这么明显的bug早修复了），或者不熟悉新规则；
缺乏计划，没做好应付多个bug的准备，同时也不能专注于单一问题点，所有问题一把抓；
这样的状态再丢掉推理，debug大概就只剩下瞎撞运气的成分了。

其实debug就像对数学题求解。已知现象和一些条件，定位bug点。只要心中有计划，按照步骤测试，根据测试结果不断修正方向，就一定能找到引发现象的原因。
debug步骤主要是，假设、验证、排除。范围从大到小，不断地试验，用系统该数据说话，而不是想象。即使错误猜测在验证时也能带来有价值的信息，即使一个小问题也要善于反问总结。还有一点就是要逼自己熟悉报错，克服对英文的不适应。很多时候对英文的不熟悉也增加了对bug信息抵触情绪。

要早点摆脱要靠跳大神的debug。