程序员修炼之道——从小工到专家

术语

Guru，古鲁

Guru is a Sanskrit term that connotes someone who is a “teacher, guide , expert or master” of certain knowledge or field.

law of demeter，得墨特尔法则

得墨忒耳定律（Law of Demeter，缩写LoD）亦称为“最少知识原则（Principle of Least Knowledge）”，是一种软件开发的设计指导原则，特别是面向对象的程序设计。得墨忒耳定律是松耦合的一种具体案例。该原则是美国东北大学在1987年末发明的，可以简单地以下面任一种方式总结:

- 每个单元对于其他的单元只能拥有有限的知识：只是与当前单元紧密联系的单元；

- 每个单元只能和它的朋友交谈：不能和陌生单元交谈；

- 只和自己直接的朋友交谈。

这个原理的名称来源于希腊神话中的农业女神，孤独的得墨忒耳。

很多面向对象程序设计语言用”.”表示对象的域的解析算符，因此得墨忒耳定律可以简单地陈述为“只使用一个.算符”。因此，a.b.Method()违反了此定律，而a.Method()不违反此定律。一个简单例子是，人可以命令一条狗行走（walk），但是不应该直接指挥狗的腿行走，应该由狗去指挥控制它的腿如何行走。

优点

得墨忒耳定律使得软件更好的可维护性与适应性。因为对象较少依赖其它对象的内部结构，可以改变对象容器（container）而不用改变它的调用者（caller）。

Misunderstanding the Law of Demeter

王国维，治学三境界

王国维在《人间词话》中说：古今之成大事业、大学问者，必经过三种之境界： “昨夜西风凋碧树，独上高楼，望尽天涯路。” 此第一境也。 “ 衣带渐宽终不悔，为伊消得人憔悴。” 此第二境也。 “ 众里寻他千百度，蓦然回首，那人却在，灯火阑珊处。”此第三境也。

http://baike.baidu.com/view/955585.htm

KISS原则

KISS原则是英语 Keep It Simple, Stupid 的首字母缩略字。KISS原则是指在设计当中应当注重简约的原则。同时这原则亦有应用在商业书信、设计计算机软件、动画、工程上。原文当中有很多其他版本，包括：”Keep It Simple & Stupid”（在西欧文学中最常使用）、”Keep It Sweet & Simple”、”Keep It Short & Simple”、”Keep it Simple, Sweetheart” 及 “Keep it Simple, Sherlock”。

CORBA

CORBA（Common Object Request Broker Architecture,公共对象请求代理体系结构，通用对象请求代理体系结构）是由OMG组织制订的一种标准的面向对象应用程 序体系规范。或者说 CORBA体系结构是对象管理组织（OMG）为解决分布式处理环境(DCE)中，硬件和软件系统的互连而提出的一种解决方案；OMG组织是一个国际性的非盈利组织，其职责是为应用开发提供一个公共框架，制订工业指南和对象管理规范，加快对象技术的发展。

fc

FC是DOS及Windows下的一个比较文件的命令行工具，使用该命令能够将两个类似文件的不同之处进行详细对比。

巴别塔

巴别塔（希伯来语：מגדל בבל‎ Migdal Bavel；也译作巴贝尔塔、巴比伦塔，或意译为通天塔），巴别在希伯来语中有「变乱」之意。据《圣经·创世记》第11章记载，当时人类联合起来兴建希望塔顶通天能传扬己名的高塔。为了阻止人类的计划，上帝让人类说不同的语言，使人类相互之间不能沟通，计划因此失败，人类自此各散东西。此故事试图为世上出现不同语言和种族提供解释。

布道

讲道（英语：Sermon）是基督教中由预言者或牧师进行的一种演说。布道主要包括圣经、神学、宗教或道德方面的话题，通常在过去和当前的背景下阐释了信仰、律法等。布道的主要元素包括诠释、劝诫和实际行动等。布道原为汉语词汇，指宣传基督教的教义。

COBOL

COBOL（CommonBusinessOrientedLanguage）是数据处理领域最为广泛的程序设计语言，是第一个广泛使用的高级编程语言。在企业管理中，数值计算并不复杂，但数据处理信息量却很大。为专门解决经企管理问题，美国的一些计算机用户于1959年组织设计了专用于商务处理的计算机语言COBOL,并于1961年美国数据系统语言协会公布。经不断修改、丰富完善和标准化，目前COBOL已发展为多种版本。

史努比发誓的程序

未解

曼特罗（mantra）

曼特罗（梵文: मन्त्र）（咒語）指据称能够“创造变化”的音、音节、词、词组、句子、段落。它们的用途与类型依照与曼特罗相关的学校和哲理而变化。曼特罗起源于印度吠陀传统，后来逐渐成为印度教的传统的重要组成部分，在佛教，锡克教和耆那教中也常被用来祈福、消灾、驱魔等。

