“再思”

  • 2016-10-22
  • 97
  • 0

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

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

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

评论

还没有任何评论,你来说两句吧