关于软件设计的言论

写在前面

这是一篇译文，原文由glenn@vanderburg.org收集和发表，觉得有意思就摘抄翻译了一下，并批注了个人理解。

内容不少，请耐心看完，后面有很多还是很精彩的，如果感兴趣，可以搜索原文阅读。

正文

简单是效率的灵魂。

— Austin Freeman (in The Eye of Osiris)

简单的东西要做到却不简单。

— Bertholdt Brecht

（注：这里强调“简单”和“难”的辩证关系）

Unix 并没有被设计为阻止人们做愚蠢的事情，因为那也会阻止他们做聪明的事情。

—Doug Gwyn

（注：这句也很精彩，聪明和愚蠢都很需要自由发挥的空间）

系统的设计者必须全身心参与系统的实施，不仅必须是系统的实施者和第一个重度使用者，而且还应该编写第一个用户手册。如果我没有充分参与所有这些活动，实际上永远不会有数百项改进，因为我永远不会想到它们，或意识到它们为什么重要。

–Donald E. Knuth

（注：总体的意思等同于英语俚语”吃你自家的狗粮”，自己真正用了才知道）

用“烂”语言编写的代码，比用“好”语言编写的代码要多得多。

—Bjarne Stroustrup (in The Design and Evolution of C++, 1994)

（注：这里应该强调的是好代码重在设计，而不会受语言的制约）

我看不到有任何问题存在，即使那些被认为复杂的，当你以正确的方式看待它时，它并没有变得更加复杂。

—Poul Anderson

（注：这里应该说的是有些复杂性是相对的。当我们认为复杂时，可能是我们缺少相关知识，或则看待事物的角度不对）

有两种构建软件设计的方法。一种是让它变得如此简单，以至于显然没有任何缺陷。而另一种是让它变得如此复杂，以至于没有明显的缺陷。

—C.A.R. Hoare

良好的设计，便于引入新特性。这虽然做起来难，但却是成功之道。

—Dennis Ritchie

（注：应该是通过“良好”、“便宜”、“难”、“成功”这个几个关键词的辩证关系，指出软件开发要重视设计。

这句很难翻译，翻成这样，不知道Dennis会不会拿板砖来找我。）

简单的事情做到简单，复杂的事情才成为可能。

—Alan Kay

（注：复杂是由简单构成的，如果我们秉持把简单的事情做简单这个原则，那么复杂的事情应该也是水到渠成）

过早的优化是编程的万恶之源。

—C.A.R. Hoare

（注：应该是避免过度设计、超前设计的意思，和在真正发生时重构的思想应该一样）

喂鸟（Bird-feeding）在消费、助记、评论中非常合适，但要避免在协议中使用。

—John Klensin

（注：猜想Bird-feeding是指缩写词，类似于聊天简写词，不太确定，如果是这个意思，整句的意思应该是编程中注意规范命名，懂行的可以帮忙看一下这样翻译是否OK）

使用C++的问题是，该语言有一种强烈的倾向，要求在做任何事情之前都已经知道一切。

—Larry Wall

（注：没用过C++，是在所C++很原始吗？这句话好玩的地方应该是Anything（任何事）和Everything（一切）这两个词）

性能的关键是优雅，而不是特殊情况的“营地”。除非回 很明显，否则应该抵制可怕的“诱惑”。

—Jon Bentley and Doug McIlroy

（注：对特殊情况的处理，是复杂的开端，和性能的毒药。要确保软件性能，需要保持简单和优雅，避免过多考虑特殊场景。）

应该指出，没有受过道德培训的软件工程师会同意编写“DestroyBaghdad”（摧毁巴格达）程序。相反，基本的职业道德会要求他编写一个“DestroyCity”（摧毁城市）程序，其中“Baghdad”可以作为参数。

—Nathaniel S. Borenstein (This was a footnote in a 1992 peer-reviewed journal paper.)

（注：应该是在说“保持基本的通用性和扩展性，是程序员的基本职业道德”）

生命是短暂的，而技艺却需要如此长时间的学习。

原文：The lyf so short, the craft so long to lerne.

—Geoffrey Chaucer

（注：语自中世纪晚期作家Geoffrey，强调熟练技艺需要时间，而生命却是短暂的。

根据一万小时定律，普通人只要经过一万小时的锤炼，就能成为专家。