海森堡虫子（Heisenbug）

In computer programming jargon, a heisenbug is a software bug that seems to disappear or alter its behavior when one attempts to study it.

https://en.wikipedia.org/wiki/Heisenbug

http://www.infoq.com/cn/articles/exterminating-heisenbugs

意大利面条式代码

面条式代码（Spaghetti code）是软件工程中反面模式的一种，是指一个程序代码的控制结构复杂、混乱而难以理解，尤其是用了很多GOTO、例外、线程、或其他无组织的分歧架构。其命名的原因是因为程序的流向就像一盘面一样的扭曲纠结。面条式代码的产生有许多原因，例如没有经验的程序设计师，及已经过长期频繁修改的复杂程序。结构化程序设计可避免面条式代码的出现。

待解

C++支持多重继承，而Java允许类实现多重接口。使用这些设施对正交性有何影响？使用多重继承与使用多重接口的影响是否有不同？使用委托（delegation）与使用继承之间是否有不同？

注重实效的程序员之快速参考指南

1.关心你的技艺

Care About Your Craft

如果你不在湖能否漂亮的开发出软件，你又为何要耗费生命去开发软件呢？

2.思考！你的工作

Think! About Your Work

关掉自动驾驶仪，接管操作。不断地批评和评估你的工作。

3．提供各种选择，不要找蹩脚的借口

Provide Options, Don’t Make Lame Excuses

要提供各种选择，而不是找借口。不要说事情做不到；说明能够做什么。

4.不要容忍破窗户

Don’t Live with Broken Windows

当你看到糟糕的设计、错误的决策和糟糕的代码时，修正它们。

5.做变化的催化剂

Be a Catalyst for Change

你不能强迫人们改变。相反，要向他们展示未来可能会怎样，并帮助他们参与对未来的创造。

6.记住大图景

Remember the Big Picture

不要太过专注于细节，以至忘了查看你周围正在发生什么。

7.使质量成为需求问题

Make Quality a Requirements lssue

让你的用户参与确定项目真正的质量需求。

8.定期为你的知识资产投资

Invest Regularly in Your Knowledge Portfolio

让学习成为习惯。

9.批判地分析你读到的和听到的

Critically Analyze What You Read and Hear

不要被供应商、媒体炒作、或教条左右。要依照你自己的看法和你的项目的情况去对信息进行

分析。

10.你说什么和你怎么说同样重要

It’s both What You Say and the Way You Say it

如果你不能有效地向他人传达你的了不起的想法，这些想法就毫无用处。

11.不要重复你自己

DRY - Don’t Repeat Yourself

系统中的每一项知识都必须具有单一、无歧义、权威的表示。

12.让复用变得容易

Make It Easy to Reuse

如果复用很容易，人们就会去复用。创造一个支持复用的环境。

13.消除无关事物之间的影响

Eliminate Effects Between Unrelated Things

设计自足、独立、并具有单一、良好定义的目的的组件。

14.不存在最终决策

There Are No Final Decisions

没有决策是浇铸在石头上的。相反，要把每项决策都视为是写在沙滩上的，并为变化做好

计划。

15.用曳光弹找到目标

Use Tracer Bullets to Find the Target

曳光弹能通过试验各种事物并检查它们离目标有多远来让你追踪目标。

16.为了学习而制作原型

Prototype to Learn

原型制作是一种学习经验。其价值并不在于所产生的代码，而在于所学到的经验教训。

17.靠近问题领域编程

Program Close to the Problem domain

用你的用户的语言进行设计和编码。

18.估算，以避免发生意外

Estimate to Avoid Surprises

在着手之前先进行估算。你将提前发现潜在的问题。

19.通过代码对进度表进行迭代

Iterate the Schedule with the Code

用你在进行实现时获得的经验提炼项目的时间标度。

20.用纯文本保存知识

Keep Knowledge in Plain Text

纯文本不会过时。它能够帮助你有效利用你的工作。并简化掉时和测试。

21.利用命令shell的力量

Use the Power of Command Shells

当图形用户界面无能为力时使用shell。

22.用好一种编辑器

Use a Single Editor Well

编辑器应该是你的手的延伸；确保你的编辑器是可配置、科扩展和可编程的。

23.总是使用源码控制

Always Use Source Code Control

源码控制是你的工作的时间机器–你能够回到过去。

24.要修正问题，而不是发出指责

Fix the Problem, Not the Blame

bug是你的过错还是别人的过错，并不是真的很有关系–它仍然是你的问题，它仍然需要

修正。

25.调试时不要恐慌

Don’t Panic When Debuging

做一次深呼吸，思考什么可能是bug的原因。

