在做出任何更改之前，每位开发者都应该问一个问题，但几乎没有人被教导去问它。
如果我在这里犯了错，最糟糕的后果是什么？
搜索“软件开发中的风险”，你会反复看到同样的文章。一份整齐的项目类别清单：预算风险、进度风险、范围蔓延、技术风险、安全风险。读起来像是项目经理存放在文件夹里的东西。这些内容都没有告诉开发者，在一个周二下午，当他们即将推送代码变更时，该如何以不同的方式完成实际工作。
那份检查清单忽略了一个决定你是否优秀的风险。你做出的每一次变更都带有一个“爆炸半径”，即如果出错，它可能造成的损害程度。资深工程师在开始工作前会评估这个爆炸半径，并据此决定需要多么谨慎。能力较弱的工程师则以相同的方式对待每一行代码，这在两个方向上都是问题。他们在无关紧要的地方行动过于缓慢，却径直走向那些看似无害实则危险的变更。
这是一份关于如何评估爆炸半径的指南。这份指南既是为 Full Scale 公司的内部工程师编写的，也是为其他任何人编写的，因为这种判断力是区分“推动业务发展的开发者”与“仅仅处理工单的开发者”的关键因素。
真正的风险不是一份检查清单，而是每次变更的爆炸半径
风险不是在项目启动时评估一次然后归档了事的东西。它是你每次打开拉取请求（Pull Request）时都需要回答的问题。
想想一家公司发布的各种软件。发射火箭的代码必须完美无缺，因为你无法修补已经升空的航天器。而那个每周只有三个人瞥一眼的内部仪表盘代码，即使整天出错也没人会在意。这是同样的技艺，同样的语言，但利害关系天差地别。如果你用同样的方式构建两者，那你肯定把其中一样做错了。
这项技能在于将你工作的谨慎程度与错误可能造成的实际损害相匹配。
大多数开发者从未有意识地做出这种判断。他们要么对所有事情都采用同样繁重的流程，导致效率低下；要么对所有事情都持同样随意的态度，导致危险重重。优秀的开发者会进行分诊处理。他们会审视即将触碰的内容，询问如果这里出错后果有多严重，并将他们的谨慎用在能产生价值的地方。
马特·沃森：将你工作的谨慎程度与错误可能造成的损害相匹配
针对眼前工作的爆炸半径阶梯
以下是思维模型。在开始之前，根据最坏情况将变更放在一个阶梯上。有两个因素决定层级：它可能造成的损害程度，以及撤销它的难度。一个可以在三十秒内回滚的错误，与一个无法挽回的错误截然不同。损害越大且越不可逆，就需要越严格的严谨性。
判断可逆性的一个简单方法是看变更是“单向门”还是“双向门”。双向门可以轻松退回：例如隐藏在功能开关背后的小功能、配置调整、或者可以一键回滚的部署。单向门则无法在没有巨大成本的情况下撤回：例如作为其他所有内容构建基础的核心架构、重写数百万行数据的数据库迁移、或者一次性替换所有内容的大规模生产环境切换。大多数日常工作都是双向门，因此其风险远小于感觉上的风险，你可以快速通过。将你的谨慎保留给单向门，因为在那里犯错会产生持久的后果。
灾难性。任何涉及资金或向大量人群发送消息的内容。例如向客户信用卡重复扣款的计费代码。向整个列表用户发送电子邮件或短信的任务。任何大规模自动运行的内容，因此单个错误会重复数千次
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
