先让它跑起来，然后把它做好，最后把它做得更好
工程师们围绕流行的格言“先让它工作，再把它做对，最后把它做快”展开争论，在快速原型和 MVP 与技术债务和架构错误的长期成本之间权衡。许多人认为，性能、可访问性和可维护性必须比这句口号所暗示的更早被考虑，并以基于 Electron 的应用和会变成永久方案的“临时”权宜之计为例。另一些人则反驳说，在大多数商业场景中，快速交付一个“足够好”的产品是合理的，因为许多产品根本活不到需要全面重写或深度优化的那一天。
关于这一箴言的不同解读
- 人们提出了许多变体：
- “先让它能用，再让它正确，最后让它快。”
- “先让它成为可能 → 令人愉快/更可能 → 有利可图/便宜。”
- “先让它运行起来 → 再把它做对 → 再把它做快（如果需要）。”
- “先让它工作 → 工作得好 → 看起来好看。”
- 几位评论者认为，“正确”和“快速”往往彼此交织；核心 API 和数据结构的选择会把性能强行锁死，迫使以后几乎重写。
- 也有人认为，“快速”是一个不同的、后续的步骤，它建立在干净、稳定的 API 之上，这样你就可以在不改变行为的情况下替换实现。
正确性、性能与架构
- 许多人强调先正确：一个运行很快但结果错误的程序毫无用处。
- 有人声称，大多数性能问题都是局部的（查询、函数），无需重新架构也能修复。
- 也有人坚持，现代性能很大程度上是架构层面的；如果你不在早期为效率进行设计，后来的“优化”就会变成重写。
MVP、迭代与“足够好”
- 很多人支持“快速上线，快速迭代”：第一个版本会发现真正的问题；后续轮次再细化和优化。
- 批评者指出，“原型”或“临时代码”很少会被丢弃；由于商业压力和优先级安排，临时拼凑的东西往往会永久保留。
- 还有人强调，软件是为商业需求服务的；如果某样东西对客户和收入来说已经“足够好”，那么就很难为更深入的重写找到理由。
Electron 与资源使用
- Electron 被用作一个核心案例研究：
- 支持 Electron 一方：庞大的开发者池、跨平台一致性，以及开发速度，往往比 RAM/CPU 成本更重要；公司优化的是迭代速度和可行性。
- 反对 Electron 一方：浪费资源，把硬件/能源成本转嫁给用户，尤其对始终运行的应用（聊天、音乐）危害更大。
- 有人认为，用户大多是缺乏更好的选择或理解，而不是他们不在乎。
流程、重构与风险
- 有人主张明确的循环：先原型，然后“把它做对”，再“把它做得更好”，有时还会刻意遵循“把第一版扔掉”的规则。
- 也有人警告，如果没有时间、权限和文化去重构，第 2 步和第 3 步就永远不会发生。
- 诸如可逆与不可逆决策，以及“最后负责时刻”等概念被提及，用来判断何时该投资于“做对”，何时只是“先把它发出去”。