读代码的“深度优先”与“广度优先”问题

现在会读很多代码，小组同事写的、API、框架等，在这个问题上，感触颇深。

在读到一个主要逻辑的时候，如果它调用其它地方的方法，后面的处理要使用这个方法返回的数据。通常代码都相当多的，也不会在短时间内就能理解所有的逻辑。这时候我就会很困惑：根据调用的方法名称大概理解下概念，继续往下面读代码？还是点进去，看那个方法里面到底是什么？

如果那段代码里面还有很多外部调用，那更会面临更多的困惑。

难道这不是一个“深度优先”与“广度优先”的问题吗？

深度优先：遇到外部调用方法，点进去看它里面的处理逻辑，等看完，返回到主代码继续；
广度优先：先不管它里面怎么实现的，继续看后面的代码，等把主体代码理解通透后，再回头看每个模块的深层实现。

在经历过几次像这样的抉择后，再结合下实际的效果，我选择“广度优先”。

很可能在遇到这样调用其它地方代码的逻辑时，在没有搞清楚这部分代码做什么，产生什么样数据之前，往下读会越来越吃力。但等把外面的那段代码理解明白后，可能就不知道调用处的逻辑了，我经常会碰到这些的问题。

只好先根据命名和逻辑揣测下它的实现和返回的数据，再继续往下看，等这个架构比较清楚了，再回过头来看具体每块的逻辑。

尤其在使用spring时，会有很多外部的代理调用，等你每个都想看明白后，就不知道原调用处在做什么了。

更多的可能是我的大脑缓存不够吧。

评论

3 楼 u013146595 2018-02-02  

楼主你人呢，搬家了吗。还想看你的文章

2 楼 cry615 2013-12-03  

广度优先可以站在宏观的角度，可能更有效率些！

1 楼 oolala 2011-09-30  

广度优先其实是为了更好的理解业务流程，把业务流程理解了，再理解有些小的业务流程