程序员世界里有哪些名言警局呢？Jun Auza 列出了50条启迪人心的至理名言，它们大多来自产业界富于经验的人们。下文列出前10个供读者欣赏。

10. "People think that computer science is the art of geniuses but the actual reality is the opposite, just many people doing things that build on each other, like a wall of mini stones."- Donald Knuth

10. “人们认为计算机科学是天才的艺术，但事实完全相反：只是很多人在共同建立起来的事物之上工作，就像一条由小石头铺成的小径。”—— Donald Knuth

9. “First learn computer science and all the theory. Next develop a programming style. Then forget all that and just hack.”- George Carrette

9. “首先学会计算机科学和所有的理论。然后发展出一个编程风格。之后便要忘掉所有这些，以自由的方式探索。”—— George Carrette

8. “Most of you are familiar with the virtues of a programmer. There are three, of course: laziness, impatience, and hubris.”- Larry Wall

8. “大多数的你们都熟悉程序员的美德。它们有三点：懒，不耐烦，以及狂妄自大。”—— Larry Wall

7. “Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other,with no structural integrity， but just done by brute force and thousands of slaves.”- Alan Kay

7. “今日的大多数软件很像埃及金字塔，由千百万砖头堆砌起来，层层相切，没有着整体的结构，是由畜力和成千上万奴隶的力量建立起来的。”—— Alan Kay

6. “The trouble with programmers is that you can never tell what a programmer is doing until it?s too late.”- Seymour Cray

6. “程序员的问题是，不到太晚，你永远无法知道一个他在做着些什么。”—— Seymour Cray

5. “To iterate is human, to recurse divine.”- L. Peter Deutsch

5. “人理解迭代，神理解递归。”—— Peter Deutsch

4. "On two occasions I have been asked [by members of Parliament]: 'Pray， Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question."- Charles Babbage

4. “有两次我被（国会议员）问道：? Mr. Babbage，如果你输入计算机错误的数据，正确的答案会出来吗？?我完全无法理解能产生此种问题的大脑的混乱。”

3. "Most good programmers do programming not because they expect to get paid or get adulation by the public, but because it is fun to program."- Linus Torvalds

3. “大部分好的程序员编程并不是为了钱或名望，而只是因为纯粹的乐趣。”—— Linus Torvalds

2. "Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live."- Martin Golding

2. “编程的时候，总是想着那个维护你代码的人会是一个知道你住在哪儿的有暴力倾向的精神病患者。”—— Martin Golding

1. “There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.”- C.A.R. Hoare

1. “有两种生成一个软件设计方案的途径。一个是把它做得如此简单，以致于明显不会有漏洞存在。另一个是把它做的如此复杂，以致于不会有明显的漏洞存在。”—— C.A.R. Hoare 下面的就是软件编程中的21条法则：

1. 任何程序一旦部署即显陈旧。

2. 修改需求规范来适应程序比反过来做更容易。

3. 一个程序如果很有用，那它注定要被改掉。

4. 一个程序如果没用，那它一定会有很好的文档。

5. 任何程序里都仅仅只有10%的代码会被执行到。

6. 软件会一直膨胀到耗尽所有资源为止。

7. 任何一个有点价值的程序里都会有至少一个bug。

8. 原型完美的程度跟审视的人数成反比，反比值会随着涉及的资金数增大。

9. 软件直到被变成产品运行至少6个月后，它最严重的问题才会被发现。

10. 无法检测到的错误的形式无限多样，而能被检测到的正好相反，被定义了的十分有限。

11. 修复一个错误所需要投入的努力会随着时间成指数级增加。

12. 软件的复杂度会一直增加，直到超出维护这个程序的人的承受能力。

13. 任何自己的程序，几个月不看，形同其他人写的。

14. 任何一个小程序里面都有一个巨大的程序蠢蠢欲出。

15. 编码开始的越早，花费的时间越长。

16. 一个粗心的项目计划会让你多花3倍的时间去完成；一个细心的项目计划只会让你多花2倍的时间。

17. 往大型项目里添加人手会使项目更延迟。

18. 一个程序至少会完成90%，但永远完成不了超过95%。

19. 如果你想麻烦被自动处理掉，你得到的是自动产生的麻烦。

20. 开发一个傻瓜都会使用的软件，只有傻瓜愿意使用它。

21. 用户不会真正的知道要在软件里做些什么，除非使用过。

“设计是一个发现问题、而不是发现解决方案的过程” —— Leslie Chicoine

“功能说明书里不存在可操作性” —— 37 Signals

“过去的代码都是未经测试的代码” —— Michael Feathers

“任何傻瓜都能写出计算机可以理解的代码。好的程序员能写出人能读懂的代码” —— Martin Fowler

