你以后永远不会修复它 - 如何将你的团队从流沙中拉出来

没有一家公司是从测试人员开始的。

然后 2 年后，这家初创公司无法为其最大的客户发布新功能，除非他们大刀阔斧地重写整个事情。一遍又一遍地看着这个很痛苦。

有一些简单的事情可以保持我们软件的卫生质量，所以您不会落入这种境地。

首先，拥抱你的恐惧。工程师是勇敢的人，我们不会轻易承认我们有顾虑。但是我们有，我们越早承认并分享这些担忧，我们就会越早准备好面对它们。

我们今天如何构建软件

我们太匆忙了，总是迟到。没有时间进行测试。没有时间进行单元测试。没有时间进行重构。

好吧，当我们作为工程团队不断破坏自己时，永远没有足够的时间来做正确的事情。

我们被问及需要多少时间，我们一直将单元测试、手动测试，甚至 API 测试和重构排除在我们的估计之外。

所以我们构建这样的软件：

• 又快又脏

• 不快，还是脏

• 快速愉快的对角线路径测试

• 其他一切都被认为是边缘情况。 （没有所谓的边缘案例。）

  
  

我们中很少有人更勇敢地拒绝快速或肮脏，并快速稳定地构建软件。

你应该从你的估计中削减的是范围，而不是质量。

您对正在处理的组件的质量了解多少？

• 你知道它很脆弱，但你不想碰它，因为它非常脆弱。

• 你很久以前就做过了，你几乎没有碰过它，它应该可以工作。

• 你不知道它很脆弱。

• 没有测试，也没有人可以测试和暴露它实际上有多脆弱。

  
  

您每天都乐于与这个肮脏的软件打交道吗？

您是否乐于每天在工作质量上做出妥协，知道它远非如此？应对“我们没有时间打扫”并且仍然迟到，因为它很脏而且你不清理它就不可能继续前进。

想象一下，您正在参加下一次工作面试。在你目前的工作中，你会吹嘘什么？您可以在压力下执行并进行深夜修复吗？他们会因此而爱你，但他们也会问你为什么不为此做点什么。也许这不是你的工作。

有团队领导和工程经理来做出这些决定。如果这取决于你，你会做一些事情。你告诉他们代码需要重构，你需要在每次回顾时为技术部门安排时间，但没人听。

好吧，你猜怎么着——你不需要许可。你的工作质量只取决于你。没有人可以强迫您编写蹩脚的代码。时间压力是短期的借口。快速而肮脏的解决方案会延迟整个项目，并且比您第一次就做对的成本更高。

你以后永远不会修好它

你愿意做出改变吗？

然后，要做的是：遵守纪律。对不起，但没有其他办法。它应该在各个层面。

构建更高质量代码的第一步应该是什么？

实施日志记录和警报

有大量用于记录和警报的工具。这是要做的第一件事。您的软件正在崩溃，而您完全没有意识到。

找到一种解决方案，让您可以轻松地从异常警报创建工单，并将它们标记为“已知”或在报告后将它们分组。

建立团队例程以观察和报告警报

如果您认为这很乏味，那么让我问您：您整个工作日是否都沉浸其中？在所有的会议和繁重的编程工作之后，您需要稍微放松一下注意力。好吧，浏览警报频道比浏览任何其他频道要好得多。

只需单击“报告工单”按钮或“标记为已知”按钮。如果你感兴趣，你可能会修复一两个。

最大的争论来了——我们可以修复几个，但我们正在编写需要有人确认的测试，我们需要部署，这会为团队带来更多计划外的工作。

PM 会对我们大喊大叫，说我们不是在处理高优先级的项目，而是在处理镀金的小警报。

具有所有“M”角色的团队对此表示同意。

发布一条经验法则——“如果它看起来很小且风险低，并且绝对没有其他正在进行的工作，那就去解决它并修复它。我们可以在每个 Sprint 中处理一两个固定的“超出范围”的小警报，以及计划中的。”

就是这样，非常简单。

开始一项一项地清理日志和警报

除了偶尔的修复，适当地计划清理。请注意，通过计划，我的意思是分配每天/每周的时间来修复它们，而不管它们的严重性或优先级。你会浪费更多的时间来评估他们的优先级而不是修复前 5 个。所以，开始修复吧。

确保每个开发人员都有一个警报，或者如果您大部分时间都在围观，请设置每天的警报时间段。我会在早上做第一件事，否则你永远做不到。

同样，这不是一个新功能，它似乎占用了您关键优先事项的时间，但由于这些隐藏的问题，您的关键优先事项已经迟到了。你已经迟到了！

删除所有空的 Try-Catch 语句并让它崩溃！

虽然警报和日志记录会暴露很多内容，但它们无法记录您隐藏的内容。所以不要把你的问题隐藏起来。

2 年前发生的崩溃，而你不知道为什么，今天却完全不同了。让它崩溃，然后修复它。它甚至可能不会以同样的方式崩溃，或者它甚至不会崩溃，所以无论如何，如果没有这些，您的代码将处于更好的状态。

立即开始编写单元测试

我是认真的。您现在正在处理一些代码。然后没有什么能阻止你编写单元测试。

