编程与软件工程darkcoding.net
Facebook 的代码质量问题（2015）
Facebook’s code quality problem (2015)
2015 — 2017，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这篇 2015 年的文章批评 Facebook 的代码质量问题，作者用几个“证据”说明其工程文化（“快速行动，打破常规”）导致代码粗糙、依赖堆人力和蛮力解决问题。文章引发关于代码质量与业务速度如何权衡的长期讨论，2017 年再次登上 HN 首页。
为什么经久不衰：代码质量与快速迭代之间的矛盾是软件行业永恒的议题，Facebook 作为巨头案例让这场讨论至今仍有参考价值。
HN 评论精选
编程本质上是设计工作，而非施工，因此代码质量无法靠分层外包解决
我把编程完全看作设计，无论是有意还是无意。Martin Fowler 让我彻底明白了这一点：有人借鉴建筑业，认为可以由少数高薪架构师画图纸，再雇廉价劳动力施工，这导致软件公司出现“架构师”与“普通程序员”的二分。但正如 Jack Reeves 所说，源代码其实就是设计文档，真正的“施工”只是编译和链接。编程中几乎没有重复性的体力活，因为凡是能当作施工的部分都应被自动化。所以在软件中，所有工作本质上都是设计。
combatentropy查看英文原文
I look at programming as all design, whether deliberate or not. Martin Fowler drove the point home for me (https://www.martinfowler.com/articles/newMethodology.html). He said that some people drew inspiration from construction, where there are designers and builders. One or two highly paid architects draw up the plans. Then you can hire a bunch of cheap labor to build it, say a bridge. This belief leads to a dichotomy in software companies, where one person is the "architect" and others are just "regular" programmers --- often outsourced to the lowest bidder. From Jack Reeves he cites the epiphany "that in fact the source code is a design document and that the construction phase is actually the use of the compiler and linker." There is little repetitive, mindless work in programming, because as most of you know, "anything that you can treat as construction can and should be automated." Therefore, "In software all the effort is design . . ."
工程师休假时故障减少是正常现象，不能作为代码质量差的证据
“证据 C：工程师休假时网站反而更稳定”和“心脏外科医生休假时病人死亡率更低”没什么区别——没人改动代码时网站当然更可靠！如果稳定不是常态、需要不断改动才能维持运行，那才真正值得担心。
charleslmunger查看英文原文
"Exhibit C: Our site works when the engineers go on holiday" Is not all so different from "Fewer patients die when heart surgeons are on vacation". Of course your site is going to be more reliable when nobody is changing it! You should be worried if reliable isn't the steady state, and it requires constant changes to stay up!
快速出活的团队比收拾烂摊子的团队处境更好，这是质量被牺牲的现实原因
以牺牲代码质量为代价快速上线功能，在商业上确实难以反驳。但我发现团队分两种：A 类团队“快速行动、打破常规”、创造商业价值；B 类团队“只维护遗留代码”、“什么都做不出来”、“花钱多”、“抱怨太多”。作为工程师，在 A 类团队工作更轻松也更有回报。
thedevil查看英文原文
It's hard to argue with the business sense of pushing out features quickly at the cost of code quality. But I've learned that that there are two kinds of development teams: (A) the teams that are "moving fast and breaking things" while "creating business value" and (B) the teams that are "only maintaining legacy code", "not getting anything done", "costing a lot of money" and "complaining too much" about code quality that team A wrote. As an engineer, I've learned that it's less work and more rewarding to be on the (A) teams than on the (B) teams.
靠不断加人掩盖技术债不可持续，最终需要文化层面的根本转变
“证据 C”让我笑得最开心。虽然文中图表没有 Y 轴、也没说明故障的代价，很多公司可能都有类似曲线。至于不断往问题里扔工程师：当 iOS 团队停止扩张时，痛苦就会到来——新工程师没有新项目可做，老工程师全在维护现有系统，没人有空开发新东西。这种剧本在很多公司上演过，最后会成立一个小组来偿还技术债，但除非文化发生根本转变（如 2003 年微软对待安全那样），否则很难成功。
icefox查看英文原文
I must say I haven't smiled so much as with Exhibit C: Our site works when the engineers go on holiday In their defense I wouldn't be surprised if many companies had similar graphs especially as there was no Y axis and there is no cost associated with incidence, but still worth a chuckle. As for just tossing more engineers at a problem it is going to be painful when they decide to stop adding engineers to work on the iOS app. Suddenly you don't have new devs with nothing on their plate ready to make new software, but all you have is engineers that are spending most (if not all) of their time maintaining what they have so there will be not many devs free to build stuff and those that are will take a while to get it done given the little free time they have to devote to the effort. This has played out many times before at many other companies. Soon a little group will be formed to reduce the technical debt and improve the architecture. They will do their best, but have a hard time unless there is a fundamental shift in culture (think Microsoft with security in 2003).
历次讨论
同类还值得读
开源应用架构
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编辑精选