编程与软件工程overreacted.io编辑精选
再见，整洁代码
Goodbye, Clean Code
2020 — 2021，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
本文中 Dan Abramov 回忆自己曾为消除重复、追求“干净代码”而直接重写同事的代码并提交到 master，后来意识到这次重构并不值得。他由此反思：不要做整洁代码的原教旨主义者，重复有时比错误的抽象更便宜，未经沟通就重写同事代码也是糟糕的协作方式。
为什么经久不衰：它用作者亲身踩坑说明盲目追求 DRY 和整洁代码可能带来错误抽象，并提醒团队协作与流程同样重要，因此多年后仍值得一读。
HN 评论精选
提出“偶然重复”概念，建议不要一看到重复就抽取，先让代码演化，再根据实际变化决定是否重构。
我常把这种现象叫“偶然重复”，也经常给初级工程师讲。很多情况下，3-5 行代码在多个方法里遵循相同模式，看起来很烦人，“不要重复自己！”对吧？于是你把这堆样板抽成一个方法，一开始没问题，直到下一次改动：你需要给辅助方法传选项和配置……很快它就极难理解，因为它在处理十几个表面相似、细节却充满重要差异的情况。我建议一条经验法则：不要立刻抽取重复代码，先带着重复把功能做出来，让代码经历几轮演化。然后很可能发生两件事之一：(1) 你发现代码看起来没那么重复了；或 (2) 你遇到一个 bug，需要把同样的改动改到六处样板代码里，而你漏了一处。场景 1 里，你可以叹口气说“原来是偶然重复，现在不困扰我了”；场景 2 里，可能就该仔细重构，把已经证明相同、而且必须在所有实例中相同的部分抽出来。
burlesona查看英文原文
I’ve usually heard this phenomenon called “incidental duplication,” and it’s something I find myself teaching junior engineers about quite often. There are a lot of situations where 3-5 lines of many methods follow basically the same pattern, and it can be aggravating to look at. “Don’t repeat yourself!” Right? So you try to extract that boilerplate into a method, and it’s fine until the very next change. Then you need to start passing options and configuration into your helper method... and before long your helper method is extremely difficult to reason about, because it’s actually handling a dozen cases that are superficially similar but full of important differences in the details. I encourage my devs to follow a rule of thumb: don’t extract repetitive code right away, try and build the feature you’re working on with the duplication in place first. Let the code go through a few evolutions and waves of change. Then one of two things are likely to happen: (1) you find that the code doesn’t look so repetitive anymore, or, (2) you hit a bug where you needed to make the same change to the boilerplate in six places and you missed one. In scenario 1, you can sigh and say “yeah it turned out to be incidental duplication, it’s not bothering me anymore.” In scenario 2, it’s probably time for a careful refactoring to pull out the bits that have proven to be identical (and, importantly, must be identical across all of the instances of the code).
反对作者对“未经沟通重写同事代码”的自责，认为代码属于公司，应该鼓励直接改进并从中学习。
我完全不同意，百分之一百万不同意！如果你在我的团队里，想重写我写的代码（因为它很烂），那就去做！别问，直接做！现在就做！尽情发挥，把它拆开，重写我所有糟糕的抽象，看看你能不能做得更好。如果结果代码更好，那太棒了！我学到东西，软件也变好。如果结果更差，那也很棒！我会告诉你为什么，你学到东西，而你提升的理解会让你写出更好的代码。我还认为，一个拿工资的工程师觉得自己写的某段代码是“他/她的”是完全错误的。那是公司的代码。对代码有虚假的归属感只会给工程师自己带来痛苦，给团队带来摩擦。
bjourne查看英文原文
> Firstly, I didn’t talk to the person who wrote it. I rewrote the code and checked it in without their input. Even if it was an improvement (which I don’t believe anymore), this is a terrible way to go about it. A healthy engineering team is constantly building trust. Rewriting your teammate’s code without a discussion is a huge blow to your ability to effectively collaborate on a codebase together. I totally disagree one million percent! If you are on my team and you want to rewrite code I wrote (cause it sux) then do it! Don't ask, just DO IT! DO IT NOW! Have a blast, tear it apart, rewrite all my shitty abstractions and see if you can do it better. If the result is better code, then awesome! I learn something and the software gets better. If the result is worse code, then awesome! I'll tell you why, you'll learn something and your improved understanding will allow you to write better code. I also think that a salaried engineer who thinks that a piece of code he or she (but almost always he) wrote is "his" or "hers" is totally wrong. It's the company's code. Having a false sense of ownership towards that code will just cause grief for that engineer and friction for his or her team.
点出文章核心：重复的代价往往低于错误的抽象。
这个博客本质上是一段自我发现之旅，最终抵达了 Sandi Metz 的《错误的抽象》：“重复远比错误的抽象便宜。”
pydry查看英文原文
This blog is essentially a journey of self discovery arriving at https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction "duplication is far cheaper than the wrong abstraction."
指出真正的问题在于流程：没有 PR、代码审查和 CI，直接推 master 才是危险操作。
让我震惊的是，所有讨论里没人指出万恶之源：“当时已经很晚了（我太投入了）。我把重构直接提交到 master，然后带着解开同事乱码的自豪感去睡觉了。”没有 PR，没有代码审查，没有 CI。就是一个牛仔直接推 master。
pelasaco查看英文原文
I'm shocked that from all discussion nobody noted the root of all evil: "It was already late at night (I got carried away). I checked in my refactoring to master and went to bed, proud of how I untangled my colleague’s messy code." No PR, no code review, no CI. Just a cowboy pushing to the master..
历次讨论
同类还值得读
开源应用架构
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编辑精选