最近在讲课的时候,发现一个新问题,就是许多同学面对着自己写完的代码,蒙圈了。
我是谁?我在哪里?我在做什么?这些代码是怎么出现的?
说来可能难以相信,明明是你自己写出来的代码嘛。
但是,下课之前我说,今天的作业,如何如何要求,格式什么样,标明用了多长时间,然后就有同学在学习群里问我,。。原话记不太清了,大概意思就是,自己写的看不明白了,还得再写一遍呀?
我说,要这样你何止再重写一遍啊,你得反复多写几遍才行。然后跟我说没思路,我说每个功能点,每个函数它们是如何交互、沟通的,我都给你们画思维导图呀,
。。。
。。
如此这般吧。
咱们在课上写代码的时候,能写出来主要有二个因素,
1、我刚讲完,脑子里还有印像;
2、我把代码都写好了,在视频里你们都能照着写;
写完之后,脑子里印象退散,又没有代码参考,思路又不太到位,自然再看自己的代码就蒙圈了。
在我个人看来,咱们前端新人写代码的时候,容易只顾眼前,就是很容易顾头不顾尾。所以写完之后,最好就是从头到尾再检查一遍。如果js运行没有错误,那么就把JS的格式再清理一下,
<!-- -->
那么,回到根本的问题,JS代码怎么读比较适合呢?
写东西之前,
1、分析UI设计图的功能结构;
2、根据功能、结构,理清此模块的交互顺序;
3、把各个交互的元素的id名写好;
4、根据1,2,3,先定好各自的函数方法,还有调用关系;
我又给同学们画了个思维导图,就这样式的,
如果你拿到的,是一个项目文件,并且它的文档不完整的时候,
阅读代码的我个人主观的基本方法:
1、先找入口,起点;
2、找到它定义的地方;
3、把它所有的方法、属性,都列出来;
4、找到它们之间的调用的关系;
5、各个方法之间,传递的参数;
把所有的方法里,用到的所有的参数,
谁跟谁,都理清楚。
6、就开始用中文,
描述各个函数以及它收到或返回的参数的用途。
7、把你的中文描述,再画一个图;
8、用你写出来的“中文文档”,再加上代码结构的图,回过头来,再对照着看代码。
就是,无论多么长的代码,多么复杂的代码,我个人吧,都是这么看,这么读。
尽量不要生生的硬看代码。
遇到bug,一时找不到原因,可以使用排除法,
1、大段的删除代码,查看bug是否消失;
2、不断缩小删除的代码的范围,直到定位bug;
3、排除bug;