编程与软件工程blog.pragmaticengineer.com
软件架构被高估，清晰简单的设计被低估
Software Architecture Is Overrated, Clear and Simple Design Is Underrated
2019 — 2022，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这篇文章讨论软件架构被过度神化、清晰简单的设计被低估。作者从实际项目出发，主张少套用架构术语和流行模式，用朴素的框线图把系统讲清楚，按实际需求做决策，避免过度设计。它并不是说不需要架构，而是强调架构应服务于理解和沟通。
为什么经久不衰：它把“何时该设计、何时该克制”这个工程团队的永恒难题讲得直白，所以多年后仍能引发从业者的共鸣与反驳。
HN 评论精选
从滥用设计模式转向极简务实后，生产力和可维护性反而更高；但简单是试错后的结果，不是偷懒。
头几年我只顾把事做完，确实完成了很多。接下来4-8年我开始玩花样，套用Factory、抽象、DI、Facade、Singleton等各种模式；跑通时感觉很好，但像杂耍，做一件事通常要动2-3个文件：UserFactory、UserService、UserModel、User。后来写代码成了负担，我对超过50个文件的项目都过敏。再往后4-5年，我立志只用务实、极简的方式写代码，这是最好的决定，也是我最高产的时期。现在多数项目除标准views/routes外核心文件不到10个，加入的开发者也能马上看懂；但保持简单不容易，需要大量试错，我写得更慢、代码更少，有时会花几小时给变量命名。
jaequery查看英文原文
First 1-3 years of coding, I just coded to get sht done. I got a lot of sht done. Next 4-8 years, I started getting cute with it and applied all kinds of design patterns, Factory, Abstractions, DI, Facade, Singleton you name it. It looked cute and felt good when it all worked but it was a juggling act. There was usually like 2-3 files to touch just to do one thing. UserFactory, UserService, UserModel, User, you get the idea. It got to a point coding now felt like a burden and I started getting allergic reaction to any projects that had more than 50 files. Next 4-5 years, I made it a mission to only code in a pragmatic, minimalistic way. Best decision I ever made, this have been the most productive time of my career. I don’t look back and never going back again. A simple require and requireAll with basic OOP is all I need on most cases. Most of my project now have less than 10 “core” files minus the standard views/routes/etc. I enjoy just working on code now it makes me happy and also any devs who joins loves it too as they get it right away. I code almost exclusively in Sinatra now btw. Express is great too but I think the ecosystem isn’t there yet for developer happiness. Keeping code simple is not easy. It takes a lot of trials and errors to know what works and what doesn’t. I realize I code a lot slower now than in the past and that I write much fewer lines of code. It’s both good and bad because sometimes I’d even spend hours just trying to properly name a variable. But I believe this pays off at the end. You just can’t best simplicity.
系统会随时间腐化，架构努力是对抗熵增和破窗效应，不能简单斥为多余。
看看作者的系统20年后还简不简单。作者在抨击一种从未存在的文化：银行架构师并不是抽着雪茄画UML丢给程序员。真实情况是，你先按需求设计，大家同意，一切顺利；随后新集成、新技术、客户需求和业务方向变化，原本整洁的系统开始变丑，人们为省时间把东西塞到不该放的地方，然后一路下滑。就像酒吧厕所：很干净你会保持，已经脏了就不想替别人清理，只添上自己的就走。软件也一样，一旦看起来不整洁，大家就用最省力的方式堆垃圾，心想“反正系统已经烂了”。说“那些人花几小时搞架构，其实只需要常识”有点太轻松。
d--b查看英文原文
Let’s see how the OP’s system looks in 20 years. Then we’ll see how clear and simple it has remained. The OP is railing against a culture that never existed. Banks software architects are not in their offices smoking cigars and making UML diagrams that they send to coders, only to realize later that they made the wrong trade off. What happens is: You design a system for what it’s supposed to do. You do it the way the OP says: nice ad hoc charts, talk to a lot of people, everybody agrees, all is swell. Then time goes by, new integrations are made, newer tech comes out, costumers need change, business orientation changes. And what used to be neat starts to become ugly. People cut corners by putting things where they don’t belong to save some time. And then it’s all downhill from there. There is a toilet analogy that works well. If you go to a bar and the toilet seat is very clean, then you’ll make sure to clean it before leaving. But if the toilet is already dirty, you’re not going to be the one cleaning other people’s pee, so you just add your own and leave. The same is true in software architecture, once it doesn’t look neat, everybody just pile up their crap in the way that demands the least effort. “The system is shit anyways”. I find it a little easy to say: “ha look at those guys, they spend hours trying to sort out system architecture, while all you really need is common sense”.
在大规模异构系统里，企业架构解决的是集成和标准化问题；“简单设计”在团队间并没有共同定义。
企业架构的价值只有你真正成为企业时才体现。我们运营300多个IT系统，来自众多且不断更换的供应商，由5000-7000名员工使用，从发工资、病人用药到时间预订。多数系统需要互操作，几乎都要访问员工数据。没有统一的企业架构标准前，300个系统各做各的，多数甚至没有API；想象在300个系统里手动管理5000-7000用户。这就是没有企业架构的世界，我们还在花数十亿纳税人钱补救，因为300个系统（有些跑在大型机COBOL上）不能一夜迁移。这只是一个市，还有97个市有同样问题。我同意文章大部分情绪，但开发者对“简单设计”看法差异很大；我集成过很多胶带代码，没有一个系统的API相似。
moksly查看英文原文
The value of Enterprise Architecture doesn’t come in to play until you’re an actual Enterprise. We operate more than 300 IT systems, from a myriad of different and switching (courtesy of procurement) suppliers. These systems are operated by 5000-7000 employees, and range from making sure employees get paid and patients get the right medicine to simple time booking apps. Most of these systems need to work together, and almost all of them need access to things like employee data. Before we had a national strategy for enterprise architecture, which defines a standard model for organisation data, all of those 300 IT systems did it their own way and most of them actually thought we liked that so they came with no APIs. Imagine having to manually handle 5000-7000 users in 300 different IT systems... That’s the world without Enterprise Architecture, and we’re still paying billions in taxpayer money to try and amend it. Because you don’t move 300 IT systems, some of them running on COBOL on mainframes, over night. And that’s just our municipality, there are 97 others with the exact same problems. Don’t get me wrong, I get the sentiment of the article and I actually agree with most of it. The thing is though, developers have very different opinions about what “simple design” is, I know, because I’ve build a lot of the gaffa-tape that integrates our 300 IT systems and not a single system has had remotely similar APIs.
文章是稻草人式标题党；真正的问题不是有无架构，而是架构好坏、是否清晰和可维护。
金句在这里：其实我们的做法原则上和大多数架构指南差别不大。整篇文章基本是标题党。作者似乎在反对一个定义不清的稻草人，最后自己也承认并非如此：他们是在做架构，只是不按“软件架构文献”来做。这有什么了不起？99%的公司都这样。重要的是所有软件都有架构；区别在于有些架构好，能满足需求；有些架构烂，脆弱、易故障、难维护、看着吓人；有些架构被清晰定义、理解并记录，有些只能靠大规模逆向工程才能理解。你可以选任一方式，这跟用不用UML、4+1、设计模式、DDD、事件溯源、微服务无关。
mindcrime查看英文原文
The money quote is here: Actually, our approach is not that different in principle, to most architecture guides. This whole article is basically clickbait. The author appears to be arguing against some ill-defined strawman, but in the end even concedes that that isn't true. They are doing architecture, they just aren't doing it according to "the software architecture literature". Whoop de freaking doo. That statement could be applied to probably 99% of companies out there. The important thing to realize is that all software has an architecture. The difference is, some software has a good architecture that makes it easy for it to meet its requirements, and some of it has shit architecture that makes it brittle, failure prone, impossible to maintain, and generally scary to look at. And also that some software has an architecture that is clearly defined and well understood and (gasp) documented in some way, where other architectures can only be understood by a massive reverse engineering effort. You can choose either approach, and all of that is orthogonal to whether or not you use UML, 4+1, Design Patterns, DDD, event sourcing, microservices, or whatever buzzword you want to rail against.
历次讨论
同类还值得读
开源应用架构
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编辑精选