编程与软件工程laputan.org编辑精选
大泥球（Big Ball of Mud，1999）
Big Ball of Mud (1999)
2013 — 2024，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
《大泥球》是 1999 年的经典软件工程论文，探讨为什么许多成功的软件系统最终演变成缺乏清晰架构、混乱生长的“贫民窟”式代码，并分析了这种模式为何反而常常行之有效。文章提出“贫民窟”等隐喻，指出在现实约束下，用普通材料和低门槛方式搭建的系统往往更能存活和扩展。
为什么经久不衰：它诚实面对软件熵增的现实：成功的系统必然持续变化，而过度抽象的架构反而难以适应未来，这一洞察历经二十多年依然成立，因此反复登上 HN 首页。
HN 评论精选
贫民窟隐喻精准：低门槛、可复制的做法虽然丑陋，却人人都能维护和扩展。
这篇文章是经典。“贫民窟是用常见、廉价的材料和简单工具建造的，可以由相对不熟练的劳动力搭建”——这个隐喻很有力，我在代码中经常见到。比如有人用和其他服务相同的 Web 框架写 API 网关：新建一个 Controller，在里面手写 HTTP 调用转发到内部服务。这很糟糕，每加一个端点都要手动扩展，但它不需要专门技能，团队里任何人都能照葫芦画瓢地加——这就是“贫民窟式”的 API 网关。
SideburnsOfDoom查看英文原文
The essay is a classic. > Shantytowns are squalid, sprawling slums. What is it that they are doing right? > Shantytowns are usually built from common, inexpensive materials and simple tools. Shantytowns can be built using relatively unskilled labor. This is a powerful metaphor, and I see it often in code. If you've ever seen an API gateway written using the same web framework as the other services, where in order to route "/external/order" to "/internal/order", the first step steps are e.g. "File | new | Controller", call it "ExternalController", make a GET method called "order", and in there code up a http call to "internal/order" ... you have a shantytown API gateway. It's terrible, it requires manual extending for any new endpoint. But it's not a specialised skill. Anyone on the dev team can extend it by just adding more of the same.
成功的系统必然持续演化，架构抽象是权衡，泥球化几乎不可避免。
这是所有软件开发者的必读文章。任何成功的软件系统最终都会变成大泥球或其他反架构，这是事物的本性。我们应该对抗熵增，但它几乎不可避免。软件要成功就得解决问题，而长期成功意味着必须不断改变和适应。架构通常意味着抽象，而抽象几乎总是权衡——牺牲灵活性来换取通用性和易用性。但问题在于：今天完美解决需求的抽象架构，明天不经过大改就无法解决新需求！
eric_b查看英文原文
This is required reading for all software developers. Any successful software system will end up as a Big Ball of Mud or other anti-architecture eventually. It's just the nature of the beast. And while we should fight the entropy, it will occur despite our efforts (there might be a few exceptions in the world, but for the most part it is inevitable) In order for software to be successful it needs to solve a problem. In order for that software to be successful in the long term it will have to change and adapt to continue solving the problem. Architecture usually means abstraction. And abstraction is most always a tradeoff - you sacrifice flexibility to make something common, easier. But there is the rub. A successfully abstracted architecture that solves the problem today, will not be able to solve the problem tomorrow without big changes!
反驳文中隐喻：许多混乱系统不是贫民窟，而是精心规划却失败的“住宅工程”。
文章说“太多软件系统在架构上不过是贫民窟，工具和基础设施投入不足，系统各部分无节制地生长，互相侵蚀污染”。我认为它们更像失败的住宅工程：称职的建筑师曾极力论证其作为解决现有问题的低成本方案，但这条路走不通，居住条件并不比贫民窟好。
tmcb查看英文原文
> All too many of our software systems are, architecturally, little more than shantytowns. Investment in tools and infrastructure is too often inadequate. Tools are usually primitive, and infrastructure such as libraries and frameworks, is undercapitalized. Individual portions of the system grow unchecked, and the lack of infrastructure and architecture allows problems in one part of the system to erode and pollute adjacent portions. Deadlines loom like monsoons, and architectural elegance seems unattainable. I would argue they are more akin to failed housing projects: competent architects went to great lengths to justify their existence as a cost-effective solution to an existing problem, but this approach didn't work and they offer no better conditions to their residents than shantytowns.
推荐此文，并补充推荐一篇关于团队无序演化的同类经典。
这是我最喜欢的两篇关于软件生产的文章之一，它讨论的是软件在不受控环境中的演化。我的另一篇最爱讨论的是技术团队在不受控环境中的演化。
smoyer查看英文原文
This is one of my (two) favorite essays regarding software production - it deals with the evolution of software in an uncontrolled environment. I just posted my other favorite "classic" essay which deals with the evolution of a technical team in an uncontrolled environment. Perhaps others will find it equally enlightening: https://news.ycombinator.com/item?id=22376468.
历次讨论
同类还值得读
开源应用架构
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编辑精选