编程与软件工程joelonsoftware.com编辑精选
你绝不该做的事（2000）
Things You Should Never Do, Part I (2000)
2009 — 2013，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
Joel Spolsky 2000 年的经典文章，以 Netscape 推倒重写导致衰败为例，论证“从零重写代码库”几乎总是灾难：旧代码中看似混乱的部分往往承载着多年积累的隐性知识和修复。文章多年来反复登上 HN 首页，成为关于重写决策最常被引用的论述之一。
为什么经久不衰：重写 vs 渐进重构是每个团队都会遇到的抉择，这篇文章提供了最著名的反方论据，至今仍是讨论该话题的必读起点。
HN 评论精选
推荐用绞杀者模式渐进替换，而非整体重写
如果实在必须重写，考虑逐个组件地隔离和替换，而不是全盘推倒重来。这样不用一次性付出全部成本，还能继续开发新功能，顺便得到更模块化的架构。这就是所谓的绞杀者模式。
bguthrie查看英文原文
If you absolutely must rewrite, consider isolating and replacing components piecemeal rather than scrapping the whole thing and starting over. You don't eat the whole cost at once, you can keep moving forward with new features if needed, and you get more modular architecture to boot. It's called the Strangler Pattern. http://www.martinfowler.com/bliki/StranglerApplication.html
重构优于重写，且静态类型语言对大型项目重构更有利
这篇文章五年前对我影响巨大，让我彻底相信重构现有系统优于重写。修掉陈年垃圾远比从零开始再造一套系统再积累自己的垃圾省时。虽然过程可怕且充满未知，但只要鼓起勇气，其实没那么难。另外，重构大型系统也让我相信大型项目应该用静态类型语言——我改坏代码时希望它坏得越响越好，比如把函数改名后看编译器在哪里报错。
moron4hire查看英文原文
This article, when I originally read it 5 years ago, was hugely influential to me. It completely convinced me of the superiority of refactoring existing systems to an ideal over rewriting. It doesn't take anywhere near as much time to fix cruft as it is to create a system from scratch and try to avoid your own cruft. But it's scary and it's an unknown. But if you approach it with courage, it falls quite easily. EDIT: refactoring large systems has also convinced me of the superiority of statically typed programming languages for large projects. When I break code, I want it to break as hard as possible. I want to see absolutely everywhere function XYZ is called, and one way to do that is to rename XYZ to XYZ___ and see where all of the compiler errors show up.
反方观点：按当前需求重写常常比逆向理解遗留代码更划算
这是被高估和滥用得最厉害的软件工程建议。读不懂陌生代码当然比写新代码难，但这恰恰说明重写往往更合理。我多次成功删掉数千行遗留代码，换成不到一百行、直接可用的实现——秘诀是不去猜测那些无文档的旧逻辑，而是收集当前需求，用最简单的方式重新实现，结果通常可读性大幅提升。
romaniv查看英文原文
This is the most overrated and overquoted piece of (bad) software engineering advice ever. Sure, it's harder to read unfamiliar code than write new code, because your understand the reasoning behind the new code. That's exactly why rewrites often make much more sense than labor-intensive incremental changes. I've had many real-life situations where I successfully chain-deleted thousands of lines of legacy code and replaced it with some sub-100-line method that simply worked. All that without understanding how legacy code works. You're wondering what's the secret here? Instead of trying to deduce the undocumented logic behind legacy code I gathered current requirements and implemented them in the simplest way possible. In most cases the results were dramatically more readable, because I used build-in language capabilities and standard libraries whereas old code spectacularly failed to do so. Also, I didn't have to worry about requirements that were no longer relevant.
重写前先建立测试基线，并渐进式替换
如果真想重写，先给现有产品写全面的测试用例（性能关键处加基准测试）；重写过程中严格对照这些用例，发现新旧差异就补一个测试；可能的话把原产品拆成可独立重写的小模块。重写的问题大多源于从零开始——从内部逐步替换代码库是好得多的做法。
zdw查看英文原文
If you really want to do a rewrite, first: - Write comprehensive test cases and run your current product agains them. Have these also benchmark the code if they're performance critical. - During the rewrite, slavishly adhere to the test cases. If there's an undesireable difference discovered between old/new, write another test case. - If possible, break up the original product into smaller modular sub-projects you can rewrite independently. Most problems with rewrites come from starting from scratch - slowly replacing a code base from the inside is a much better way to do it.
历次讨论
同类还值得读
开源应用架构
The Architecture of Open Source Applications
《开源软件架构》（AOSA）是一本在线免费书，邀请知名开源项目的作者亲自剖析其内部设计，涵盖 SQLAlchemy、LLVM、Audacity、Apache、Bash 等系统。
编程与软件工程上首页 9 次 · 2011–2024aosabook.org编辑精选编程语言简史：简短、不完整且多半错误
A Brief, Incomplete, and Mostly Wrong History of Programming Languages
一篇以戏谑、故意不准确的方式回顾编程语言史的博客文章，用夸张轶事和讽刺定义串起 Lisp、C、C++、Java、JavaScript、PHP 等语言。
编程与软件工程上首页 8 次 · 2009–2021james-iry.blogspot.comSQLite 是如何测试的
How SQLite is tested
SQLite 官方文档页，系统介绍 SQLite 的测试体系：多种测试方法（TCL 测试、模糊测试、回归测试、静态分析等）和海量测试用例，展示了这个小型开源项目如何靠极致测试获得…
编程与软件工程上首页 8 次 · 2009–2025sqlite.org编辑精选高级编程语言（2009）
Advanced programming languages (2009)
Matt Might 的经典文章，按用途推荐“高级编程语言”：如果追求就业就选主流语言，如果追求表达力、学术研究或创业，则推荐 Haskell、OCaml、Scala 等函数式语…
编程与软件工程上首页 8 次 · 2009–2022matt.might.net我的 Forth 与栈机器经历
Yosefk - My history with Forth & stack machines
作者以亲身经历回顾了使用 Forth 语言和栈式机器的历程：既赞叹其简洁优雅、代码量小、可自举的优点，也坦率指出栈操作在实际编程中的痛苦，以及 Forth 社区文化中的问题。
编程与软件工程上首页 8 次 · 2010–2024yosefk.com编辑精选