“测试是来表明bug的存在而不是不存在” —— Edsger Dijkstra

“简单不先于复杂，而是在复杂之后” —— Alan Perlis

“Real developers ship” —— Jeff Attwood

“没有绝世神功” —— Frederick Brooks

“过去的33年里，我每天早上看着镜子问自己：“今天是我生命的最后一天吗？我是否要去做今天该做的事？”一天一天太多次是“不是”，我知道这需要改变…所有的事情——所有身外的期望，所有的骄傲，所有的对困难和失败的恐惧——这些东西在死亡面前立刻消失的无影无踪，只剩下真正重要的东西。想着自己即将死去，这是让我避免落入担心失去什么的陷阱里的最好的方法。” —— Steve Jobs

“设计是一个发现问题、而不是发现解决方案的过程” —— Leslie Chicoine

“功能说明书里不存在可操作性” —— 37 Signals

“过去的代码都是未经测试的代码” —— Michael Feathers

“任何傻瓜都能写出计算机可以理解的代码。好的程序员能写出人能读懂的代码” —— Martin Fowler

“测试是来表明bug的存在而不是不存在” —— Edsger Dijkstra

“简单不先于复杂，而是在复杂之后” —— Alan Perlis

“Real developers ship” —— Jeff Attwood

“没有绝世神功” —— Frederick Brooks

“过去的33年里，我每天早上看着镜子问自己：“今天是我生命的最后一天吗？我是否要去做今天该做的事？”一天一天太多次是“不是”，我知道这需要改变…所有的事情——所有身外的期望，所有的骄傲，所有的对困难和失败的恐惧——这些东西在死亡面前立刻消失的无影无踪，只剩下真正重要的东西。想着自己即将死去，这是让我避免落入担心失去什么的陷阱里的最好的方法。” —— Steve Jobs

 

第二篇：程序员名言

软件在能够复用前必须先能用。

–Ralph Johnson

优秀的判断力来自经验，但经验来自于错误的判断。

–Fred Brooks

‘理论’是你知道是这样，但它却不好用。‘实践’是它很好用，但你不知道是为什么。程序员将理论和实践结合到一起：既不好用，也不知道是为什么。

–佚名

当你想在你的代码中找到一个错误时，这很难；当你认为你的代码是不会有错误时，这就更难了。

-Steve McConnell《代码大全》

如果建筑工人盖房子的方式跟程序员写程序一样，那第一只飞来的啄木鸟就将毁掉人类文明。

-Gerald Weinberg

项目开发的六个阶段：

充满热情

醒悟

痛苦

找出罪魁祸首

惩罚无辜

褒奖闲人

–佚名

优秀的代码是它自己最好的文档。当你考虑要添加一个注释时，问问自己，“如何能改进这段代码，以让它不需要注释？”

-Steve McConnell《代码大全》

我们这个世界的一个问题是，蠢人信誓旦旦，智人满腹狐疑。

–Bertrand Russell

无论在排练中演示是如何的顺利(高效)，当面对真正的现场观众时，出现错误的可能性跟在场观看的人数成正比。

–佚名

罗马帝国崩溃的一个主要原因是，没有0，他们没有有效的方法表示他们的C程序成功的终止。

–Robert Firth

C程序员永远不会灭亡。他们只是cast成了void。

–佚名

如果debugging是一种消灭bug的过程，那编程就一定是把bug放进去的过程。 –Edsger Dijkstra

你要么要软件质量，要么要指针算法；两者不可兼得。

–(Bertrand Meyer)

(有思想的话…)

有两种方法能写出没有错误的程序；但只有第三种好用。

–Alan J. Perlis

用代码行数来测评软件开发进度，就相对于用重量来计算飞机建造进度。

–比尔-盖茨

最初的90%的代码用去了最初90%的开发时间。余下的10%的代码用掉另外90%的开发时间。

–Tom Cargill

程序员和上帝打赌要开发出更大更好——傻瓜都会用的软件。而上帝却总能创造出更大更傻的傻瓜。所以，上帝总能赢。 –Anon

“设计是一个发现问题、而不是发现解决方案的过程” —— Leslie Chicoine

“功能说明书里不存在可操作性” —— 37 Signals

“过去的代码都是未经测试的代码” —— Michael Feathers

“任何傻瓜都能写出计算机可以理解的代码。好的程序员能写出人能读懂的代码”

——

Martin Fowler

“测试是来表明bug的存在而不是不存在” —— Edsger Dijkstra

“简单不先于复杂，而是在复杂之后” —— Alan Perlis

1. 无风不起浪

别紧张，这也许只是一场消防演习

代码设计是否糟糕，从某些地方就可以看出来。比如：