26.“Select”没有问题

“Select” Isn’t Broken

在OS或编译器、甚或是第三方产品或库中很少发现bug。bug很可能在应用中。

27.不要假定，要证明

Don’t Assume It - Prove It

在实际环境中–使用真正的数据和辩解条件–证明你的假定。

28.学习一种文本操纵语言

Learn a Text Manipulation Language

你用每天的很大一部分时间处理文本，为什么不让计算机替你完成部分工作呢？

29.编写能编写代码的代码

Write Code That Writes Code

代码生成器能提高你的生产率，并有助于避免重复。

30.你不可能写出完美的软件

You Can’t Write Perfect Software

软件不可能完美。保护你的代码和用户，使它（他）们免于能够预见的错误。

31.通过合约进行设计

Design with Contracts

使用合约建立文档，并检验代码所做的事情正好是它声明要做的。

32.早崩溃

Crash Early

死程序造成的危害通常比有问题的程序要小得多。

33.用断言避免不可能发生的事情

Use Assertions to Prevent the Impossible

断言验证你的各种假定。在一个不确定的世界里，用断言保护你的代码。

34.将异常用于异常的问题

Use Exceptinos for Exceptional Problems

异常可能会遭受经典的意大利面条式代码的所有可读性和可维护性问题的折磨。将异常保留给

异常的事物。

35.要有始有终

Finish What You Start

只要可能，分配某资源的例程或对象也应该负责解除其分配。

36.使模块之间的耦合减至最少

Minimize Coupling Between Modules

通过编写“羞怯的”代码并应用得墨忒耳法则来避免耦合。

37.要配置，不要集成

Configure, Don’t Integrate

要将应用的各种技术选择实现为配置选项，而不是通过集成或工程方法实现。

38.将抽象放进代码，细节放进元数据

Put Abstractions in Code, Details in Metadata

为一般情况编程，将细节放在被编译的代码库之外。

39.分析工作流，以改善并发性

Analyze Workflow to Imporve Concurrency

利用你的用户的工作流中的并发性。

40.用服务进行设计

Design Using Services

根据服务–独立的、在良好定义、一致的接口之后的兵法对象–进行设计。

41.总是为并发进行设计

Always Design for Concurrency

容许并发，你将会设计出更整洁、具有更少假定的接口。

42.使视图与模型分离

Separate Views from Models

要根据模型和视图设计你的应用，从而以低廉的代码获取灵活性。

43.用黑板协调工作流

Use Blackboards to Coordinate Workflow

用黑板协调完全不同的事实和因素，同时又使各参与方保持独立和隔离。

44.不要靠巧合编程

Don’t Program by Coincidence

只依靠可靠的事物。注意偶发的复杂性，不要把幸运的巧合与有目的的计划混为一谈。

45.估算你的算法的阶

Estimate the Order of Your Algorithms

在你编写代码之前，先大致估算事情需要多长时间。

46.测试你的估算

Test Your Estimates

对算法的数学分析并不会告诉你每一件事情。在你的代码的目标环境中测定它的速度。

47.早重构，常重构

Refactor Early, Refactor Often

就和你会在华园里除草、并重新布置一样，在需要时对代码进行重写、重做和重新架构。要

铲除问题的根源。

48.为测试而设计

Design to Test

在你还没有编写代码时就开始思考测试问题。

49.测试你的软件，否则你的用户就得测试

Test Your Software, or Your Users Will

无情地测试。不要让你的用户为你查找bug。

50.不要使用你不理解的向导代码

Don’t Use Wizard Code You Don’t Understand

想到可以生成大量代码。在你把它们合并进你的项目之前，确保你理解全部这些代码。

51不要搜集需求–挖掘它们

Don’t Gather Requirements - Dig for Them

需求很少存在于表面上。它们深深地埋藏在层层假定、误解和政治手段的下面。

52.与用户一同工作，以像用户一样思考

Work with a User to Think Like a User

要了解系统实际上将如何被使用，这是最好的方法。

53.抽象比细节活得更长久

Abstractions Live Longer than Details

“投资”于抽象，而不是实现。

54.使用项目词汇表

Use a Project Glossary

创建并维护项目中使用的专用术语和词汇的单一信息源。

55.不要在盒子外面思考–要找到盒子

Don’t Think Outside the Box - Find the Box

在遇到不可能解决的问题时，要确定真正的约束。问问你自己：“它必须以这种方式完成吗？

它真的必须完成吗？”

56.等你准备好再开始

Start When You’re Ready

你的一生都在积累经验。不要忽视反复出现的疑惑。

57.对有些事情“做”胜于“描述”

Some Things Are Better Done than Described

不要掉进规范的螺旋

58.不要做形式方法的奴隶

Don’t Be a Slave to Formal Methods

