每位开发人员都应铭记的10句编程谚语

所谓谚语，就是用言简意赅、通俗易懂的方式传达人生箴言和普遍真理的话，它们能很好地帮助你处理生活和工作上的事情。也正因如此，我才整理了10句编程谚语，每位开发人员都应该铭记他们，武装自己。

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引发的十次严重后果》。这些例子便说明了我们正行使着多大的权利。你今天写的代码，无论你是否有意，说不定有朝一日在重要的应用程序中派上用场，这想想都令人害怕。编写正确合格的代码吧！

译注：Slashdot是一个资讯科技网站。

第二篇：130句编程警句

130句编程警句（Epigrams in Programming ）

The phenomena surrounding computers are diverse and yield a surprisingly rich base for launching metaphors at individual and group activities. Conversely, classical human endeavors provide an inexhaustible source of metaphor for those of us who are in labor within computation. Such relationships between society and device are not new, but the incredible growth of the computer's influence (both real and implied) lends this symbiotic dependency a vitality like a gangly youth growing out of his clothes within an endless puberty. The epigrams that follow attempt to capture some of the dimensions of this traffic in imagery that sharpens, focuses, clarifies, enlarges, and beclouds our view of this most remarkable of all mans' artifacts, the computer.

1. One man's constant is another man's variable.

2. Functions tend to delay binding; data structures tend to induce binding. Moral: Structure data late in the programming process.

3. Syntactic sugar causes cancer of the semi-colons.

4. Every program is a part of some other program and rarely fits perfectly.

5. If a program manipulates a large amount of data, it does so in a small number of ways.

6. Symmetry is a complexity reducing concept (co-routines include sub-routines); seek it everywhere.

7. It is easier to write an incorrect program than understand a correct one.

8. A programming language in which the irrelevant is as portentious as the critical in programs is a low order language.

9. It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures.

10. Get into a rut early: Do the same processes the same way. Accumulate idioms. Standardize. The only difference(!) between Shakespeare and you was the size of his idiom list -- not the size of his vocabulary.

11. If you have a procedure with 10 parameters, you probably missed some.

12. Recursion is at the root of computation since it trades description for time.

13. If two people write exactly the same program, each should be put in micro-code and then they certainly won't be the same.

14. In the long run every program becomes rococo -- then rubble.

15. Everything should be built top-down, except the first time.

16. Every program has (at least) two purposes: the one for which it was written and another for which it wasn't.

17. If a listener nods his head when you're explaining your program, wake him up.

18. A program without a loop and a structured variable isn't worth writing.

19. If a language doesn't affect the way you think about programming, it's not worth knowing.

20. Wherever there is modularity there is the potential for misunderstanding: Hiding information implies a need to check communication.

21. Optimization often delays evolution.

22. A system is a collection of weakly interacting procedures that, in various combinations, perform a varietoy functions, in short, a system is a (general purpose?) computer. Hence the command language (order code) is critical. A good system can't have a weak command language.

23. To understand a program you must become the machine that executes it, often the programs

that process it.

24. Perhaps if we wrote programs from childhood on, as adults we'd be able to read them. However, reading a program is not like reading a book, it is more like being a psychiatrist to a recumbent patient.

25. One can only display complex information in the mind. Like seeing, movement or flow or alteration of view is more important than the static picture, no matter how lovely.

26. There will always be things we wish to say in our programs that in all languages can only be said poorly.

27. Once you understand how to write a program get someone else to write it.

28. Around computers it is difficult to find the correct grain of time to measure progress. Some cathedrals took a century to complete. Can you imagine the grandeur and scope of a program that would take as long?

29. For systems, the analogue of a face-lift is to add to the control graph an edge that creates a cycle, not just toan additional node.

30. In programming, everything we do is a special case of something more general -- and we often know it too quickly.

31. Simplicity does not precede complexity, but follows it.

32. Good Programmers are not so much to be measured by their ingenuity and their logic as the completeness of their case analysis.

33. The 11th commandment was "Thou Shalt Compute" or "Thou Shalt Not Compute" -- I forget which.

34. The string is a stark data structure and everywhere it is passed there is much duplication of process. It is a perfect vehicle for hiding information.

35. Everyone can be taught to sculpt: Michelangelo would have had to be taught how not to. So it is with the great programmers.

