编程与软件工程users.ece.utexas.edu编辑精选
Rob Pike 的编程规则（1989）
Rob Pike's Rules of Programming (1989)
2014 — 2020，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这是 Rob Pike 1989 年提出的编程规则集合，核心包括：不要凭直觉猜性能瓶颈，先测量；不要过早优化；花哨算法在小规模下未必更快且更难写对；数据结构优先于算法。页面很短，反复强调把注意力放在数据建模和实际测量上，而不是做性能魔法。
为什么经久不衰：这些关于复杂度、过早优化和数据结构的建议跨越语言与时代，今天仍能防止工程师把简单问题过度设计。
HN 评论精选
用一个过度设计案例说明：未测量就加缓存和复杂查询，往往是在给极小数据添乱。
我希望大家能遵守这条规则，让东西先正常工作。我最近遇到职业生涯中最极端的例子：一次设计评审上，有人提议为一个不到 1GB、读量中等、写量极低的 MySQL 数据库加 Redis 缓存层和复杂的自定义查询方案，还想把大部分数据塞进 JSON 字段、在应用代码里管理 schema 演进。我们能不能先让东西正常工作？我并不喜欢 MySQL，但面对极小数据、近乎理想的使用场景，一个久经考验的通用技术大概率够用；至少在花几天设计并记录一堆花哨技巧、只为拯救被几 MB 数据压垮的 MySQL 之前，先给它一个机会。
dkarl查看英文原文
> Rule 1. You can't tell where a program is going to spend its time. Bottlenecks occur in surprising places, so don't try to second guess and put in a speed hack until you've proven that's where the bottleneck is. I wish people would follow this rule and just let stuff work. I recently encountered the most extreme version of this I've ever seen in my career: a design review where a guy proposed a Redis caching layer and a complex custom lookup scheme for a <1GB, moderate read volume, super low write volume MySQL database. And of course he wants to put the bulk of the data in JSON fields and manage any schema evolution in our application code. Can't we just let stuff work? I'm no fan of MySQL, but can't we admit that a ubiquitous and battle-tested piece of technology, applied to a canonical use case, on tiny data under near-ideal circumstances, is probably going to work just fine? At least give it a chance before you spend days designing and documenting a bunch of fancy tricks to save MySQL from being crushed under a few megabytes of data.
引用两位大师说明：数据结构比代码或流程图更能决定程序形态。
Torvalds 对规则 5 的版本是：“烂程序员担心代码，好程序员担心数据结构和它们之间的关系。” Brooks 的版本是：“给我看你的流程图，藏起你的表，我仍会困惑；给我看你的表，我通常就不需要流程图了——它会一目了然。”
jonahx查看英文原文
Torvalds version of rule 5: “Bad programmers worry about the code. Good programmers worry about data structures and their relationships.” Brooks's version: "Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowcharts; they’ll be obvious."
数据建模才是很多业务问题的真正瓶颈，而非写代码。
所有做无代码工具的人都在学习，或终将学到：多数企业的问题不是缺少编程能力，也不是不会实现算法，而是如何从一开始就以合理的方式组织和建模数据。
karl11查看英文原文
Everyone building no code tools is learning or will learn that the problem most businesses have is not a lack of coding skill, or the inability to build the algorithm, but rather how to structure and model data in a sensible way in the first place.
规则并非教条：热点分散时测量与调优更复杂，算法选择要看场景；规则 5 最可靠。
我职业生涯大部分时间都在做性能优化，这些规则有些成立，很多则不然。规则 2 只适用于你能判定当前性能“挺好”然后抽身走人的情况；如果你面对的不是一个占 80% 的热点，而是五个各占 16% 的温点，要拿到潜在 4 倍加速就得做五倍的思考。规则 4 是从糟糕实现出发的论证：花哨算法确实更难写对，但说一种算法比另一种“更容易有 bug”是什么意思？难道 Strassen 矩阵乘法里真埋着 bug？规则 3 也可疑，它暗示花哨算法在小 N 下的性能代价很重要，前提是你真的会大量执行它；也许只是选错了花哨算法。规则 5 是最好的一条，所以我喜欢能细致描述数据结构的语言。
glangdale查看英文原文
Having spent a great deal of time - most of my career, really, doing performance optimization, some of this rings true, but much of it doesn't. Rule 2 only applies if you can just decide that your current level of performance is "pretty great" and then parachute away to another project. Otherwise if you find that, instead of 1 hot spot taking 80% of your time, you have 5 warm spots taking 16% of your time, you have 5x as much thinking to do to fix your problems and get that potential 4x speedup (assuming you could get cut that 80% down by a factor of 16). Rule 4 is an argument from bad implementation. It's harder to get fancy algorithms right, but what does it mean to say an algorithm is buggier than some other algorithm. Are we seriously meant to think that there are some bugs buried in Strassen's matrix multiply? Rule 3 is dubious. It seems to imply that the performance cost of fancy algorithms on low N matters, which assumes that we are actually executing the algorithm quite a bit. Perhaps we've picked the wrong fancy algorithm? Maybe if you have a godzillion tiny matrix multiplies you shouldn't be using Strassen's but you might still get a performance win from doing something 'fancy' that's tuned for large numbers of small matrix multiplies... As for Rule 5, this is probably the best of the lot. That's why I like to use languages that allow me to describe my data structures in detail... even going so far as to say that the contents of my user-built containers have types. Ahem.
历次讨论
同类还值得读
开源应用架构
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编辑精选