还记得2013年的时候，那是刚毕业工作。对于软件项目的理解，基本为0。只能做一些简单的软件，对于大型的软件项目，基本上是望尘莫及。

        有一天下午，项目经理叫我过去，说给我一个任务，就是把一个项目罗列的Bug列表的Bug都找到并解决掉。然后我就开始去找了。找了一些时间，然后找到了一些。然后找到项目经理，说bug解决了，就跟他说了那些bug在哪里出的问题，如何解决。

        意外的是，他说我没有找到问题的根本，所以那些bug并没有真正的解决。但是我深信我找到了bug。但是既然项目经理都怎么说了，毕竟他对项目很熟，所以我继续去找。但是他所说的意思，当时我并没有真正明白为什么还没找到。

        后续的几年的开发工作中，慢慢对他的话有了理解。而就在这周，我让我们团队的小伙伴去研究一个项目的代码，让他去学习项目的业务逻辑。而我在让他讲他的了解的内容。结果我不满意，但是他却很肯定的认为，他是对的，而且很有底气的那种。这让我想起了之前项目经理让我找bug的经历。这种感觉透露出一股熟悉的味道，有点意思。

        那我在这里就简单做一个分析吧，供新手参考。

        不管是找Bug，解决问题，还是看代码了解业务逻辑，其实都是差不多的。只不过，找bug更偏重于技术实现，而看代码更偏重于业务逻辑流程。但是根本上是一样的，那就是要深知代码中透露出来的流程，要了解每一个细节，以至于可以全盘掌握。你可以是针对一个功能点的执行流程进行细致的跟踪，也可以是对整个系统模块相关的分工的归类，等等。这些都可以有助于你深入理解项目。

        不过找bug和阅读代码稍微有些区别，我还是单独细说吧。

    1.如何找bug

        Bug是一个程序功能的没有按照预设的流程执行，以至于出现了非预期的结果。Bug可以是功能性错误，也可以是业务性错误。功能性错误可以理解为代码用法错误，导致程序异常，如内存泄漏、程序崩溃等。业务错误则是导致业务没有按照既定的规则运作，可能导致数据错误，进而导致经济损失或者其他问题。

        功能是一个逻辑执行流程。对于bug，可能出现在每一个步骤中。哪样才算找到错误了呢？错误都是可以验证的，大部分错误是可以轻松复现的，少部分错误很难复现。我们在找bug的时候，不是要急着去看代码，而是要先分析错误的现象，将所有错误的现象记录下来。然后分析错误可能出现在功能流程中的哪一步，然后开始看代码。

        对于功能来说，一个流程往往有很多步骤，因为代码写的不严谨，所以错误会不经过检测就直接往后传递了。比如一个数据已经出错了，因为没有检测，就直接往后传递了。后面一连串的步骤处理的结果都是错误的。如果你只是找到了后续的代码，然后用屏蔽错误或者局部修改的方式，只是将错误堵在了某一个步骤，看似解决了问题，实则只是治标不治本。这也就是为什么我那个项目经理会说我没有根本解决问题的原因。因为我只是定位到最后一个步骤，并解决了最后一个步骤的检测与处理。然而问题出现的真正位置，则是在前面的很多个步骤的一个。在第一次出现的位置，就是真正出现的位置，后续的步骤即使做了一些补救但是终究不是根治的方法。说不定此次堵住了一个错误的情况，然后前面的步骤还有可能出现其他的错误情况。

        那么如何验证问题是否根本解决了呢？

        1) 验证修改后现象：将之前出现的现象和修改后运行的现象进行对比，如果正常了，说明有了效果。并且所有现象都要消失。

        2)验证恢复修改后的现象：再将代码恢复原样，再测试运行后的现象是否和之前一样有问题。

        3)验证代码逻辑与错误现象的解释：通过阅读代码逻辑，来解释为什么会出错，修改之后，为什么所有问题都没有了。一定要解释的通，合情合理！！这一点是检验问题是否根本解决的基础。前面两步可能是快速验证问题，但是并不能作为根本问题的解决验证方式。如果能够合情合理的解释问题出现的过程，能够解释代码后问题消失的原理，这样不仅是可以将这个问题解决。而且可能会发现相关的问题，进而可以促进解决更多同类问题。

    2.如何阅读代码了解业务

        在拿到一个项目源码时，如果没有文档资料，那就只能通过阅读代码来了解业务逻辑了。如何阅读代码了解业务逻辑，想必是很多人都要做的。但是很多新手可能总是做不到位，对代码本身的结构可能都会压力山大，对于业务逻辑也是了解的不全面。

        阅读代码就和看散文一样，表面上的几句话似乎都懂了，但是其实那只是懂了语法而已，对于了解业务，还远远不够。比如说，你看到代码里有这样的一段代码逻辑“程序启动的时候，加载了一个配置文件，然后读取了一个列表到一个变量里，然后就启动了”。这一句话的描述就是一个程序上的逻辑。代码是看懂了，代码里描述的就是这么一个流程。然而这样就够了吗？这样就完了吗？如果你只看到这个层面，说明只是看懂了代码，还是不懂业务。

        如何去了解业务规则？通过代码。但是你看了代码就知道代码的流程，又不将代码流程与业务关联起来，那怎么看懂业务流程呢？！这就是说，你要知道程序中每一个变量会代表业务上的某一个方面，每一个程序流程会对应到业务上的某一个流程，要知道变量的不同数值对应到业务的不同的分类。而对于每一个不同的分类或者状态，又是在哪些地方创建、更新、查询和删除的。而这些状态的操作，又是在哪进行的，是自动的还是人工的。如果是人工的，又是在哪里操作的，通过什么方式操作的。

        简单来说，你就是要将代码中的流程映射到业务上，然后将每一个部分的来龙去脉看的清清楚楚。这一句总结看似简单，但是很难做到。对于接手的项目来说，你不知道代码如何写的，不知道代码的结果，不知道代码的设计结构。所以这就会造成一个障碍。好在“熟能生巧”，所以这也不是问题。

        不管是新手还是老鸟，都是需要先将代码结构逻辑都弄清楚，然后才可能细致的了解其中的业务逻辑的。只不过对于老鸟来说，编程基础扎实，再加上项目经验丰富，对于常用的功能的实现方式有了解，所以在看代码的时候，会按照经验里的思路，逐个找到并确认。新手则是在编程基础上很弱，在项目经验上很欠缺，所以新手不知道这个功能会涉及到些什么东西，只是抓到什么是什么，而且还眼见为实，据理力争。反而是老鸟即使看完了全部代码都不一定敢完全担保说自己完全掌握了。毕竟代码是别人写的，很有别人的一些做法自己没有想到，或者一些实现的东西自己有所忽略，所以老鸟反而是更加谦逊。毕竟一时疏忽总是很容易打脸了。当时有多么坚信，打脸后就多么疼。

        那么给新手看代码的建议就是，依照“增-删-改-查”四个大方向和“是什么、为何来、为何去、怎么来、怎么去”五个操作，来逐个确认各个代码。增，即添加、创建。不管是状态、数据、还是流程，万物都有一个开始，这就是增的含义。删则代表删除、消失、隐藏等。改就是修改、更新、设置等。查就是查询、获取、显示等。是什么表示定义，比如变量的含义，代表什么。未何来表示你要做这个东西的渊源，为什么你要做，为什么要添加。为何去即最终要达到一个效果，为什么要这个效果。这是来龙去脉的基础要素。然后就是操作，怎么得了解得到的来龙去脉。

        简单来说，就是要有一个缜密的逻辑思维，对于每一个细节都要清楚的把握，而不是模糊的一笔带过。没有理所应当，没有就是这样。有些系统确实提供了一些基础的条件，但是你要确认你涉及到的条件，确实要是系统提供的，而不是只是你以为。要通过认真的调查研究得到确认的结果。因为不同的系统，实现各不一样，在A系统中一些特性确实提供了，但是在B系统中可能系统没有提供，而是某个开发人员自己定义了一个类似的机制，来支持了你需要的特性。但是这些特性可能还有问题，或许还要你去修改维护，而如果你只是将这个当成是理所应当的系统的支持，那么在出问题时，你就总不会想到这一点去。然而就怪系统怎么怎么垃圾什么的。

        而缜密思维的形成则是慢慢积累出来的，不能一蹴而就。上面给出的建议，则是可以帮助你去形成缜密思维的一个方法。如果直接说答案就是缜密思维，我可以说，绝大部分的新手都无从下手，似乎思维模式就是那样，好像自己也没有办法。所以我提供了一个基本的思考方法，供新手练习学习。