调试会导致工程师陷入代码库的黑暗角落，使他们有时间深入了解某些代码部分，但是这些至关重要的信息（错误和修复）通常留在负责此问题的工程师的脑海中。
如果将来出现类似的错误，会发生什么？ 您是否要求其他工程师提供修复程序，还是最好让原始工程师脱离他们现有的工作？ 在此博客中，我们将深入探讨在工程组织内部为初创企业共享知识的最佳实践。
Bug潜水：统一工程师和开发人员成功团队
在Nylas，我们使用协作式错误探究来帮助我们的团队了解错误，调试策略以及导致错误的代码库相关部分。 在进行bug潜水期间，解决bug的工程师向工程和开发人员成功（尼拉斯的客户成功版本）团队说明了他们的方法和最终解决方案。 这不仅有益于其他工程师，而且对于技术客户成功团队而言，对于以最佳方式交流更多有关其他用户可能遇到的问题以及他们将来如何诊断类似技术问题的信息，也更有利。
如何组织Bug潜水会议
对于Nylas的Bug潜水，工程和客户成功团队每两周聚会一次，以分享经验。 我们使用Zendesk跟踪客户问题，因此带头进行Bug潜水的工程师将与团队共享Zendesk凭单以添加上下文，或者，如果该Bug是内部报告的，他们将显示相关日志，错误消息，或堆栈跟踪。
然后，我们将讨论：
- 工程师关于错误的最初假设
- 他们如何能够复制问题
- 如果原始假设被反对，那么它怎么被反对
- 使用了哪些调试策略
- 咨询了哪些监控工具
最后，他们提出了最终的解决方案，并逐步介绍了解决该问题的代码。
工程团队和客户成功团队对代码库的这一部分有了更好的了解，并接触了新的调试技术。 所有的错误潜水演示文稿都存储在Dropbox中，以后可以很容易地发现它们，以供将来任何人参考。
成功进行Bug潜水的技巧
定期安排错误潜水
—为了保持出席率，请每两周选择一个特定时间，并将其添加到团队日历中。 在另一个事件之前或之后选择一个时间是个好主意，这样工程师就不必从现有工作中抽身而出。 在Nylas，我们在午餐后潜水了虫子，这是在恢复工作之前消化和补充能量的好方法。
提出一个有创意的名称和有关该bug为何有趣的摘要
—在传递有关Bug潜水的消息时共享此内容，以激发对该主题的兴趣。 标题为“关于数据库查询的错误潜水”的事件的投票率可能会比带有特定于错误的标题的事件（例如，在数据库中查询名为X的对象会发生什么？）的事件的投票率更低。 对于第一个标题，工程师可能会认为“我已经了解数据库查询，我不会浪费时间”，但是第二个标题会激起他们的兴趣。
任何人都可以带领Bug潜水！
—您可以将Bug潜水视为小型技术讲座。 进行技术讲座和传达具有挑战性的想法是所有工程师都必须具备的重要技能。 Bug潜水是一种很好的，低风险的方法，可以练习并帮助工程师为更多的听众开发其公开演讲的技能。 不要将bug潜水仅限于高级工程师，对于初级工程师来说，教更多的高级工程师一两件事可能是很好的角色互换。
Bug潜水与传统知识转移课程有何不同
深入探究特定主题。 由于很难在30分钟内传达对大型系统的深刻理解，因此，更深入地研究Bug，并详细讨论系统的一小部分。 Bug潜水不是深入讨论，而是深入研究特定系统的代码。
了解代码中的错误会使团队暴露于代码库的各个角落。 潜入错误时，只会显示具有挑战性或意外错误。 Bug潜水所涵盖的内容由错误发生的位置决定，这意味着Bug潜水的内容通常是鲜为人知的系统。 漏洞修复可帮助团队熟悉经常需要更多关注的更多外围系统中的代码。
提出错误的工程师不必做更多的工作。 除了组织信息之外，由于工程师只是解决了该错误，因此他们已经熟悉了其假设及其漏洞。 他们可能会有一些注释，为相关的监视页面添加了书签，并且可以轻松地进行代码更改。
此过程表示工程师为调试问题所做的艰苦工作。 破坏Bug可能是一个费力且无聊的过程-您正在修复最初不应该被破坏的东西。 但是，bug潜水为庆祝工程师的勇气提供了一个舞台。 工程师可以使用户克服劣等代码和不良监视的麻烦，并以令人满意的解决方案结束。
Bug潜水是自我维持的。 因为错误潜水不仅是演示工程师的庆祝活动，而且对听众有益，所以它们是自我维持的。 总是会有更多的错误。 发现错误的工程师将始终希望分享自己的壮举并受到赞誉。 工程部门的其他成员将始终对不规则错误的原因以及用于识别该错误的调试策略感到好奇。
结论
除了一些小问题，您很少会向其他团队的工程师学习。 Bug潜水通过提供跨团队知识转移的舞台来统一工程师。 这种统一可以导致我们对整个产品的设计和执行做出更有成效的决策。
在Nylas，我们的工程师喜欢就各种与行业相关的主题分享他们的观点。 我们很想听听您的Bug潜水故事以及为您带来的成功。 有关Nylas的更多信息，并加入Twitter上的讨论，请单击此处。
