加载失败
文章描述一个团队在耗费约 18 个月开发后决定全部重写代码的经历；评论揭示作者早期禁止写测试但后期又从零开始建立测试的矛盾，以及因此导致的客户流失和代码质量问题（文章涉及的产品自称是自动化 bug 查找工具却仍丢失客户）。讨论频繁把该案例放入“version 2 problem”的历史框架，引用 Netscape（早期浏览器厂商）和 Fred Brooks（《The Mythical Man‑Month》作者）的教训。评论者以创业公司常见的“原型优先（prototype）”与“生产化（production）稳定”之间的成本—收益权衡来评判是否在早期投入测试，并延伸到工程文化、技术选型（如 microservices、Node/Next 生态）导致的长期维护问题。整体争论结合历史教训、团队治理与现代工具生态来评估作者的决策合理性。
评论将作者的经历放进所谓的“version 2 problem”框架：v1 往往是为客户快速定制、能用但设计欠缺的版本，团队试图通过彻底重写（v2）来修复所有问题却把所有此前被搁置的想法都堆上去，结果导致过度设计、性能和可维护性下降甚至客户流失。有人用 Netscape 的 NN2 失败与 Fred Brooks 在《The Mythical Man‑Month》中关于“第二系统倾向”的论述来类比，指出 v2 经常变成“big pile”。实务经验显示 v2 可能短期扩大客户群但会让原有大客户反感，理想的 v3 则是去掉 v1 的严重缺陷同时避免 v2 的不必要复杂性，从而恢复用户满意度并逐步扩展产品。评论中还有具体案例：v1 为单一客户定制且被喜爱，v2 为泛化做了全面重写却导致老客户大量反弹，需要多年通过逐步重设计才能折中回归。
关于是否在早期写测试有强烈分歧：有人认为“actively disallowing tests”在任何场景都很危险，缺乏自动化测试会让每次改动依赖大量手动回归，长期成本超过编写测试本身。反对者主张对小团队、燃烧现金且尚未找到 product‑market fit 的创业公司应做成本—收益评估，短期把精力投在探索和快速迭代上可能更划算，且评论提到 LLM/AI 工具正在快速改变测试的成本结构。许多评论建议把最初工作当成可抛弃的 prototype，在确认方向后再“从零开始”建立测试（作者后期也提到“we started with tests from the ground up”），并引用“0→0.1 与 0.1→1” 的区分来说明探索期与放大期对测试的不同需求。反对完全禁写测试的声音还指出，不写测试会导致繁重的手动回归测试和不可预测的回归风险，从而吞噬未来开发速度。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9]
很多评论把问题归结为工程文化和领导决策：对特定方法的教条式坚持（例如完全禁止测试或盲目追求微服务）会阻塞讨论與成本—收益评估，导致重复犯错并损害团队信誉。有人讲述极端案例：技术负责人逼着创始人做出一个耗时数年的“microservice monster”，团队只有一位开发、只有一个表单被大量使用却因架构糟糕（如 React 过度重渲染导致输入滞后）而体验极差。评论还指出作者公开“自我检讨式”叙述可能反映骄傲或炒作，有人甚至怀疑这是“no such thing as bad publicity”的公关策略；同时揭露矛盾——产品号称是自动化 bug 查找工具，却因代码质量问题失去客户，进一步加剧对领导判断的质疑。
评论讨论把部分责任归于技术生态：有人直言 Next（Next.js）和 Node 生态在实践中带来很多碎片化与重复工作，缺乏像 Rails 或 Django 那样的“batteries‑included” 全栈惯例，导致团队常常在工具链选择上踩雷并产生长期维护成本。也有回顾性观点认为早期 Java 应用服务器曾把许多 web 问题较好地整合起来，而当代的前端/后端框架更多是一种“时尚产业”，开发模式随潮流变化。该话题延伸出对技术趋势的厌倦与期待：有人半戏谑地说 Mongodb 是“webscale”，也有人对 LLMs 带来的新探索性表示感激，认为这是几十年内真正的新鲜事物。
version 2 problem: 指第一次可用但粗糙的产品（v1）之后对系统的全面重写（v2）往往会把所有理想化设计堆叠上去，导致过度工程、性能或可用性下降并可能伤害市场地位；评论中用 Netscape（早期浏览器厂商）NN2 和 Fred Brooks 在《The Mythical Man‑Month》对“第二系统倾向”的论述来说明这一现象。
TDD (Test‑Driven Development): 先写测试再实现代码的开发方法；讨论中出现对 TDD 的正反两面观点、所谓“reverse TDD” 的实践以及在原型期与生产化期对测试投入的不同权衡。
microservices: 将应用拆分成多个小服务的架构模式；评论指出在小团队或单客户场景下，过早或过度采用 microservices 会造成复杂性和维护成本激增，出现所谓的“microservice monster”。