做技术的应该持之以恒，也应该抱有终生学习的心态）

如果你多年来一直用额头敲钉子，当有人第一次递给你锤子时，你可能会觉得很奇怪。但这并不意味着你应该把锤子绑在头上，让你的头骨感受到古老的熟悉的震动。

—Wayne Throop

（注：很有意思的一句话，和另一句“手里拿个锤子，看什么都像钉子”有异曲同工之妙，可以让我们感受习惯的力量，领会审时度势，灵活应变的必要性。

对于技术人来说，新手期间需要根据专家指导循规蹈矩，但熟练之后，要学会跳出框框限制，因时制宜，因地制宜，不要僵化）

有些功能不应该使用，有些概念不应该被创造，有不应该解决的问题，有不应该写的程序。

—Richard Harter

（注：对于软件开发人员来说，需要认识到，并不是所有的问题都要解决，也并不是所有的问题都要通过编程解决，在编程之前，要学会寻求编程之外的解决之道）

编写代码，并不是一种对男子汉气概的练习。

—Richard Harter

（注：完全没概念，难道是说编写代码，需要耐心和细致？）

这个世界的问题是：愚蠢的人自信满满，聪明的人充满怀疑。

—Bertrand Russell

（注：说的应该是认知曲线里的道理，“不知道自己不知道”的人是可怕的）

运气是设计的残余。（Luck is the residue of design）

—Branch Rickey

（注：不知道您怎么理解，我认为是在从侧面说明设计的好处，我们只有预先做了足够良好的设计，在未来就可以因此带来收益）

我认为心理分析针头（psychoanalyze-pinhead）是 GNU Emacs 的重要一课。

—Bennett Todd

如果不定期查看封面以确保它不是一本关于软件设计的书，就很难通读一本关于魔法原理的书。

—Bruce Tognazzini

吹牛者让清楚变模糊，思考者让模糊变清楚。

—Hugh Kingsmill

真正紧密的界面是在书和读者之间，书中的世界直接插入你的大脑，更不用说[虚拟现实]紧身衣了。

—Bill McKibben (in The Age of Missing Information)

（注：应该和界面设计有关，“虚拟现实”可能是界面设计的一种有效方法）

好的判断是经验的结果，经验是坏判断的结果。

—Fred Brooks

程序必须是为人们阅读而编写的，只是偶然地为机器执行而编写。

—Abelson and Sussman

一种什么都没有的语言实际上比有一些的语言更容易编程。

—Dennis Ritchie

设计师可以用几个月的时间仔细考虑复杂的设计，之后他突然想到了一个简单、优雅、美丽的解决方案。当它发生在你身上时，感觉好像上帝在说话！也许他是。

—Leo Frankowski (in The Cross-Time Engineer)

（注：这种事情经常有吧，只不过我们常常是匆忙做了决定）

编程语言的设计不应该通过在特性之上堆积特性，而应该在设计上努力消除那些需要附加特性的弱点和限制。

–from Revised4 Report on the Algorithmic Language Scheme

（注：说的是关于编程语言的设计，不应该打补丁，而是优化本身的设计，消除打补丁的必要。在一般软件开发中，应该也是这个道理。）

幼稚者喜欢花哨和新奇，成熟者喜欢平凡和普通。

—Erik Naggum

添加功能的成本不仅仅是编码所需的时间，还包括未来功能扩展的障碍。解决该问题的方法是选择让功能之间不相互冲突。

—John Carmack

（注：应该是“正交设计”的表述）

有了正确的价值体系，做出好的短期决策就会带来好的长期结果。我认为这是价值体系的目的。我们需要找出生活方式，以便在我们中年时“做正确的事”。当我们的邻居过来和我们争论时，我们不会开始考虑这会如何影响我们十年后的生活，而是根据我们被教导的方式和我们自学的方式做出反应。

—Ralph Johnson

（注：有了正确的价值观，短期决策不会偏颇，更不会影响长期目标）

理想的工程师是一个复合体。他既不是科学家，也不是数学家，既不是 会学家，也不是作家，但他可能会使用任何或所有这些学科的知识和技术来解决工程问题。

—N. W. Dougherty

对学习的研究告诉我们，从实验到反馈的时间延迟是至关重要的。

—Kent Beck (in Wiki:IsExtremeProgrammingWacko)

