你的代码库需要 OSHA
Source: Dev.to
我从来无法在凌乱的空间里正常运作。这并不是关于整洁——而是更深层的原因。当事物散乱、标记错误或被阻塞时，这不仅仅让我恼火——更伤害我的大脑。当环境与我作对时，我无法清晰思考。
真实案例
多年前，我在一家仓库工作。货物随意堆放，通道被堵，东西都不在该放的地方。
“这乱象不仅让人恼火，还很危险。有人会绊倒的。”
我把一位经理拉到一旁，冷静而清晰地说明了风险，并指出我因为必须绕开混乱而变慢。对方的回应？
快进到现在，我听到的正是同样的话。
代码库如危险工作场所
- 地雷: 缺失的标签、接线错误的逻辑、只有在踩到时才会触发的隐藏陷阱。
- 裸露的钉子: 代码中留下的 TODO，只有一半记住的业务规则。
- 座右铭: “事情就是这样。”
但事实并非如此。它不该是这样的。我们已经忘记了当伤害不可见时 “不安全” 的样子。
认知伤害也是伤害
“让你精疲力竭、让你怀疑自己的能力、因为架构主动抵抗理解而把你逼到深夜加班的代码？这也是安全问题。”
如果叉车司机拒绝操作没有刹车的机器，我们会称之为安全问题。为什么当你的大脑被逼到极限时却不同？
要求安全并不是个人的失败。
你并不是在挑剔——你是在负责任。
商业现实
我明白：你面临交付压力，不想再有延迟、再有争论、再有耗费在看不见的东西上的故事点。
事实： 这种混乱正在让你付出代价。
- 事故
- 错失交接
- 更长的入职时间
- 人员流失
仅仅因为伤口没有留下瘀伤，并不意味着你没有在 流血（损失金钱）。
你不必成为代码质量的狂热分子。
不安全认知环境的症状
- 生产力下降，而管理层却看不见。
- 对基本任务产生怀疑。
- 在脑中携带的状态比系统内存中的状态更多。
- 花费大量时间预测故障模式，而不是编写功能。
- 对工具——以及对自己的信任丧失。
“为什么这么久？”——这句经典提问标志着受伤。
而且也许最糟糕的部分？你停止谈论它——不是因为你不在乎，而是因为觉得徒劳——甚至更危险。那种沉默正是不安全系统得以存活的方式。
安全的样子
基础
- 呼吸。 它让你在没有直觉恐惧的情况下有信心进行更改。
- 可预测性。 它让你在不需要给新开发者一串念珠和支持小组的情况下让其加入团队。
现有的安全装备（我们已经拥有）
- 类型系统
- Linters
当有人为了快速而禁用它们时，这种理由会被侧目——因为我们知道这意味着什么。
安全装备只有在使用时才有效。
想象一下告诉工厂工人安全设备是可选的。听起来荒唐吗？更糟的是……熟悉吗？
为什么安全协议在受伤后才出现
- OSHA 并不是因为有人对梯子非常在意而出现的。
- 它只在伤害变得不可忽视时才出现。
我们的事后分析并不是用血写成的，但仍然是用痛苦写成的：失眠的夜晚、失去的周末、倦怠、升级、辞职。
常见的事后分析语句：
- “我们没有意识到那个系统是多么相互关联的。”
- “没有足够的时间编写测试。”
- “它很脆弱，但我们不知道有多脆弱。”
我们把这些称为事件。闪电并不常常击中，而且也不总是击中同一个文件。
速度 vs. 安全
- Velocity 是一个标量。它告诉你团队有多快——但不涉及原因。
- 它不在乎速度是来自清晰的架构还是无偿加班。
- 速度可以被制造——通过跳过安全。
OSHA 并不以速度来衡量成功，而是以无伤害来衡量成功。
不安全的行为不是个人缺陷——而是系统性问题。
不安全的环境随着时间推移成本更高——即使它们在短期内更快。安全的成本低于事故，但前提是你在伤害发生之前进行投资。
系统的角色
安全的环境不依赖于每个人都勇敢。
它依赖于系统不允许不安全行为继续。
- 事后分析成为信号，而不仅仅是故事。
- 没有安全的高速并不是交付；它是导致人员流失和延误的配方。
我们不需要重新发明如何保护自己。
行动号召
你已经看到了伤害。以下是你的选择：
- 继续压榨系统，直到出现故障。
- 决定安全重要。
事实很简单：事故的成本高于预防。
一旦你这样看待，就很难再忽视。
你想负责什么样的系统？
我们每个人都有责任。而且有人 指望你 做出正确的决定。
将承担下一个风险。
这部分仍取决于你。