我懂了！没有准备好进行单元测试的基础设施，是吗？快点！无论如何，您都会延迟那个想要的功能。

您不需要超过一天的时间来设置单元测试框架和您的 CI 来运行测试。去做就对了。

为 Bug 修复启动 TDD

“我们不知道问题出在哪里，也不知道我们将如何解决它。我们无法为尚不存在的代码编写测试。”

亲爱的开发人员，测试的目的是检查假设。这适用于一般测试，而不仅仅是软件测试。因此，您需要编写测试的不是代码。您需要预期的行为和结果。

现在，如果用户故事含糊不清并且你还没有准备好开始针对用户故事编写测试，我也有一个解决方案，但在此之前 - 开始为错误编写测试优先代码。

错误描述中有一个称为“预期结果”的组件，重现的步骤是您的测试用例。所以你面前已经有了测试用例。现在，在开始修复代码之前首先对其进行编码。

测试驱动开发正在编写一个测试来验证你做了正确的工作，而不是你已经做对了。单元测试验证你是否做对了。

绘制覆盖路线图

测试自动化和技术债务有着相似的悲惨命运——它们从未开始，因为“我们永远无法涵盖所有内容，我们永远无法清理所有内容，开销太大。我们没有时间这样做。”

听我说完：您不必将所有事情都自动化！

但您绝对必须自动化您的关键任务元素——高优先级用例、关键基础设施和核心功能。随心所欲，但业务依赖于您 20% 的代码和基础设施，而您的客户使用您 20% 的功能。

你看我要去哪里了。

您甚至不需要立即开始为这些功能编写自动化测试。您首先需要做的是优先考虑它们。

在您的高级和低级架构图前作为一个团队聚集在一起。没有，是吗？或者存在的是 2.5 年前拍摄的白板照片？我知道。

是的，您需要花半天时间来更新这些内容。好消息是有一些有趣的工具可以帮助您，因此您不需要手动维护它。做一些研究。

毕竟你是一个研发团队，对吧？！

不要以全面覆盖为目标——而是以低风险和高可信度为目标

在绘制最新架构和基础设施的图表时，添加注释或圆圈，或者将以下所有地方加粗或涂成红色：

• 对您的业务和软件至关重要

• 迫切需要重构，否则您将一直推迟其他关键任务功能。

• 不断地破坏和浪费时间修复它们几乎是徒劳的，因为它们会在几天内再次破坏。

图纸准备好后，与您的团队一起讨论需要对所有这些带圆圈的组件进行测试的内容。

• 不要陷入“这太过分了！我们必须停止所有其他工作以涵盖所有这些！”的陷阱。您不必一次涵盖所有这些。但是你需要一个计划。现在，打开另一个看板，开始编写您的测试目标。例子：

  
  

  • 涵盖所有成功和失败的获取数据 API 请求，这样您就知道您不会发送错误的请求，如果失败，则因为供应商而失败。

    
    

  • 概述关键任务用户旅程。把它分解成单元。编写单元测试。当测试金字塔被发明时，一个单元意味着一个组件，而不是一个方法，所以它涵盖的是功能，而不是方法和类。

    
    

  • 识别交通堵塞，并决定如何解决它们。

    
    

  • 计划做对。你的快速和肮脏的代码将在肮脏的测试中保持肮脏。

我有意使用覆盖图而不是测试金字塔，因为……在这个阶段，当您没有任何手动或自动测试到位时，您还没有为金字塔做好准备。

许多团队有错误的印象，认为他们必须先达到 96% 的单元测试覆盖率，然后再进行集成测试等等。现代单元测试覆盖率的问题在于我们测试的是方法和类，而不是功能。

甚至更多的团队从 UI 自动化开始，这同样是错误的。

这实际上是你能做的最糟糕的事情，而且注定要失败。

因此，不要从金字塔的顶部或底部开始，而是构建风险地图。

某些功能可能需要广泛的集成测试，其他功能可能需要广泛的 UI 测试，下一部分可能确实是一切都依赖的核心功能（尽管是另一个危险信号），您必须从上到下完全覆盖它。

或者它是一种数据收集服务，例如，您需要关注 API 的性能。

构建需要大量测试的软件热点图。

然后考虑如何使该测试自动化。

你不能在流沙中进步，只有你才能把自己从那里拉出来

让我们总结一下 - 没有测试，代码状态不佳，而且您没有时间。你一直在妥协，因为“你没有时间”。你并不完全开心，或者至少你很无知——他们付钱，这是他们的决定，而不是你的决定。

如果他们不满意，你就会转到下一家公司。

好吧，去年情况发生了很大变化，不是吗？！您需要成为一名出色的开发人员才能继续被聘用。公司了解到，无论他们的贡献如何，他们都可以抛弃人。

尽管如此，公司还是会竭尽全力留住工程师。要成为其中一员，您需要推动变革并不断证明业务取决于像您这样的人。

每个人都会写出蹩脚的软件，但真正优秀的人不仅能愉快地写出优秀的软件，还能激励他人，传播代码质量文化。

在流沙中你无法进步，只有你才能把自己拉出来。