深度优先和广度优先遍历的联想

今天老蔡去面试游戏服务端开发,面试官问了很多问题,中间有一个问题是让我总结深度优先和广度优先的区别。

我觉得,这个东西理解跟表达是两码事。之前我写搜索引擎的时候,碰到过这样的问题,url的深度与广度的遍历对搜索引擎内容质量会有很大的影响。所以以此举例说明了一下。

然后后来面试官问了一下老蔡最能描述清楚的项目,老蔡就是说的这个搜索引擎的实现了。

老蔡的描述方式是喜欢从头说到尾,遇到一些细节的实现过程也讲的很详细。面试官表示他对具体实现暂时不关心,然后让我先把整个项目的构架先描述一下。

然后我描述着描述着,就一不小心又纠结在一个具体功能的实现上讲起来了。

面试官显得很无赖,然后告诉我了我这个习惯的缺点:会纠结于一个小问题的实现,耽误比较多的时间。在实际开发中,也会因为这个习惯导致开发效率的降低。

当时觉得有道理,就记下了,后来回来路上琢磨着琢磨着,就明白了:这个问题完全可以用遍历的两种方法来解释了。

老蔡一直习惯一个人编程,每个问题都需要自己独自解决,所以遇到一个问题,就解决一个问题,养成了这样的习惯,并导致遇到问题后,会耽误,或者说花掉大量时间在学习和研究这个问题的解决方案上,属于深度优先遍历

团队编程时,先列出大致实现的接口,然后分头实现,属于广度优先遍历。而团队编程还有附带的好处:碰到一个不熟的问题,别人或许经历过,并且可以在比你短很多的时间内解决,这样,碰到棘手的问题后,先略过,并保留接口,留给其他人实现,会让开发效率更高,同样属于广度优先遍历

回来跟朋友聊天时,他说他们公司的BU分派MR给他的时候,总说实现起来很简单,但是其实做起来不知道有多麻烦,我于是跟他开玩笑说,他分发任务给你的时候,属于广度优先遍历,并且只用关心第一层,你自己实现的时候,属于深度优先遍历,所以难度和描述的差别可想而知了。

虽然今天虽然往返接近4个小时的车程奔波劳累,但是却有了意想不到的收获。