?a. 超大类或超大函数

?b. 大片被注释的代码

?c. 逻辑重复

?d. If/else嵌套过深 程序员们通常称它们作代码异味(Code Smell)

，但是就我个人认为“代码警报”这个名字更为合适一些，因为它有更高的紧迫感的含义。根本问题处理不当，终将引火烧身。

译注：Code Smell中文译名一般为“代码异味”，或“代码味道”，它是提示代码中某个地方存在错误的一个暗示，开发人员可以通过这种smell（异味）在代码中追捕到问题。

2. 预防为主，治疗为辅

好吧，我相信了！

20世纪80年代，丰田公司的流水作业线因为它在缺陷预防方法上的革新变得出了名的高效。每个发现自己的部门有问题的成员都有权暂停生产。这个方法意在宁可发现问题后马上暂定生产、解决问题，也不能由其继续生产而导致更棘手且更高代价的修复/更换/召回后的问题。

程序员总会做出生产率就等同于快速编码的错误臆断。许多程序员都会不假思索地直接着手代码设计。可惜，这种Leeroy Jenkins式鲁莽的做法多会导致软件的开发过程变得很邋遢，拙劣的代码需要不断的监测和修改——也可能会被彻底地替换。最终，生产率所涉及到的因素就 不仅仅是写代码所消耗的时间了，还要有调试的时间。稍不留神就会“捡了芝麻丢了西瓜”。（因小失大。）

译注：Leeroy Jenkins 行为：WOW游戏中一位玩家不顾大家独身一人迎敌，导致灭团。

3. 不要孤注一掷 （过度依赖某人）

一个软件开发团队的公共要素（bus factor）是指那些会影响整个项目进程的核心开发人员的总数。比如某人被车撞了或某人生孩子或某人跳槽了，项目可能就会无序，甚至会搁置。 译注： bus factor 即指公共要素，比喻了开发过程中的一些共同因素。如果挤上 bus 的 factor 越多，bus 就越不稳定，所以要控制好 bus factor ，以免问题发生。

换句话说，如果你的团队突然失去了一个主力成员，你会怎么办？生意依旧进行还是戛然而止？

很不幸，大多数软件团队都陷入了后一种情况。

这些团队把他们的开发员培养成了只会处理他们自己专业领域的“领域专家”。起初，这看起来是一个比较合 理的方法。它 对汽车制造装配生产线很适用，但是为什么对软件开发团队就不行呢？毕竟，想让每个成员都掌握所编程序的细微差别也不太可能，对吧？

问题是开发人员不容易轻易替换掉。虽然当每位成员都可用时，“抽屉方法”很有效，但如果当“领域专家”突然因人事变动、疾病或突发事故而无法工作 时，抽屉 方法立马土崩瓦解。（所以，）软件团队有一些看似多余实则重要的后备力量是至关重要。代码复查、结对编程和共有代码可用成功营造一个环境，在这个环境中， 每位开发人员至少表面上是熟悉自己非擅长领域之外的系统部分。

4. 种瓜得瓜，种豆得豆

《注重实效的程序员》一书中有这样一段话解释“破窗理论”：不要留着“破窗户”（低劣的设计、错误的决策或者糟糕的代码）不修。发现一个就修一个。 如果没有足够的时间进行适当的修理，就先把它保留起来。或许你可 以把出问题的代码放到注释中，或是显示“未实现”消息，或用虚拟数据加以替代。采取一些措施，防止进一步的恶化。这表明局势尚在掌控之中。

我们见过整洁良好的系统在出现“破窗”之后立马崩溃。虽然促使软件崩溃的原因还有其他因素（我们将在其他地方接触到），但（对“破窗”）置之不理，肯定会更快地加速系统崩溃。

简而言之，好的代码会促生好的代码，糟糕的代码也会促生糟糕的代码。别低估了惯性的力量。没人想去整理糟糕的代码，同样没人想把完美的代码弄得一团糟。写好你的代码，它才更可能经得住时间的考验。

译注：《注重实效的程序员》，作者Andrew Hunt / David Thomas。该书直击编程陈地，穿过了软件开发中日益增长的规范和技术藩篱，对核心过程进行了审视――即根据需求，创建用户乐于接受的、可工作和易维护 的 代码。本书包含的内容从个人责任到职业发展，直至保持代码灵活和易于改编重用的架构技术。从本书中将学到防止软件变质、消除复制知识的陷阱、编写灵活、动 态和易适应的代码、避免出现相同的设计、用契约、断言和异常对代码进行防护等内容。

译注：破窗理论（Broken Window theory）：是关于环境对人们心理造成暗示性或诱导性影响的一种认识。“破窗效应”理论是指：如果有人打坏了一幢建筑物的窗户玻璃，而这扇

