没有绝对的答案，这就是重点。速度与可维护性是情境相关的 — 您根据风险程度和代码的预期生命周期来匹配严格程度。一次性原型和支付核心应该有非常不同的标准。负责人的工作是有意地做出权衡，而不是让它意外发生。
决策框架
在采取捷径之前，问三个问题：
// TODO、RFC 中的注释）。您确切知道您做了什么权衡以及为什么。即使在压力下也要保持核心清洁 — 良好命名的边界、经过测试的关键路径。将混乱推向边界，这样便宜到可以推翻。
当截止日期紧张时，诚实的做法是与涉众重新协商范围或时间 — 而不是默默地交付易损坏的东西。"我们可以用功能 A 和 B 赶上日期，但 C 推迟一周"是一个真实的对话。默默地交付脆弱的代码会消耗团队未来的速度，却没有人同意。
总是优化速度的团队会陷入技术债；总是过度设计的团队会错过市场。负责人的价值在于判断力 — 根据情景调整严格程度，并让权衡可见且负责，这样今天的捷径就是团队可以偿还的选择，而不是它继承的意外。