胡思乱想：关于解bug和写代码的一些感想

本来准备转正答辩PPT来着，一不小心写多了，不舍得丢弃，记录在此：

关于解bug：

这是算是我实习期间最核心的工作，从一开始找缺陷位置都要找半天，到现在看到这个bug就能反应过来其发生机制，并且找到解决办法，这当然不是因为我能够熟悉每一行代码，而是因为我之前解的一个bug跟这个bug是属于同一个组件的，我对这一块儿代码印象特别深刻。

我在解bug的时候，往往先通过抓包并且凭着之前对代码的经验缩小bug可能发生的范围，并最终一步步定位到具体的某个函数、某个变量。这中间很有可能很发生一些“虚晃一枪”的情况，你很怀疑bug的产生是某个变量引起的，结果跟踪了半天发现这个变量在整个流程中根本不起作用。

最终定位到bug发生的点之后，这样就可以开始解决bug了吗，当然不能。与其说是不能，倒不如说是不敢。整个模块那么多代码，你改了这几行，会不会影响其他行呢？而且很多时候bug的这个点会和多个点有联系，你不仅需要改动这几行的代码，还要同步地改动其他地方的几行，不然程序一致性就被破坏了。所以，我找到一个bug发生的点之后，仍是战战兢兢，一定要阅读与其相关的所有流程，在脑中模拟这个bug发生时各个函数与变量的变化，直到确保这个bug在我面前一览无余后，才开始动手修改。

对于大多数业务逻辑相关的bug，修改起来的阻力也同样不是因为这个逻辑真的有多复杂，而是你要考虑这个功能原本的设计是什么样子的，能不能最小化地修改代码就可以解决这个bug？这样可以避免大刀阔斧地更改代码所造成的未知的错误。当然，并不是说最小化的修改原有代码一直是最正确的，当一个功能不得不打上各种补丁，进行各种特判的时候，往往意味着这个功能的设计本来就不合理，应该进行一次小的重构。幸运的是，我还没有发现这样的场景。

关于写代码

这是我实习期间所写代码量最多的一个任务，总共有大概七百多行代码，还有一个UI界面。如果说之前所解决的那些缺陷是打基础的话，这个任务就是让之前全部所学得以应用。我从原先的页面设计偷师，用以设计管理页面的逻辑。

在我之前解决缺陷的过程中，我常常会被有些模块乱七八糟的代码所困扰（每个人都有自己的开发思路，长期累积，合在一起就很乱），所以在我编写这部分代码的时候，总是试图以最少的代码逻辑完成所需功能。对于头文件，尽量使用前置声明，不随便包含其他头文件，减少依赖，提高编译速度。对于整个管理页面的所有功能，包括人员显示、权限提交、下拉框更改权限、批量修改和删除、选择与全选逻辑、添加协作者等等，我都尽量避免代码啰嗦。

可即便是这样，管理页面类也有二十多个函数，总的代码量也差不多七百多行了。我意识到有时候业务逻辑就是这么复杂。那怎么办呢，我的想法是尽量减少各个功能之间的依赖关系，直观上看就是类成员变量尽量少。虽然代码较多，好在我在关键地方都写了一些注释，而且主要代码结构是和其他模块类似的，希望不会给后面维护的开发人员带来太多困扰吧。