2015-7-1 记而随，随而记

 

今天仍是在改BUG，使用的是BUG管理系统是禅道，此次在修改BUG的时候，养成了一个好习惯就是把每一个BUG所对应的修改的文件与涉及的模块关联了起来。解决的问题是

1. 解决好的BUG又被激活了，不知道修改的哪一个文件，哪一个模块，不能快速定位，这样定位快多了。
2. 打包时，能够统计都有哪些模块更新了

 

我想BUG改完以后，还须要对这一期的BUG进行下总结、统计。有什么好处呢？首先，能够根据功能性、样式区分。

根据严重性与通常性等等几个方面来区分，来看下分析下BUG的分布状况，统计BUG所涉及到的知识点。对发生的BUG进行总体性的分析，来指导从此的编码工做，提早为本身打好预防针。同时，发现本身或公司在知识地图上的

不足，进而找到弥补的方向与目标，本身能力的提高点也就找到了。

（本身想了想，其实这能够归入到公司的工做流程，毕竟，这是有好处的）

 

说到知识地图，咱们每一个人都应该有本身的知识地图，而公司获取也应该有一份知识地图，这是你们共有的知识地图，你们共同去完善，共同去交流、共同去成长。（关于知识地图这方面的东西，我是从《如何高效学习》这本书学到的，这是本很是不错的书，我想之后有了孩子，我应该教他这个的）

 

而后，就我修改BUG的状况，来谈谈一些想法，首先，有这样一个前提，就是修改的大部分模块我是不熟悉的，基本没有接触过，业务逻辑是不知道的。每修改一个BUG，定位其缘由我都须要从头至尾，甚至每一个细节都要查看，对，每一个细节都要过一遍，按道理说，这是没有必要的，缘由就出在全部的业务逻辑放在一个大大的函数里面，我不得不一点点查看，没有业务逻辑层的函数致使理解起来就很是花时间，同时BUG定位，也很是的困难。因此，一直要强调职责明确，职责明确，每一个函数就应该干一件事。而系统中充斥着这种大函数，也只有那些对这些大函数了如指掌的人才能快速定位BUG，找到缘由所在，然而，人得记忆是有限的，随着时间的流逝，咱们对这些大函数也会渐渐淡忘，也会愈来愈陌生，当有一天咱们再看见他们的时候，若是仍是掺杂许多业务的话，咱们就真不认识他们了。因此说，请写小函数，请写职责明确的函数，程序员何须为难程序员。（有关这些方面的知识我是从《代码整洁之道》《重构 改善既有代码的设计》中学到的）

 

再说说另外一个问题，在修改BUG的过程当中，是否有着一个把BUG改好就好了的想法，我想，大部分是这样的，我也这样，毕竟谁也不想由于本身的其余的改动而引入其余的BUG。然而，在改BUG的过程当中，我想有一件事仍是有必要作的，那就是重构，若是发现了坏味道（此名词见《重构 改善既有代码的设计》）咱们就应该将其去除掉，若是你想之后轻松维护他的话。任其烂代码的存在，咱们增长了哪些成本：时间成本，咱们须要耗时间去理清业务逻辑，工期加长。维护成本，烂代码很是容易引入BUG。何况，修改BUG时，顺便重构，是重构的最佳时间，由于毕竟咱们还有测试，在确认BUG的过程当中也就同时保证了咱们重构的正确性。

 

今天重构了一个登陆错误时，显示错误消息的代码，代码很长，而且在修改密码页面还有完完相同的一套代码。也正好修改一个错误消息提示不合理的BUG，果断就重构了，把这段抽到一个地方，两个地方使用一套代码，瞬间就简单许多了。关于代码，改天再贴吧，想一想也是颇有意思的。