“再思”

为期两周的硬件课程设计中间跨过了一个六天的国庆假期。放国庆假时，正是我在用verilog写单周期CPU时，整个假期的时间几乎都消耗在了看波形图、调试程序中。这固然让我积累了大量的调试经验，以致后来帮别的同学调试verilog时熟练而又迅速，可以快速定位问题之所在，但值得思考的是，我为何会有那么多的错误，要在调试中花去大量的时间。回过头来再看，其实错误都很明显，无非就是一些细枝末节的问题，这儿变量名写错了，那儿分号忘打了，这儿多复制了点东西，那儿本该按Ctrl+c却按成了Ctrl+x。而这样的问题是很明显的，如果我能仔细的看一遍所有代码，一定可以发现这些问题，而看一遍所有代码所花费的时间，最多只需要几个小时，远远小于调试花去的好几天时间。

为何不愿这样做，而要浪费更多时间呢？这大概是在学C语言时就养成的习惯，代码写完从来不看，直接运行，出错了再调试，用类似逆向的方式寻找问题，而不去重新阅读一遍源码，看看哪写得有问题。这在学C语言时就浪费了很多时间，只是自己没有察觉，这次终于警醒自觉了。
“季文子三思而后行。子闻之，曰：‘再，斯可矣。’”孔子虽不赞成三思才后行，但也说要“再”思。所以我觉得写完程序需要再看一遍，谓之“再思”，看看有没有不合理的地方，有没有“笔误”，这样可以极大的减少错误，节约调试的时间。但也只看一遍，第一遍都没有发现的错误，短时间内重复同样的过程再来一遍也不怎么能发现。不仅仅是写代码，进行设计也是一样，需要“再思”；不仅仅是学习中，一言一行，都当“再思”。在国庆假以后的课设中践行了这一想法，发现“再思”果然可以消除很多错误，极大地减少了用于调试的时间。

这就是本此课设我最大的收获，不是知识技能，也不是经验体会，（当然这些收获也是很宝贵的），而是行为方式的改变——不再等出问题后再逆向寻找问题出在哪，而是一开始就“再思”。