如果你的代码只是足够好，也没关系
在软件工程中，如何在“足够好”的代码与长期质量之间取得平衡，是一个反复出现的张力。评论者们权衡了快速交付虽然凌乱但可工作的代码——尤其是在创业公司或原型阶段——与忽视可读性、测试和清晰设计后所积累的维护成本、漏洞和功能开发减速。许多人认为，可接受的质量高度依赖上下文（从生命攸关系统到 CRUD 应用不等），但团队应明确约定质量标准，避免完美主义与教条式做法，因为这些做法会无谓地增加复杂度而没有真正收益。
代码生命周期与遗留现实
- 经验差异很大：有些代码几年内就会消亡，而有些 1990 年代的代码至今仍原封不动地运行。
- 有几位提到一个悖论：“快速拼凑的临时代码”往往活得最久，而精心打磨的“杰作”却会被替换。
- 有人认为从未被触碰过的代码就是“死的”；也有人说，未被修改却能正常工作的代码，才是成功而不是失败。
“足够好”的含义取决于上下文
- 许多人同意：在安全关键系统之外，能发布并解决用户问题的“足够好”通常就是正确选择。
- 也有人反驳：把“足够好”当借口，可能会纵容意大利面式代码、漏洞和糟糕工程。
- 不同场景不同：
- 没有用户的创业公司：速度和学习比结构、测试和抽象更重要。
- 任务关键系统：可靠性和 QA 压倒一切，即使生产力代价极高。
- 普通业务应用：应追求平衡，并最好由团队明确决定。
代码质量 vs 产品质量
- 用户看不到代码风格，但他们看得到漏洞、卡顿和缺失的功能。
- 一派观点认为：糟糕的内部实现最终一定会拖慢功能开发并增加 bug，因此质量是经济上的必要条件。
- 另一派观点认为：过度工程化、抽象过重的“干净代码”，以及教条式规则（DRY、设计模式），造成的伤害可能大于帮助，既影响可用性也影响交付。
可维护性、协作者与流程
- 多个案例提到，混乱的代码库会导致功能开发变慢、疲于救火，并让后续维护者感到沮丧。
- 轻量实践——测试、清晰结构、简单设计——被认为在你熟练之后，往往并不比草率工作更贵。
- PR 规范和 CI 被特别强调：连运行都不行的代码，普遍被视为不应进入评审。
抽象、DRY 与 WET，以及可读性
- 过度抽象和极端 DRY 是常见抱怨；它们会隐藏行为、增加认知负担，并让调试更困难。
- 也有人“非常害怕 WET 代码”，因为重复的业务逻辑很容易被不一致地更新。
- 新兴的折中方案是：只有当事物确实必须一起变化时才抽象；优先考虑行为的局部性，以及从客户端代码追踪的容易程度。
完美主义、学习与专业精神
- 有些人享受追求接近完美，把它当作工艺或竞争优势。
- 也有人警告说，把“只是足够好”当成心态，会阻碍技能成长并拉低行业标准。
- 大体共识是：务实一些，提前讨论质量目标，并让投入与风险、领域和生命周期相匹配。