36. The use of a program to prove the 4-color theorem will not change mathematics -- it merely demonstrates that the theorem, a challenge for a century, is probably not important to mathematics.

37. The most important computer is the one that rages in our skulls and ever seeks that satisfactory external emulator. The standardization of real computers would be a disaster -- and so it probably won't happen.

38. Structured Programming supports the law of the excluded muddle.

39. Re graphics: A picture is worth 10K words -- but only those to describe the picture. Hardly any sets of 10K words can be adequately described with pictures.

40. There are two ways to write error-free programs; only the third one works.

41. Some programming languages manage to absorb change, but withstand progress.

42. You can measure a programmer's perspective by noting his attitude on the continuing vitality of FORTRAN.

43. In software systems it is often the early bird that makes the worm.

44. Sometimes I think the only universal in the computing field is the fetch-execute cycle.

45. The goal of computation is the emulation of our synthetic abilities, not the understanding of our analytic ones.

46. Like punning, programming is a play on words.

47. As Will Rogers would have said, "There is no such thing as a free variable."

48. The best book on programming for the layman is "Alice in Wonderland"; but that's because it's the best book

on anything for the layman.

49. Giving up on assembly language was the apple in our Garden of Eden: Languages whose use squanders machine cycles are sinful. The LISP machine now permits LISP programmers to abandon bra and fig-leaf.

50. When we understand knowledge-based systems, it will be as before -- except our finger-tips will have be singed.

51. Bringing computers into the home won't change either one, but may revitalize the corner saloon.

52. Systems have sub-systems and sub-systems have sub-systems and so on ad finitum -- which is why we're always starting over.

53. So many good ideas are never heard from again once they embark in a voyage on the semantic gulf.

54. Beware of the Turing tar-pit in which everything is possible but nothing of interest is easy.

55. A LISP programmer knows the value of everything, but the cost of nothing.

56. Software is under a constant tension. Being symbolic it is arbitrarily perfectible; but also it is arbitrarily changeable.

57. It is easier to change the specification to fit the program than vice versa.

58. Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses remove it.

59. In English every word can be verbed. Would that it were so in our programming languages.

60. Dana Scott is the Church of the Lattice-Way Saints.

61. In programming, as in everything else, to be in error is to be reborn.

62. In computing, invariants are ephemeral.

63. When we write programs that "learn", it turns out we do and they don't.

64. Often it is means that justify ends: Goals advance technique and technique survives even when goal structures crumble.

65. Make no mistake about it: Computers process numbers -- not symbols. We measure our understanding (and control) by the extent to which we can arithmetize an activity.

66. Making something variable is easy. Controlling duration of constancy is the trick.

67. Think of all the psychic energy expended in seeking a fundamental distinction between "algorithm" and "program".

68. If we believe in data structures, we must believe in independent (hence simultaneous) processing. For why else would we collect items within a structure? Why do we tolerate languages that give us the one without t other?

69. In a five year period we get one superb programming language. Only we can't control when the 5 year period will begin.

70. Over the centuries the Indians developed sign language for communicating phenomena of interest. Programmers from different tribes (FORTRAN, LISP, ALGOL, SNOBOL, etc.) could use one that doesn't

require them to carry a blackboard on their ponies.

71. Documentation is like term insurance: It satisfies because almost no one who subscribes to it depends on its benefits.

72. An adequate bootstrap is a contradiction in terms.

73. It is not a language's weaknesses but its strengths that control the gradient of its change: Alas, a language never escapes its embryonic sac.

74. Is it possible that software is not like anything else, that it is meant to be discarded; that the whole point is to always see it as soap bubble?

75. Because of its vitality, the computing field is always in desperate need of new cliches: Banality soothes our nerves.

76. It is the user who should parametrize procedures, not their creators.

77. the cybernetic exchange between man, computer and algorithm is like a game of musical chairs: The frant search for balance always leaves one of the three standing ill at ease.

78. If your computer speaks English it was probably made in Japan.

79. A year spent in artificial intelligence is enough to make one believe in God.

80. Prolonged contact with the computer turns mathematicians into clerks and vice versa.

81. In computing, turning the obvious into the useful is a living definition of the word "frustration."

82. We are on the verge: Today our program proved Fermat's next-to-last theorem!

83. What is the difference between a Turing machine and the modern computer? It's the same as that between

Hillary's ascent of Everest and the establishment of a Hilton hotel on its peak.