如果你没有把某项技术放进你的开发时间和能力的语境中，不要盲目地采用它。

59.昂贵的工具不一定能制作出更好的设计

Costly Tools Don’t Produce Better Disigns

小心供应商的炒作，行业教条，以及价格标签的诱惑。要根据工具的价值判断它们。

60.围绕功能组织团队

Organize Teams Around Fucntionality

不要把设计师与编码员分开，也不要把测试员与数据建模员分开。按照你构建代码的方式构建

团队。

61.不要使用手工流程

Don’t Use Manual Procedures

shell脚本或批文件会一次次地以同一顺序执行同样的指令。

62.早测试，常测试，自动测试。

Test Early. Test Often. Test Automatically

与呆在书架上的测试计划相比，每次构建试运行的测试要有效得多。

63.要到通过全部测试，编码才算完成。

Coding Ain’t Done ‘Til All the Tests Run

就是这样。

64.通过“蓄意破坏”测试你的测试。

Use Saboteurs to Test Your Testing

在单独的软件副本上故意引入bug，以检验测试能够抓住它们。

65.测试状态覆盖，而不是代码覆盖

Test State Coverage, Not Code Coverage

确定并测试重要的程序状态。只是测试代码行是不够的。

66.一个bug只抓一次

Find Bugs Once

一旦测试员找到一个bug，这应该是测试员最后一次找到它。此后自动测试应该对其进行

检查。

67.英语就是一种编程语言

English is Just a Programming Language

像你编写代码一样编写文档：遵守DRY原则、使用元数据、MVC、自动生成、等等。

68.把文档建在里面，不要栓在外面

Build Documentation In, Don’t Bolt It On

与代码分离的文档不太可能被修正和更新。

69.温和地超出用户的期望

Gently Exceed Your Users’ Expectations

要理解你的用户的期望，然后给他们的东西要多那么一点。

70.在你的作品上签名

Sign Your Work

过去时代的手艺人为能在他们作品上签名而自豪。你也应该如此。

检查清单

71.要学习的语言

厌倦了C、C++和JAVA？试试CLOS、Dylan、Eiffel、Objectve C、Prolog、Smailltalk或TOM。它们每一种都有不同的能力和不同的“风味”。用其中的一种或多种语言在家里开发一个小项目。

72.WISDOM离合诗

What do you want them to learn? 你想让他们学到什么？

What is their interest in what you’ve got to say? 他们对你讲的什么感兴趣？

How sophisticated are they? 他们有多富有经验？

How much detail do they want? 他们想要多少细节？

Whom do you want to own the information? 你想要让谁拥有这些信息？

How can you motivate them to listen to you? 你如何促使他们听你说话？

73.怎样维持正交性

·设计独立、良好定义的组件。

·使你的代码保持解耦。

·避免使用全局数据。

·重构相似的函数。

74.应制作原型的事物

·架构

·已有系统中的新功能

·外部数据的结构或内容

·第三方工具或组件

·性能问题

·用户界面设计

75.架构问题

·责任是否得到了良好定义？

·写作是否得到了良好定义？

·耦合是否得以最小化？

·你能否确定潜在的重复？

·接口定义和各项约束是否可接受？

·模块能否在需要时访问所需数据？

76.调试检查清单

·正在报告的问题是底层bug的直接结果，还是只是症状？

·bug真的在编译器里？在OS里？或者是在你的代码里？

·如果你向同事详细解释这个问题，你会说什么？

·如果可疑代码通过了单元测试，测试是否足够完整？如果你用该数据运行单元测试，会发生什么？

·造成这个bug的条件是否存在于系统中的其它任何地方？

77.函数的得墨忒耳法则

某个对象的方法应该只调用属于以下情况的方法：

·它自身

·传入的任何参数

·它创建的对象

·组件对象

78.怎样深思熟虑地编程

·总是意识到你在做什么。

·不要盲目地编程。

·按照计划行事。

·依靠可靠的事物。

·为你的假定建立文档。

·不要只是测试你的代码，还要测试你的假定。

·维尼的工作划分优先级。

·不要做历史的奴隶。

79.何时进行重构

·你发现了对DRY原则的违反。

·你发现事物可以更为正交。

·你的知识扩展了。

·需求演变了。

·你需要改善性能。

80.劈开戈尔迪斯结

在解决不可能解决的问题时，问问你自己：

·有更容易的方法吗？

·我是在解决正确的问题吗？

·这件事情为什么是一个问题？

·是什么使它如此难以解决？

·它必须以这种方式完成吗？

·它真的必须完成吗？

81.测试的各个方面

·单元测试

·集成测试

·炎症和校验

·资源耗尽、错误及恢复

·性能测试

·可用性测试

·对测试自身进行测试