讲真，我们并不认为自己是完美主义者。对我们来说，更多的只是尽量让它听上去是好的，不管多少。

—Donald Fagen

发现的最大障碍不是无知，而是知识的错觉。

—Daniel Boorstin

（注：无胜于有的情况）

任何进展都不能停留在其最初的计划上，我们不妨想想在婴儿的摇篮里摇晃一个成年人。

—Edmund Burke

（注：计划赶不上变化，唯一不变的就是变）

灵感来自于写作。

—Steven Dunn

设计和编程是人类活动。如果忘记这一点，一切都将消失。

—Bjarne Stroustrup

极简自极繁。

—Winston Churchill

（注：关于语录，丘吉尔还真是高产啊，而且很多话很有道理和激励性，大家可以上语录 看一下）

除了变化，没有什么是永恒的。

—Heraclitus

对于数据库人员来说，每个指甲看起来都像一个拇指。或类似的东西。

—Jamie Zawinski

（注：这里有DBA吗？求救，完全Get不到啊）

如果您甚至不知道自己在说什么，那么对某事进行精确描述是没有意义的。

—John von Neumann

（注：先想明白再说，能够三句话说清楚，就说明想明白了）

牛顿是个天才，但不是因为他大脑的超强计算能力。相反，牛顿的天才在于他将世界简化、理想化和流线化的能力，因此在某种程度上，完全普通人的大脑可以处理它。

—Gerald M. Weinberg

（注：普通人也可以成为牛顿，你不高兴吗？）

写作的技巧是创造一个其他人可以思考的环境。

—Edwin Schlossberg

没有一点歪门邪道的Java开发将是一个沉闷的地方，也是一个危险的地方。

—Bruce Tate

（注：有懂得吗？）

首先听取用户的意见，然后忽略它们。

—Ken Arnold

（注：是“手中无剑，心中也无剑”吗？歪果仁也这么虚吗？）

Ajax 真正重要的一点是，它诱使我们采用了一种非常强大的语言，而我们本来不会选择自己这样做。

—Stuart Halloway

（注：是在说JavaScript比VBScript强大吗？）

设计中最难的部分，是将功能排除在外。

—Donald Norman

（注：设计求简，而某些功能要不要舍弃的确是个纠结的事情）

简单并不意味着缺乏或贫困，并不意味着没有任何装饰，或绝对的裸露，只意味着装饰应该与设计密切相关，任何与它无关的东西都应该被去除。

—Paul Jacques Grillo

（注：好的，装饰应该与设计密切相关）

敲响仍能响起的钟，忘记你为完美的付出，万物皆有缝隙，光就是这样进来的。

—Leonard Cohen

（注：应该是讲不要过度追求完美无缺，缺陷本身就是一种美，不是吗？）

每个任务都涉及约束，我们只管去解决问题，这是因为有魔法链条可以帮助我们放松僵硬的大脑。结构，还是结构，尽管它们捆绑在一起，但神奇地解放了我们的思想。

—James Falen（詹姆斯·失败）

（注：这句话我不太懂，我是冲着语录者名字来的，她让我想起了东方不败，你信吗？）

美在技术中最为重要，因为软件是如此复杂，而美是抵御复杂性的终极防御。

—David Gelernter (in Machine Beauty: Elegance and the Heart of Technology)

（注：牛掰，这句话我喜欢）

简单是这个世界上最难保证的事情，这是经验的最后极限，也是天才的最后努力。

—G.Sand

（注：又是关于简单的，差点以为这位先生名字只有一个G字）

简单的（写作）风格是非常努力的结果。

—William Zinsser

设计是拆分、分组、抽象和隐藏的艺术，设计决策的支点是变化，将那些因不同原因而改变的事物分开，将那些因相同原因而改变的事物组合在一起。

—Uncle Bob Martin（鲍勃·马丁叔叔）

（注：话说得到位，可是也不能名字里带“叔叔”啊，上来就让人叫你叔叔，不带这么玩儿的，太会占便宜了）

我们这个时代的悲剧是我们已经倒退了，我们学会了热爱技术而使用人。

—Herb Kelleher

（注：可能是在说人才是创造力的源泉，舍本逐末的意思）

一切都是模糊的，直到你试图让它变得精确时，你才会意识到。

—Bertrand Russell

（注：这种说了等于没说的话，最可怕了）

系统程序员是低级邪教的高级祭司。