窗户又得不 到及时的维修，别人就可能受到某些暗示性的纵容去打烂更多的窗户。发现问题就要及时矫正和补救。

5. 欲速则不达

经理、客户和程序员正日益变得急躁。一切都需要做的事，都需要马上就做好。正因如此，快速修复问题变得非常急迫。

没时间对一个新功能进行适当的单元测试？好吧，你可以先完成一次测试运行，然后你就可以随时回来继续测试它。

当访问Y属性时，会不会碰到奇怪的对象引用错误？无论怎样，把代码放到try/catch语句块中。我们要钓到大鱼啦！

是不是似曾相识呢？这是因为我们在以前已经都做到了。并且在某些情况下、它是无可非议的。毕竟，我们有最后期限，还得满足客户和经理。但不要过于频 繁操 作，否则你会发现你的代码不稳定，有很多热修复、逻辑重复、未测试的方案和错误处理。最后，你要么是把事情草草做完，要么是把事情好好做完。

6. 三思而后行

“敏捷开发”这个词最近被频繁滥用，经常被程序员用来掩饰他们在软件开发过程中的糟糕规划/设计阶段。我们是设计者，看到产品朝正当方向有实质进 展，我们理应高兴。但意外的是，UML图和用例分析似乎并不能满足我们的愿望。所以，在不知自己做什么的情况下或者不知自己身处何处时，我们开发人员经常 就稀里糊涂地写代码了。

这就好比你要去吃饭，但你根本没有想好去哪里吃。因为你太饿了，所以你迫不及待地找个餐馆，定个桌位。然后你上车开车后沿途在想（找地方吃饭）。只 是，这样会耗费更多的时间，因为你要过较多的U型弯道，还在餐馆前停车，也许最后因等待时间过长而不吃了。确切地说，你最后应该能找到地方吃饭，但你可能 吃的饭并不是你想吃的，并且这样花费的时间，可能比你直接在想去的餐馆订餐所花的时间更长。

7. 如果你惟一的工具是一把锤子，你往往会把一切问题看成钉子

看见了吧？我早就说过动态记录在这个项目中很有效

程序员有一种倾向，当一谈到他们工具时，其视野就变狭窄了。一旦某种方法在我们的一个项目上“行得通”，我们就会在接下来所有的项目上都用到它。学 习新东 西仿佛是一种煎熬，有时候甚至会心神不定。从始至终都在想“如果我用之前的方法做、这个就不会这么麻烦了”。一定要摒弃这种想法，按我们所知道的去做，即 使那不是最完美的解决方法。

坚持自己所知很简单，不过从长远的角度讲，选择一个适合这项工作的工具要容易得多。否则，就会与你的职业生涯格格不入。

8. 沉默即赞同

我什么都没看见！没看见！

"破窗理论"与"变成惯性理论"有着宏观的联系。

编程社区就好像一个现实社区。每个作品都是一个开发者的缩影。糟糕的代码发布的越多，就越容易反映现状。如果你不去努力编写优秀、整洁和稳定的代码，那你每天都将和糟糕的代码相伴了。

同样地，如果你看到别人写出了糟糕的代码，你就要跟这个人提出来。注意，这时候机智就应该用上场了。一般情况下，程序员都愿意承认他们在软件开发中还是有不懂的地方，并且会感谢你的好意。互相帮助对大家都有利，而对问题视而不见，只会使问题一直存在。

9. 双鸟在林，不如一鸟在手

如果可以讨论系统架构和重构，那么就差找个时间把事情做完。为了使正常运作的东西更加简洁而做改动，权衡改动的利弊很重要。当然了，简洁是一个理想 目标， 但总会有可以通过重构改进的代码。在编程世界中，为了代码不过时，会频繁简单改动代码。但有时候你又必须保证代码对客户有价值。那么，你面临一个简单窘 境：你不能一石二鸟。你在重构旧代码上所发时间越多，你编写新代码的时间就越少。在及时改进代码和维护程序之间，也需要找到平衡点。

10. 能力越大，责任越大

毫无疑问，软件已成为我们生活中一个既基本又重要的一部分。正因如此，开发优秀软件格外重要。乒乓球游戏中的Bug是一回事，航天飞机导向系统或者 航空交通管制系统中的Bug是另外一回事。Slashdot曾发表一文，讲述了单单Google News的一个小失误使一家公司股票蒸发11.4亿美元。其他例子参见《软件Bug引发的十次严重后果》。这些例子

便说明了我们正行使着多大的权利。你今 天写的代码，无论你是否有意，说不定有朝一日在重要的应用程序中派上用场，这想想都令人害怕。编写正确合格的代码吧！