现在会读很多代码,小组同事写的、API、框架等,在这个问题上,感触颇深。
在读到一个主要逻辑的时候,如果它调用其它地方的方法,后面的处理要使用这个方法返回的数据。通常代码都相当多的,也不会在短时间内就能理解所有的逻辑。这时候我就会很困惑:根据调用的方法名称大概理解下概念,继续往下面读代码?还是点进去,看那个方法里面到底是什么?
如果那段代码里面还有很多外部调用,那更会面临更多的困惑。
难道这不是一个“深度优先”与“广度优先”的问题吗?
深度优先:遇到外部调用方法,点进去看它里面的处理逻辑,等看完,返回到主代码继续;
广度优先:先不管它里面怎么实现的,继续看后面的代码,等把主体代码理解通透后,再回头看每个模块的深层实现。
在经历过几次像这样的抉择后,再结合下实际的效果,我选择“广度优先”。
很可能在遇到这样调用其它地方代码的逻辑时,在没有搞清楚这部分代码做什么,产生什么样数据之前,往下读会越来越吃力。但等把外面的那段代码理解明白后,可能就不知道调用处的逻辑了,我经常会碰到这些的问题。
只好先根据命名和逻辑揣测下它的实现和返回的数据,再继续往下看,等这个架构比较清楚了,再回过头来看具体每块的逻辑。
尤其在使用spring时,会有很多外部的代理调用,等你每个都想看明白后,就不知道原调用处在做什么了。
更多的可能是我的大脑缓存不够吧。
在读到一个主要逻辑的时候,如果它调用其它地方的方法,后面的处理要使用这个方法返回的数据。通常代码都相当多的,也不会在短时间内就能理解所有的逻辑。这时候我就会很困惑:根据调用的方法名称大概理解下概念,继续往下面读代码?还是点进去,看那个方法里面到底是什么?
如果那段代码里面还有很多外部调用,那更会面临更多的困惑。
难道这不是一个“深度优先”与“广度优先”的问题吗?
深度优先:遇到外部调用方法,点进去看它里面的处理逻辑,等看完,返回到主代码继续;
广度优先:先不管它里面怎么实现的,继续看后面的代码,等把主体代码理解通透后,再回头看每个模块的深层实现。
在经历过几次像这样的抉择后,再结合下实际的效果,我选择“广度优先”。
很可能在遇到这样调用其它地方代码的逻辑时,在没有搞清楚这部分代码做什么,产生什么样数据之前,往下读会越来越吃力。但等把外面的那段代码理解明白后,可能就不知道调用处的逻辑了,我经常会碰到这些的问题。
只好先根据命名和逻辑揣测下它的实现和返回的数据,再继续往下看,等这个架构比较清楚了,再回过头来看具体每块的逻辑。
尤其在使用spring时,会有很多外部的代理调用,等你每个都想看明白后,就不知道原调用处在做什么了。
更多的可能是我的大脑缓存不够吧。