—Bob Barton

（注：有意见去找Barton去，这可不是我说的）

雄心勃勃的系统的普遍问题是复杂性。[…] 强调简单和优雅的价值很重要，因为复杂性会带来困难。

—Fernando J. Corbató

（注：看来都被复杂性整怕了）

当我解决问题时，我从不考虑美，我只想如何解决问题。

但是当我完成后，如果解决方案不够漂亮，我知道它是错误的。

–R. Buckminster Fuller

（注：这人说话怎么大舌头呢？算了，看你名字这么长的份上，放过你了）

简单和优雅是不受欢迎的，因为它们需要努力和严格才能实现，需要教养才能欣赏。

—Edsger Dijkstra

（注：追求点好的东西就这么难吗？上帝在哪儿？咱们找个地儿聊聊）

简单地解决问题只是使解决方案看上去透明。

—Herbert Simon

（注：好的，简单=清晰）

架构是耦合和内聚之间的张力。

—Neal Ford

（注：算你狠）

编程是应用数学中最难的分支之一。

—Edsger W. Dijkstra

任何人都可以在一天内学会 LISP，但如果他们已经会 Fortran，则需要三天时间。

—Marvin Minsky

（注：都喜欢这么互黑吗？）

软件中如此多的复杂性来自试图让一件事做两件事。

—Ryan Singer

（注：好的，妈妈叫我回去收衣服了）

抽象的目的不是模糊，而是创造一个新的语义层次，在这个层次上可以绝对精确。

—Edsger Dijkstra

值得攻击的问题通过反击来证明它们的价值。

—Piet Hein

（注：好的，你打我说明你还在意我）

简单、明确的目的和原则会产生复杂、智能的行为。

复杂的规章制度导致简单、愚蠢的行为。

—Dee Hock

（注：我说我怎么这么蠢呢，原来是规章制度的问题）

程序员在其职业生涯的前 5 年里掌握复杂性，而他们的余生则在学习简单性。

—Buzz Andersen

（注：厉害，你是怎么知道的？这个和一万小时定律合上了）

庞杂、杂乱和不清晰不是信息的属性，它们是设计的失败。

—Edward Tufte

（注：汉语一个“乱”字，英语却分了很多种）

最好的性能提升是从非工作状态过渡到工作状态。

—John Ousterhout

一周的编码通常可以节省一个小时的思考时间。

—Josh Bloch

（注：对了，爱因斯坦说过，如果我有一小时拯救世界，我会花55分钟去确认问题为何，只以5分钟寻找解決方案。）

简单是我们必须为可靠性付出的不可避免的代价。

—C.A.R. Hoare

（注：你们这些人都好虚伪，想要简单就直说吗？还要扯上可靠性）

好的设计增加价值的速度快于增加成本的速度。

—Thomas C. Gale

使软件设计变得困难的事情是，我们必须使用一种不包含许多我们习惯的表达特征的语言来表达对一个我们通常不完全理解的问题和解决方案的想法，以一个不容忍错误的系统。

—Alistair Cockburn

（注：好吧，老哥，你赢了，你字多，你说话不用换气）

软件正确性的问题最终归结为：“它是否做到了我们的想法，甚至是我们尚未考虑的事情？”

—Alistair Cockburn

不要用魔法子弹射中自己的脚。

—Gerald Jay Sussman

（注：老兄，你还在吗？我试了，一点儿也不疼，只是感觉身体越来越麻了）

约束不是限制，是洞察力。

—Steve Sanderson

如果你是一个有创造力的人，那么你永远不会真正下班，连睡觉都觉得很有创意。

—Jennifer Carpenter

（注：完全同意，不接受反驳，我就是个特别爱睡觉的人）

让计算机知识见鬼去吧，学习它绝对是荒谬的。只需要学习数学，学会思考，读，写。

—Butler Lampson

（注：计算机=数学+思考+读+写）

矛盾之处在于，当管理者专注于生产力时，很少能实现长期的改进，而当管理者关注质量时，生产力会不断提高。

—John Seddon

（注：生产力可能和创造力有关，拒绝束缚）

魔法的唯一秘诀是，我愿意在那些你认为不值得的事上付出努力。

—Penn Jillette

（注：Penn，我认为你根本不值得给我一百万美金）

人们会忘记你完成工作的速度有多快，但他们会记得你做得有多好。

