编程与软件工程thereader.mitpress.mit.edu
专家级软件设计师的习惯
Habits of Expert Software Designers
2019 — 2021，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
MIT Press 为图书《Software Design Decoded》刊发的图解文章，罗列了专家级软件设计师的种种思考习惯：深入了解用户、刻意寻找优雅的抽象、聚焦问题本质、想清楚自己不做什么等。文章以条目式呈现，而评论区则围绕'这类经验清单到底有没有用'展开了激烈争论。
为什么经久不衰：它两度登上 HN 首页都引发同一场争论——专家经验能否被清单化传授，而评论区补充的实战心得（如编码前先做粗略估算）比清单本身更经得起时间检验。
HN 评论精选
清单式总结流于空泛，识别好设计本身就需要多年经验，规则帮不上忙。
这类清单往往流于陈词滥调，这篇也不例外。比如：'专家不满足于任意一种抽象，他们会刻意寻找优雅的抽象，让复杂结构得以高效地引入、理解和指代。'我交谈过的每个开发者都发自内心地相信自己正在这么做，然而 99% 的软件依然一塌糊涂——包括我自己的。回头看五年前写的东西全是垃圾，我的大部分工作就是在重写它们。没有捷径，光是能识别出好的设计就需要大量经验，更别提写出来了，十来条规则帮不上什么忙。这就像画画，'名画家的十个习惯'不可能让你成为伟大的画家。
WalterBright查看英文原文
These lists tend to be trite, and this one is no exception. For example, "Experts are not satisfied with just any abstraction, they deliberately seek elegant abstractions through which complex structures can be introduced, understood, and referred to efficiently." Every developer I've ever talked to believed down to their core that this was what they were doing. Yet 99% of software is utter bilge. This includes mine. I look at everything I've written 5 or more years ago, and it's all garbage. Most of the work I do is rewriting it. There's no way around it, it takes a lot of experience to be even able to recognize a good design, let alone write one. No list of 10 rules is going to help much. It's like painting. No "10 Habits of Famous Artists" is going to help you become a great artist.
没有相应实践经验的人读不懂这类清单，经验无法靠条目脱离场景传授。
这些要点（审视上下文的关键作用、关注用户、想清楚自己不做什么等）确实是软件开发的重要部分。但问题是，除非你已有足够的经验、能在实践中对应上这些条目，否则你无法真正理解这份清单，更不会因此改变做事方式。比如'始终了解用户'就太模糊了：哪些用户？怎么跟他们交流？什么时候该相信他们、什么时候不能照单全收？这类东西脱离真实场景是学不会的。
decasia查看英文原文
Most of these points (like the crucial importance of context/looking around, of users, of figuring out what you're not doing, etc) are important parts of software development. But the problem is, unless you already have the requisite experience to show you what these bullet points really refer to in practice, you're not going to really make sense of this list, not in a way that will actually help you do anything differently. "Always learn about the users" for example is much too vague: which users? how do you talk to them? when do you trust them and when do you not take their feedback at face value? I don't think you can learn this sort of thing outside of a real life context.
顶尖高手（如 Jeff Dean）的共同习惯是编码前做大量粗略估算，凭性能开销直觉快速筛选设计。
不知道书里有没有讲到这一点：我注意到 Jeff Dean、Martin Thompson 这类顶尖软件人才都热衷于做大量'信封背面式'的粗略估算。他们能在脑子里或纸上快速迭代设计，评估成本与价值，判断设计有没有前景、瓶颈和唾手可得的改进在哪，因为他们对分支预测失败、内存访问、每核内存带宽、磁盘寻道、网络延迟等各环节的性能开销有很好的直觉。换句话说，在写规格、动手编码之前，他们往往已经做过几十上百次粗略估算，把设计放进'大致正确'的区间。我认为正是这个习惯让他们与众不同。
jorangreef查看英文原文
I don't know if the book goes into this, but one thing I've noticed about brilliant software people like Jeff Dean or Martin Thompson is that they appear to love doing simple "back-of-the-envelope calculations" (and lots of them). They can iterate designs rapidly in their head or on paper, evaluate the cost or value of a design, know when a design has promise or when it won't work, and where the bottlenecks or low-hanging fruit might be, because they have a good feel for the performance/scaling cost of all the resources involved along the axes of things like branch mispredicts, main memory references, per core memory bandwidth, disk seeks, disk bandwidth, network latency, network bandwidth, expensive memory vs inexpensive storage tradeoffs. Numbers that programmers should know [1] but often don't. In other words, before they even write specifications or start coding, they've probably done tens to hundreds of back-of-the-envelope calculations to put their design in the "roughly right" ballpark. This drastically increase the chances that the design is going to work, and work really really well. And I think this habit is also what tends to set them apart. [1] https://colin-scott.github.io/personal_website/research/interactive_latency.html
逐条商榷：用户参与但不主导设计，'优雅'应改为'简单'，先抓本质再验证。
我的笔记：1）专家会让用户参与，但不会让用户来设计软件。用户常常想告诉你软件'必须'做什么，专家会先理解领域，再和用户一起找到合适的界面映射。2）'设计优雅的抽象'这点我不同意。我见过不少'专家'因为方案显得优雅、聪明而选用它，我自己也干过。专家设计的应是能让工作顺利完成、少费周折的简单抽象——把'优雅'换成'简单'就对了。专家的软件看起来朴素甚至笨拙，而不一定优雅聪明；当然，差的软件也可能看起来朴素。3）专家先聚焦本质，再通过测试验证提炼出的本质足以解决整个问题。
lmilcin查看英文原文
Hi, my notes: 1) Experts involve the user. Also, experts do not let the user design the software. The user will frequently want to tell you what the software "must" be doing. An expert will disregard this and will want to first understand the domain and then work with the user to find a good mapping to a useful interface. 2) Experts design elegant abstractions I don't agree on this. Oftentimes, I have seen "experts" use solutions because they seemed elegant, intelligent, "nifty". I did that myself. An expert will design simple abstractions that let the job done with little fuss. The software needs to be as simple as possible but not simpler than is needed. Replace "elegant" with "simple", and it sounds about right. An expert software looks dumb and simple, not necessarily super elegant and intelligent. Also, bad software can look dumb and simple. 3) Experts focus on the essence Experts start by focusing on the essence. Then verify by testing how the distilled essence is useful at solving entirety of the problem.
历次讨论
同类还值得读
开源应用架构
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编辑精选