在发布新功能之前

介绍

发布新功能令人兴奋，作为软件开发人员，我们希望看到我们的代码在生产中运行。但是，在提供有助于提高新功能质量的任务之前，可以采取一些操作，问题和步骤。

使用行为，如构建优雅失败的代码，利用重构机会，了解所交付功能的影响，监控和手动测试更改，只是预发布活动的几个示例。

在发布功能之前要问的问题

始终牢记新变更可能对最终客户造成的影响至关重要。如果出现问题，无论合并提交的简单程度如何，都要反映出对用户会产生的后果。

此外，还要考虑最终用户提供的功能对他们的观点有多重要。如何做得更好？

在发送我们心爱的代码之前要问的几个问题可能是：

如果此页面/服务中断，用户将体验到什么？

恢复这些变化有多难？

像这样的突破会对我们品牌的形象产生多大的影响？

还有哪些其他功能可以利用这一功能并为用户提供更多价值？

此功能可能缺少哪些功能？

这些问题的答案将概述可以采取的步骤，以提高已发布功能的质量。

在发货清单之前

以下是在单击部署按钮之前可以执行的操作清单。

为有影响的角落案例创建测试

当然不需要测试每个边缘情况。你很可能不会覆盖所有这些，它会让你的测试套件变得臃肿。

但是，必须测试导致有效故障的极端情况并使用回退功能进行覆盖。例如，如果特定页面依赖于从外部API获取数据。如果API关闭会发生什么？页面是否打破？它是否部分填充？它是否重定向到另一个页面？

探索这些最具影响力的边缘场景通常可以防止将来出现生产问题。如果一个人滑倒，在测试中重现错误，修复不需要的行为，然后将其推到堆栈中。

手动测试更改

不幸的是，自动化测试并不总能抓住一切。花点时间探索产品和正在交付的新功能。以客户的身份体验它，并问自己是否对解决方案感到满意。

如果识别出与功能相关的改进，请确保使用用户素材跟踪它们。它们可能不需要立即实施，但如果它们可以在积压中访问，最终它们将被处理。

获取客户的反馈

我们经常就如何使用我们开发的产品提出想法和意见。然而，真正重要的是我们的客户如何使用和感知我们提供的功能。

从最终用户那里获得反馈是一种苦乐参半的感觉。同时它可能是艰难而富有洞察力的。他们可能批评您努力构建的产品，同时也让您了解他们需要或期望的产品。保持开放的态度，如有必要，随时准备转移焦点。

设置充分的监控

在软件中，很多事情都发生在幕后。通过使用用户界面来判断一切是否正常并不容易。记录是用于查看正在生产中运行的系统的方法之一，并且如果事情真的很好就能理解。

但你会记录什么？这不是一个微不足道的问题。这取决于系统，产品和构建它的团队。太多的日志记录可能会导致不必要的开销，而太少的日志记录可能会使您在应用程序中发生的情况为零。

要记录的事情的一些示例是：

• 当预期的错误发生时（例如：内部救援/捕获区）
• 当出现不期望但必要的行为时（例如：用户被重定向到404页面）
• 关键指标（例如：在后台处理的项目数）
• 业务指标（例如：使用Google注册的用户数）

重构代码

绊倒可能被重构的代码片段（出于质量或可重用性目的）经常发生。改进代码或使其可重用于其他开发人员可能会花费一点时间，但从长远来看它会得到回报。

如果没有开发人员支付重构任何代码的代价，技术债务可能会堆积起来，直到代码库减缓新功能的开发。那时，你要付出所有未完成的重构的代价。

如果可以通过一些额外的工作来改进代码的一部分，那就去做吧。让下一个将触及该部分代码的开发人员更快乐。

结论

这是我对功能发布清单的看法。你会在列表中添加什么？你的团队有什么做法？我很乐意听到它