—Howard Newton

我们科学界被数学的成功宠坏了，数学是研究非常简单的问题，以至于它们有很好的解决方案。

—Whitfield Diffie

（注：这么狂吗？难道是因为数学要解决的问题都已经定义清楚了？）

我不知道接下来我需要学习什么，但这可能是我以前认为无用的东西。

—John D. Cook

你不用付钱给工程师写代码，你只需付钱让他们理解问题的玄机和边界，代码只是它们的附属物。

—Ted Dziuba

（注：有句老话说得好，当你认识到问题时，问题就解决了一半了）

抽象的目的是隐藏不需要的属性，而不应该隐藏想要的。

—Butler Lampson

（注：妈妈说，钱财莫外露）

只要有足够的决心，软件中的几乎任何东西都可以实现、销售甚至使用。一个单纯的科学家说不出什么话，能抵挡住一亿美元的洪流。但有一种品质无法以这种方式购买，那就是可靠性。可靠性的代价是追求极致的简单，这是非常富有的人最难以付出的代价。

—C.A.R. Hoare in The Emperor’s Old Clothes

（注：嗯，钱买不来的，还有爱情）

如果您认为好的架构很昂贵，请尝试糟糕的架构。

—Brian Foote and Joseph Yoder in Big Ball of Mud

一个好的设计不是正确预测未来的设计，而是让适应未来变得负担得起的设计。

—Venkat Subramaniam

您可以像优化性能一样过早地优化可维护性、灵活性、安全性和健壮性。

—John Carmack

编程的艺术是组织复杂性的艺术，是掌握众多事物并尽可能有效地避免其混沌的艺术。

—Edsger Dijkstra

在软件开发中，没有比代码本身所捕获的更高级的设计细节了。

—Kevin Hooke

（注：这是代码即文档的翻版吗？）

设计很大程度上取决于约束。

—Charles Eames

一个不断发展的系统会增加其复杂性，除非采取什么措施来降低它。

—Meir Lehman

事情就是这样，因为它们就是那样的。（Things are the way they are because they got that way.）

—Gerald Weinberg

（注：道可道，非常道）

有时候，问题是要发现问题是什么。（Sometimes the problem is to discover what the problem is.）

—Gordon Glegg

一个运行的复杂系统总是被发现是从一个运行的简单系统演变而来的。相反的命题似乎也是正确的，从头开始设计的复杂系统永远不会起作用，也不能使其起作用。您必须重新开始，从一个简单的系统开始。

—John Gall (this is known as “Gall’s Law”)

编程是一次只做一件事的艺术。

—Michael Feathers

（注：拆分和专注在开发中很重要，不是吗？）

先让它工作，然后让它漂亮，然后如果你真的，真的必须，那么就让它快点。90% 的情况下，如果你让它漂亮，它已经很快了。所以实际上，只是让它漂亮而已！

—Joe Armstrong

（注：好看能当饭吃，是这么来的吗？）

促进“自然语言”编程的项目本质上注定要失败。

—Edsger Dijkstra

从来没有一个称为正确的解决方案，但总是有多个错误的。

—Dave Akin (Akin’s Laws of Spacecraft Design, #12)

复杂是世界的本来，而简单是思想。

—Donald Norman

巨大的变化是一种幻觉，其实所有的变化都很小，只是反馈周期的长短而已。

—Kent Beck

沟通中最大的一个问题是它已经发生的错觉。

—George Bernard Shaw

理解总是有力量的。（There is always power in understanding.）

—Alton Brown

所有模型都是错误的，但有些是有用的。

—George Box

（注：错误不代表无用）

测试导致失败，失败导致理解。

—Burt Rutan

程序员，就像诗人一样，工作只是稍微远离纯粹的思想。他们在空中建造城堡，从空中，通过发挥想象力来创造。

—Fred Brooks in The Mythical Man-Month

（注：很多年以后，有人会说我们的时代是个像唐朝那样的时代吗？）

缺乏自然数学规律的保证，人文科学比火箭科学难多了。

—Edward Tufte

写在末尾

写的过程中发现，其实有很多收集语录的 站，英文的，中文的都有，英文的搜索关键词quotes就可以了，中文的搜索语录 ，也有好几个。很多语录还是很精彩的，可以给迷茫中的我们点亮一盏明灯，带来一丝温暖，你觉得呢？