这是一年多前的一封我写给部门的内部邮件，现在拿出来分享下

Hi，all

我一直在强调“有战斗力的team”，也一直在强调各种流程，比如对于bug的修复流程，我一直主张尽量利用JIRA对bug的整个生命周期进行管理，尤其是截图、comment、work log、commit和code review，但是在推行过程中遇到了一些阻力。其它有关“耗费时间精力”、“太繁琐”于我而言都不是理由，我认为真正的问题在于1、大家对流程的好处没有深刻的体会；2、没有sample去参照去学习

对于comment，我们的JIRA里有一些是“已修复”，大部分没有任何comment，而真的利用comment进行交流的很少。可能大家更习惯于线下交流，但我想说的是，线下交流固然方便、省时间，但是对于一个团队的积累是没有太大好处的，比如，应该没人能告诉我这个快两年前的bug的原因是什么，又是怎么解决的：（略）。另一点，在一个remote的team里，是没有办法进行实时的线下沟通的，能够依靠的就只有bug tracer里的comment和各种记录，这一点大家可以随便找一个开源项目，去bugzilla、jira里翻翻就知道了。对于这样的项目，开发人员变化很快，用户量很大，只有详细的bug记录才能保证1、整个项目尤其是bug的生命周期是可追溯和可分析的；2、对于开发、测试、用户都能很好地利用之前的记录判断一个新bug是否duplicated，是否与已有的bug相关。而有些比较极端的开源项目，在你新建bug之前是必须进行搜索操作的，确保你将要提的bug在一定程度上是“新的”，从而避免浪费开发人员排查的时间；3、对于新加入团队的开发和测试人员，只需要花点时间就能对之前项目的bug情况有个大致的了解，也能给之后的bug修复和测试提供一些方向性的指导

在这一点上，我们刚刚起步，需要时间去打磨和积累

以下分享一个今天刚修完的bug，展示一个“我（在之前的team中）习惯的bug处理方式”。相关链接：（略）

1、这个bug在我3/28接手时和曹明做过基本的沟通，大致了解了bug的情况。但是由于之后一直没腾出时间，所以有近一个月的时间没有处理，等今天我想处理时，发现对之前沟通的内容已经完全没有了印象，于是要求曹明将之前的情况添加到comment中：

（略），在此感谢曹明的comment写得很详细，我们之后没有进行任何二次沟通

2、看到comment后我便开始看相关代码，并很快定位到了原因。此时我完全可以直接进行修复、提交测试，但我还是按照自己的习惯将详细原因记录了下来，并附上了截图：（略）。随后加了个comment给了解决方案：（略），并给出了不同方案的对比。最后，记录了30分钟的work log：（略）

3、大概6点半开始进行修复，也就花了十几分钟，然后在本地进行了测试并通过，同时附上了线上数据清理的SQL：（略）。此时我也可以直接标记resolved并提交测试，但是觉得这个bug的测试需要进行数据库操作，相对麻烦，于是给了相应的数据筛选SQL和造数据的方法，并给了相应的截图证明“我的确修复了”：（略）。然后提交代码，新建code review，标记resolved并记录一个小时的work log。做了这些事情，花了我大约半个小时的时间，我的想法很简单：1、测试方式、修复截图我都提供了，之后的验证过程QA应该不会再来问我，不会打断我之后的时间，我也就不用再花时间去回忆今天的修复过程、相关SQL，然后向QA讲解；2、上线文档中需要的SQL我也提供了，之后QA在写验收报告时也不需要来打断我我的时间。总之，看似我花了十几分钟修复一个bug，却花了更多的时间去写一些“额外”的信息。我的收益在于，正常情况下我之后的时间不会再被与这个bug相关的任何事务打断，QA的验证工作也应该会因为这些comment简化不少。我多花了半个小时的时间，但避免了之后的时间碎片，同时缩短了QA的验证时间，整体上来讲是相当划算的。最重要的，即使两年之后，根据这些comment以及提交的相关代码，任何一个开发、测试人员都可以很方便地恢复今天的场景，了解这个bug的来龙去脉。

延伸一句，之前有一些开发人员向我诉苦自己的时间经常被QA占用或打断，我的解决方案是：多替对方想想，提前把QA可能会来问的东西告诉他们，并尽量详细些，到时候就能理直气壮地说一句“自己看comment去，我都写了”（当然如果QA对于5603有任何问题，仍然可以直接来问我）。而如果真的是很复杂的信息，（重复）沟通在所难免，那也主动一些，提前找他们沟通，因为与其自己的大块时间被动地被他们的问题打碎，不如提前充分利用自己已经存在的碎片时间把信息分批告诉他们。同样一个小时，整块的和打碎的价值相差十万八千里，这跟内存是一个道理

至此，整个bug的修复基本完成，只等待验证和code review