84. Motto for a research laboratory: What we work on today, others will first think of tomorrow.

85. Though the Chinese should adore APL, it's FORTRAN they put their money on.

86. We kid ourselves if we think that the ratio of procedure to data in an active data-base system can be ma arbitrarily small or even kept small.

87. We have the mini and the micro computer. In what semantic niche would the pico computer fall?

88. It is not the computer's fault that Maxwell's equations are not adequate to design the electric motor.

89. One does not learn computing by using a hand calculator, but one can forget arithmetic.

90. Computation has made the tree flower.

91. The computer reminds one of Lon Chaney -- it is the machine of a thousand faces.

92. The computer is the ultimate polluter: Its feces are indistinguishable from the food it produces.

93. When someone says "I want a programming language in which I need only say what I wish done," give him a lollipop.

94. Interfaces keep things tidy, but don't accelerate growth: Functions do.

95. Don't have good ideas if you aren't willing to be responsible for them.

96. Computers don't introduce order anywhere as much as they expose opportunities.

97. When a professor insists computer science is X but not Y, have compassion for his graduate students.

98. In computing, the mean time to failure keeps getting shorter.

99. In man-machine symbiosis, it is man who must adjust: The machines can't.

100. We will never run out of things to program as long as there is a single program around.

101. Dealing with failure is easy: Work hard to improve. Success is also easy to handle: You've solved the wrong problem. Work hard to improve.

102. One can't proceed from the informal to the formal by formal means.

103. Epigrams are interfaces across which appreciation and insight flow.

104. Epigrams parametrize auras.

105. Epigrams are macros, since they are executed at read time.

106. Epigrams crystallize incongruities.

107. Epigrams retrieve deep semantics from a data base that is all procedure.

108. Epigrams scorn detail and make a point: They are a superb high-level documentation. 109. Epigrams are more like vitamins that protein.

110. Epigrams have extremely low entropy.

111. Purely applicative languages are poorly applicable.

112. The proof of a system's value is its existence.

113. You can't communicate complexity, only an awareness of it.

114. It's difficult to extract sense from strings, but they're the only communication coin we can count on.

115. The debate rages on: Is PL/I Bachtrian or Dromedary?

116. Whenever two programmers meet to criticize their programs, both are silent.

117. Think of it! With VLSI we can pack 100 ENIACS in 1 sq. cm.

118. Editing is a rewording activity.

119. Why did the Roman Empire collapse? What is the Latin for office automation?

120. Computer Science is embarrassed by the computer.

121. The only constructive theory connecting neuroscience and psychology will arise from the study of the computer.

122. Within a computer natural language is unnatural.

123. Most people find the concept of programming obvious, but the doing impossible.

124. You think you know when you learn, are more sure when you can write, even more when you teach, but certain when you can program.

125. It goes against the grain of modern education to teach children to program. What fun is there in making plans, acquiring discipline in organizing thoughs, devoting attention to detail and learning to be self-critical?

126. If you can imagine a society in which the computer-robot is the only menial, you can imagine anything.

127. Programming is an unnatural act.

128. Adapting old programs to fit new machines usually means adapting new machines to behave like old ones.

129. In seeking the unattainable, simplicity only gets in the way.

130. The last epigram? Neither eat nor drink them, snuff epigrams.

?

作者简介：

Alan J. Perlis(04/01/1922--02/07/1990) 第一位图灵奖(1966 年) 获得者。( 授予Alan J. Perlis 图灵奖以表彰其在) 高级编程技术及其编译器的构造领域的影响。 Alan ，出生于美国宾州 Pittsburgh, Pennsylvania.19xx年获得CMU(www.cmu.edu)的化学学士学位。19xx年和19xx年，分别获得MIT的数学硕士与博士学位。其博士论文题目为"On Integral Equations, their Solution by Iteration and Analytic Continuation”. Alan是著名的CMU 计算机科学系的首位系主任在19xx年到19xx年。在19xx年，Alan加入耶鲁大学计算机科学系，并在19xx年到19xx年出任计算机系系主任。19xx年，Alan，在耶鲁大学计算机系任职期间，撰写了一篇

著名的文章”Epigrams on Programming"(编程警言)并发表在ACM SIGPLAN杂志上(Vol. 17, No. 9, September 1982)。这篇包含130个警言的文章得到了工业界和学术界广泛的注意和引用。