今天还是在改BUG，使用的是BUG管理系统是禅道，这次在修改BUG的时候，养成了一个好习惯就是把每个BUG所对应的修改的文件与涉及的模块关联了起来。解决的问题是
- 解决好的BUG又被激活了，不知道修改的哪个文件，哪个模块，不能快速定位，这样定位快多了。
- 打包时，可以统计都有哪些模块更新了
我想BUG改完之后，还需要对这一期的BUG进行下总结、统计。有什么好处呢？首先，可以根据功能性、样式区分。
根据严重性与一般性等等几个方面来区分，来看下分析下BUG的分布情况，统计BUG所涉及到的知识点。对发生的BUG进行整体性的分析，来指导今后的编码工作，提前为自己打好预防针。同时，发现自己或公司在知识地图上的
不足，进而找到弥补的方向与目标，自己能力的提升点也就找到了。
（自己想了想，其实这可以纳入到公司的工作流程，毕竟，这是有好处的）
说到知识地图，我们每个人都应该有自己的知识地图，而公司获取也应该有一份知识地图，这是大家共有的知识地图，大家共同去完善，共同去交流、共同去成长。（关于知识地图这方面的东西，我是从《如何高效学习》这本书学到的，这是本非常不错的书，我想以后有了孩子，我应该教他这个的）
然后，就我修改BUG的情况，来谈谈一些想法，首先，有这样一个前提，就是修改的大部分模块我是不熟悉的，基本没有接触过，业务逻辑是不知道的。每修改一个BUG，定位其原因我都需要从头到尾，甚至每个细节都要查看，对，每个细节都要过一遍，按道理说，这是没有必要的，原因就出在所有的业务逻辑放在一个大大的函数里面，我不得不一点点查看，没有业务逻辑层的函数导致理解起来就非常花时间，同时BUG定位，也非常的困难。所以，一直要强调职责明确，职责明确，每个函数就应该干一件事。而系统中充斥着这种大函数，也只有那些对这些大函数了如指掌的人才能快速定位BUG，找到原因所在，然而，人得记忆是有限的，随着时间的流逝，我们对这些大函数也会渐渐淡忘，也会越来越陌生，当有一天我们再看见他们的时候，如果还是掺杂许多业务的话，我们就真不认识他们了。所以说，请写小函数，请写职责明确的函数，程序员何必为难程序员。（有关这些方面的知识我是从《代码整洁之道》《重构 改善既有代码的设计》中学到的）
再说说另一个问题，在修改BUG的过程中，是否有着一个把BUG改好就行了的想法，我想，大部分是这样的，我也这样，毕竟谁也不想因为自己的其他的改动而引入其他的BUG。然而，在改BUG的过程中，我想有一件事还是有必要做的，那就是重构，如果发现了坏味道（此名词见《重构 改善既有代码的设计》）我们就应该将其去除掉，如果你想以后轻松维护他的话。任其烂代码的存在，我们增加了哪些成本：时间成本，我们需要耗时间去理清业务逻辑，工期加长。维护成本，烂代码非常容易引入BUG。况且，修改BUG时，顺便重构，是重构的最佳时间，因为毕竟我们还有测试，在确认BUG的过程中也就同时保证了我们重构的正确性。
今天重构了一个登录错误时，显示错误消息的代码，代码很长，并且在修改密码页面还有完完相同的一套代码。也正好修改一个错误消息提示不合理的BUG，果断就重构了，把这段抽到一个地方，两个地方使用一套代码，瞬间就简单许多了。关于代码，改天再贴吧，想想也是很有意思的。
