心得与吐槽——十天痛苦调试的总结

    最近十天在改两个需求，是在别人的代码基础上进行的修改，是在一个和公司之前框架上进行的修改，是在一个完全不熟悉业务以及设计的系统上进行的修改，是在测试环境都不确定是否正确上的修改，这四个“是”注定这十天的痛苦。

    这些日子是很痛苦，但是还是学到了不少东西，比如调试的方法、做事的方法等等。也许人生是公平的，承受了痛苦，然后才会有所收获。其实说“痛苦”这个词有点言过其实，有些矫情与夸张，感觉这个东西都是主观的，带有情绪的，而在调试的时候，主观的东西往往会给自己带来很大的麻烦。

    还有要感谢所有给我帮助的人，王总、郝工、赵工、王哥……没有这些人的帮助，我现在还在痛苦着……

    废话太多了，切入正题。

************以上是抒情部分，对此不感兴趣的可以略过，以下是正文*************

    1、程序里没有什么是小问题。

    我这两块里最终的解决都在“小”问题上，一个是一个字段的true和false的选择上，另一个是一个字段（标识状态）的设值上，还都是原来写程序的人帮我看出来的。程序里任何问题都是大问题，尤其是在应用系统中（说尤其是因为我现在只做过应用系统），一个字段的设置不同，其业务含义就天壤之别。现在当别人问我一个东西什么时候能做完，总是很心虚，主要原因是我水平不够，经验不足，另一个不可忽视的原因就是最近一段日子认识到的这种小问题引发大毛病的现象。

    2、开始编程调试之前，一定要搭好环境。

    这条看上去有废话的嫌疑，但是却也是我痛苦的原因之一。开始给了一个环境，我也没多问，搭起来后直接编码、调试。可是越到后面，麻烦越大。经常调试到某个地方的时候，看不到源码，跟不到具体的错误出在哪。更有甚者，有时候干脆环境中的方法直接挂掉。这在你本来心情就不好的情况下，简直就是雪上加霜。磨刀不误砍柴工，古之人不余欺也！

    3、需求、业务是绝对不可以轻视的。

    这两个东西的重要性在这十天之前就已经领教到了。   

    需求一定要尽可能地去了解。有的时候是客户的需求，这个是很难控制的，因为客户有时候也不知道自己需要的是什么，这个只能循序渐进了。还有的时候则是设计者的“需求”，去编码实现之前，某个字段的含义必须搞清楚，否则有自己哭的时候。

    业务，只从我做的应用系统来说，重要性不言而喻。相信大家都知道因为对于程序意味着什么，只是我之前的认识程度不够，写在这里算是给自己提个醒。

    4、请教，真的很重要。

    我一直是个喜欢自己去研究的人。有时会弄出一些东西，但有时也会进入死角。一个人知道的毕竟还是少的，也许有的人不懂程序怎么写的，但是知道数据库的结构，知道某个字段代表什么意义。还有更多时候，是自己不懂得如何写方法，调接口或是搭建环境，这时候更需要问，尤其是用公司自己的框架，而且又没有一个良好的文档的时候。

    5、抱怨对调试没有丝毫的作用。

    有的时候会对程序走某个方法而没有另一个方法而恼火，有时会因为环境报错而生气，还有时会因为某个自认为正确的方法异常而愤怒，这时候通常会头脑发热，然后更没法调试了。“当程序出错时，一定要承认自己错了”，然后尽量静下心来。

    6、最重要的一条……

    不要以为自己写了这些东西，以后就不会再犯同样的错误了；不要以为自己貌似懂的一点东西，就万事大吉了，代码要一行一行写，程序要一步一步调。

    异常总会有的。重要的是，出现之后是不是能吸取以前的教训，然后静下心来，踏实地一步步调试下去。

    好吧，这条同样是我用来提醒自己的。