译：是时候抛弃的 5 个工程教条
原文：https://newsletter.manager.dev/p/5-engineering-dogmas-its-time-to
作者：Anton Zaides
译者：Claude
几个月前，我写了一篇关于13 条软件工程定律的文章，那些是关于软件项目行为模式的观察。
今天，我将介绍 5 个被认为是"常识"的实践，以及为什么我认为值得重新考虑它们。
- 不要重复造轮子——找一个包
- 每个 PR 都必须经过审查
- 2-4 周的冲刺是现代团队的工作方式
- 每个代码变更都应该放在功能开关后面
- 如果需要注释，代码就太复杂了
1. 不要重复造轮子——找一个包
为什么要浪费时间写别人已经写过的代码呢？
我曾经工作过的一家初创公司的 CTO 非常讨厌依赖。我们做一些 3D 计算（无人机软件），他自己写了几十个数学函数。他坚持认为，虽然这样做更慢，但他至少理解每一部分，可以修复任何可能出现的 bug，而且不会在软件的关键部分依赖任何其他人。
我曾经嘲笑那种偏执，他让我去读一些疯狂的故事：
- left-pad 的开发者从 NPM 上删除了它，导致 Facebook、Spotify、Netflix 和许多其他公司的构建失败。它基本上是一个 11 行的 for 循环，用于在字符串中添加空格。
- is-even npm 包每周有 16 万次下载（！）。作者是在学习编程时发布的。它的功能是这样的：
是的……
你也更容易受到安全事件的影响（并且需要花费大量时间追踪更新）。在大多数小公司，没有包的审查流程（不像供应商那样）——每个工程师都随心所欲。
有了 LLM，更容易陷入这种混乱，也更容易摆脱它：误装一个不需要的依赖更容易了，但从头实现"已知"的解决方案也更快了。
这是一个微妙的平衡。
2. 每个代码变更都必须经过审查
在我过去 15 年工作过的每家公司，我们都有强制代码审查（每个 PR 至少一个，通常两个审查者）。
几个月前，我写了一篇关于强制代码审查的代价的深入分析。
简而言之——它们帮助你提高质量，但会大大减慢你的速度。
我绝对不反对代码审查——它们有很大的价值。我反对的是一个有严格规则的冗长流程（比如每次 PR 的提交都必须重新请求审查，即使它已经被批准了）。
我喜欢 Pylon 的流程：工程师合并自己的代码，只有在需要意见、认为有风险的变更或仍在入职时才请求审查。他们的思路是：如果我们雇用有技能的工程师并信任他们，就没有理由用强制审查来阻塞每个变更。
结对编程也是异步审查的一个很好的替代方案。
3. 2-4 周的冲刺是现代团队的工作方式
我相信冲刺正在夺走构建软件的乐趣。
如果你必须思考组织团队努力的理想方式，你真的认为你会选择目前的做事方式吗？
你觉得它为你的客户带来了最大的价值吗？你认为你的工程师真的享受这个过程，感觉他们是在用自己的创造力做贡献吗？
Shape Up 是一个很好的替代方案。以下是它的要点（来自这里）：
我们以 6 周为周期工作。一个周期结束后，我们会从计划项目中休息一到两周，这样每个人都可以独立漫游、修复问题、做一些我们一直想做的个人项目，并在开始下一个六周周期之前放松下来。
注意：这些不是冲刺。我鄙视"冲刺"这个词。冲刺和工作不搭配。这不是要你全力以赴跑得越快越好，而是要平静地工作，以合适的节奏，并在过程中做出明智的决定。 没有蛮力，没有在最后集体喘息。
我的观点不是说你应该采用 Shape Up。
而是说 Scrum/Kanban 有替代方案。你可以建立一种真正适合你的团队和公司的工作方式，而不会让每个人都筋疲力尽。
4. 每个代码变更都应该放在功能开关后面
在很多情况下，功能开关正在毁掉你的代码库：
一旦你引入了功能开关的能力，PM 们就会想出其他使用它的想法：
-
为什么我们要依赖开发人员来进行配置更改？让我们把它移到 PM 可以访问的地方，这样我们就可以在不打扰任何人的情况下完成。
-
既然如此，让我们也让它可以按用户调整！这样，PM 可以安全地为几个用户发布功能以收集反馈并自己测试，之后再向所有人发布。
这类似于金丝雀发布。它们之间的区别是，金丝雀发布的功能会暴露给随机选择的一组用户，而这里的功能会暴露给特定的一组用户。
-
为什么我们要限制自己只用它来开启功能呢？让我们把最消耗资源的功能放在一个开关后面，让运维人员在异常过载的情况下关闭它。
-
哦，我们还有那些高级用户，让我们只为他们启用一些功能！
-
最后一件事——你可以把所有东西都放在功能开关下，对吧？所以让我们不要冒险进行任何没有它的变更，请把任何 bug 修复都隐藏在一个开关下，以防修复需要回滚。
于是你发现自己陷入了困境，有数百个活跃的功能开关——使你的代码库更加复杂，也更难测试。
功能开关还会给你一种虚假的安全感——我见过多个由开发人员发布到生产环境的代码引起的 bug，这些代码本应隐藏在开关后面，但实际上没有（尤其是在 React 中）。
我绝对认为你应该使用功能开关——只是不要滥用它们。在预发布环境中正确测试代码变更是可以的，然后在没有任何开关的情况下发布它。
5. 如果需要注释，代码就太复杂了
注释建议的 V1 版本是：“注释你的代码，这样无论谁接手都能理解。”
然后，V2 版本的建议开始流行：“如果你需要添加注释，说明你的代码很烂。它需要是自解释的。”
在我看来，任何极端都没有意义。
是的，你可以写出需要更少注释的代码。
尽管如此，在某些情况下，一两行注释可以在未来几年内为别人节省数小时的挫折感。
最后的话
还有许多其他的"常识"，比如"不要在周五发布"和"微服务有助于扩展和所有权"。
它们都不是，本文涵盖的 5 个也不是完全的胡说八道。它们变得如此普遍是有原因的。
我的观点是，好的工程经理知道如何在这些教条和现实之间取得平衡，并不断评估什么对他们的团队最好。