于今夕之何夕，唯读书以自省

如果两个或更多从句在语法上各自都很完整，而且没有用连词连接在一起构成一个复合的句子，那么这些从句之间应该用分号。

Mary Shelley's works are entertaining; they are full of engaging ideas.

It is nearly half past five; we cannot reach town before dark.

当然，将两个从句分开写成两个独立的句子也是对的，不过是用句号替换分号。

Mary Shelley's works are entertaining. They are full of engaging ideas.

It is nearly half past five. We cannot reach town before dark.

如果插入连词，那么用逗号是正确的做法。（参见基本规则4）

Mary Shelley's works are entertaining, for they are full of engaging ideas.

It is nearly half past five, and we cannot reach town before dark.

对比上面的三种方式，可以清晰地发现第一种的优势。至少从例子中看来，这种形式要比第二种好，因为它体现了两个句子间的紧密关系，而第二种形式没有体现出来；它比第三种好，是因为要更简短，因此更有力。的确如此，这种表示句子关系的简单方法是写作最有用的工具之一。如上所示，句子之间的关系常常是因果关系。

要注意，如果第二个从句由副词引导，比如accordingly、besides、then、therefore或是thus，而不是连词引导，那么分号还是需要的。

I had never been in the place before; besides, it was dark as a tomb.

这里要指出的是：分号规则有一个例外。当从句都很短，而且形式上很像时，或是句子的语调、语气简单、类似于对话时，选用逗号更合适。

Man proposes, God disposes.

The gates swung apart, the bridge fell, the portculls was drawn up.

I hardly knew him, he was so changed.

Here today, gone tomorrow.

在连词引导的独立从句前要用逗号

The early records of the city have disappeared, and the story of its first years can no longer be reconstructed.

The situation is perilous, but there is still one chance of escape.

由两部分构成的句子，当第二部分由as（表达“因为”的意思）、for、or、nor、或是while（表达“与此同时”的意思）引导时，在这些连词前需要加一个逗号。

如果是一个依赖从句，或是需要由逗号引起的介绍性短语，第二个依赖从句前不需要在连词后添加逗号。[译注：本句存疑，为什么说在连词后加入逗号？]

The situation is perilous, but if we are prepared to act promptly, there is still one chance of escape.

当两个从句的主语相同而且仅表达一次时，如果连接词是but，就可以用逗号。如果连词是and，而且两个句子之间的关系非常接近或是时间上非常靠近时，逗号可以省略。

I have heard the arguments, but am still unconvinced.

He has had several years' experience and is thoroughly competent.

The best way to see a country, unless you are pressed for time, is to travel on foot.

这个规则可不好实行。因为很难判断一个单词，比如however，或者一个短语是否是插入语。如果对于整句的语气打断很轻微，省略逗号应该没有问题。但不管对语气的打断是轻微还是比较重，决不要留一个逗号，忽略一个都好。下面这样的标点符号试用方式完全错误：

Marjories husband, Colonel Nelson paid us a visit yesterday.

还有这种：

My brother you will be pleased to hear, is now in perfect health.

日期通常包含隶属插入语的单词或数字。标点符号使用方法如下：

February to July, 1992

April 6, 1986

Wednesday, November 14, 1990

注意下面这种忽略逗号的方式只是习惯用法：

6 April 1988

这种形式用来写日期是非常好的，数字之间用一个单词隔开，因此，很容易就能领会。

直接称呼的姓氏或头衔也属于插入语。

If, Sir, you refuse, I cannot predict what will happen.

Well, Susan, this is a fine mess you are in.

缩略语etc.、i.e.和e.g.，学位的缩略语，跟在名字之后的头衔也是插入语，应该注意正确使用标点符号。

Letters, packages, etc., should go here.

Horace Fulsome, Ph.D., presided.

Rachel Simonds, Attorney

The Reverend Harry Lang, S.J.

不过，不要对表明身份的限定语使用逗号。

Billy the Kid

The novelist Jane Austen

William the Conqueror

The poet Sappho

尽管Junior和其缩略语Jr.常被看作缩略语，然而，逻辑上将其看作限定语，因此不需要逗号。

James Wright Jr.

非限定的关系从句算是插入语，由连词引导的、表示时间或地点的从句与之类似。因此需要逗号。非限定性的从句无法对前面的名词起到标示或定义的作用。

The audience, which had at first been indifferent, became more and more interested.

In 1769, when Napoleon was born, Corsica had but recently been acquired by France.

Nether Stowey, where Coleridge wrote The Rime of the Ancient Mariner, is a few miles from Bridgewater.

在上面这些句子中，由which、when和where引导的从句是非限定性从句，它们不会做出限定或定义，仅仅是补充一些内容。在第一个例子中，由which引导的从句无法指明提到的是哪些可能的观众，而是假定读者对此已经知晓。从句以插入语的形式加入了一个句子，对主句形成补充。上面这三句话都是两个句子构成的，可以分开表述。如下：

The audience was at first different. Later it became more and more interested.

Napoleon was born in 1769. At that time Corsica had but recently been acquired by France.

Coleridge wrote The Rime of the Ancient Mariner at Nether Stowey. Nether Stowey is a few miles from Bridgewater.

相对而言，限定性从句不是插入语，不应用逗号隔开。因此，

People who live in glass houses shouldn't throw stones.

此句中由who引导的从句可以指出修饰的是哪些人。这一句与上述句子不同，无法分成两个独立的句子。这里的逗号使用规则也可用于分词短语和同位语。

People sitting in the rear couldn't hear. （限定性作用）

Uncle Bert, being slightly deaf, moved forward. （非限定性作用）

My cousin Bob is a talented harpist. （限定性作用）

Our oldest daughter, Mary, sings. （非限定性作用）

当一个句子的主从句由一个短语或是附属从句作为前缀时，要用逗号隔开这些语法元素。

Partly by hard fighting, partly by diplomatic skill, they enlarged their dominions to the east and rose to royal rank with the possession of Sicily.

在公共会议做演讲，需要克服两大障碍：如何从会议主办方获得许可、如何在会议上做好演讲。

对于第一个障碍，Jim Holmes的博客文章“编写优秀的演讲摘要”给出了几点建议：

• 让你的演讲内容与活动目标相符合
• 避免过于宽泛的演讲
• 标题非常重要，真的
• 说明听众能从你的演讲中得到哪些收获
• 给出讨论的实际例子
• 展示该演讲以前获得的反馈
• 编写简洁的摘要
• 编写内容紧凑的摘要
• 一审再审，让人复审

第二个障碍，可以参考Kathy Sierra（她是Head First系列书籍的作者之一）的博客文章：如何在技术会议上演讲

• 坚决不要等待邀请！
• 坚决不要指望别人提出建议议题邀请！
• 知道会议的主题
• 选择好的标题
• 从听众的角度思考
• 不要害羞，不要充斥市场宣传之词
• 真正的工作实践远胜过抽象的思考
• 回答该问题：我的演讲如何才能让听众解决实际问题？
• 花时间研究会议手册，阅读每个摘要
• 提供引人注目的个人介绍
• 以前的演讲经验会有所帮助
• 实际参加会议
• 提交多个议题
• 不要放弃，不管怎样，要是被拒绝了，不要将其视为个人恩怨
• 寻求帮助

P.S.:本文动机来自infoq新闻：《女士们：请递交你们的议题吧！》

现在来看The Art of Unit Testing With Examples in .NET的第三章“Using Stubs to Break Dependencies”

• 作者使用了三种定义来指向测试中的伪造关系：fakes, stubs 和 mocks。
• “除了间接层次过多这样的问题之外，没有哪种面向对象的问题是不能通过添加间接层次解决的。”然而，单元测试的诸多精妙之处就在于：如何找到正确的地方添加或使用间接层次，以测试目标代码。
• 加入间接层次的三个步骤：
  1. 找到待测试方法依赖的“接口”。这里的接口不单单是指面向对象中的接口，还包括与其他类协作需要调用的方法或类。
  2. 如果“接口”与待测方法有“直接关系”（比如直接调用等等），就可以通过向接口加入间接层次，使得待测方法可以被测试。
  3. 将交互接口的“潜在实现”用可以控制的东西替换。
• 对于Seam（接缝）的定义：

Seams are places in your code where you can plug in different functionality, such as stub classes. (可参考Michael Feathers的《修改代码的艺术》)

• 打破依赖的5种方法：
  1. 抽离出接口，以替换潜在实现。
  2. 向待测类中注入stub实现。
  3. 在构造器中接收接口作为函数。
  4. 将接口作为属性，进行设置或读取。
  5. 在调用方法前得到stub。

在The Art of Unit Testing With Examples in .NET的第二章“A first unit test”中，提出了一些unit test应该注意的初步细节，比如测试方法命名的基本规则：

待测试对象：Project , 例如：项目名为Logan

测试代码中的对应对象：创建项目名称为[ProjectUnderTest].Tests；上例对应项目名为：Logan.Tests

待测试对象：Class，例如：类名为LogAnalyzer

测试代码中的对应对象：对于每个class，至少创建一个对应class，命名为[ClassName]Tests；上例对应类名为：LogAnalyzerTests

待测试对象：Method，例如：期待名为IsValidLogFileName的方法，输入合法的文件名，希望返回true

测试代码中的对应对象：对于每个方法，创建至少一个测试方法，命名规则为[MethodName]_[StateUnderTest]_[ExpectedBehavior]. 上例对应方法名为：IsValidFileName_valideFile_ReturnsTrue()

此外，还提到了针对状态的间接测试——state-based testing，其定义如下：

State-based testing (also called state verification) determines whether the exercised method worked correctly by examining the state of the system under test and its collaborators (dependencies) after the method is exercised.

根据The Art of Unit Testing With Examples in .NET，好的unit test应该具备如下特点：

• It should be automated and repeatable.
• It should be easy to implement.
• Once it’s written, it should remain for future use.
• Anyone should be able to run it.
• It should run at the push of a button.
• It should run quickly.

如果这还不够，请回答下列问题，足以判断一个测试是否是好的unit test：

• Can I run and get results from a unit test I wrote two weeks or months or years ago?
• Can any member of my team run and get the results from unit tests I wrote two months ago?
• Can I run all the unit tests I’ve written in no more than a few minutes?
• Can I run all the unit tests I’ve written at the push of a button?
• Can I write a basic unit test in no more than a few minutes?

有任何一个问题的回答是“no”，对不起，您的测试不是unit test，而是integration test，书中对于此类测试定义如下：

Integration testing means testing two or more dependent software modules as a group.

因此，unit test的定义如下：

A unit test is an automated piece of code that invokes the method or class being tested and then checks some assumptions about the logical behavior of that method or class. A unit test is almost always written using a unit-testing framework. It can be written easily and runs quickly. It’s fully automated, trustworthy, readable, and maintainable.

 

开始看这本书：The Art of Unit Testing With Examples in .NET。选择它，两个原因：

1. 单元测试是保证代码质量的基石和安全网。
2. 该书篇幅短小精湛，而且非常实用。非常期待看到Chapter 8中的Tough Questions and Answers，其中有对如下问题的回答。

• How much time will this add to the current process?
• Will my QA job be at risk because of this?
• How do we know this is actually working?
• Is there proof that unit testing helps?
• Why is the QA department still finding bugs?
• We have lots of code without tests: where do we start?
• We work in several languages: is unit testing feasible?
• What if we develop a combination of software and hardware?
• How can we know we don’t have bugs in our tests?
• My debugger shows that my code works: why do I need tests?
• Must we do TDD-style coding?

如果能够顺利回答这些问题，相信unit test的实施就不是问题了。

我们希望系统解决的问题通过需求得以体现。GUI设计是要体现出GUI如何引导用户使用系统以解决他们的问题。很多项目都将GUI设计混同于需求的假面之下，这很让人讶异。如果你的项目总是陷于无尽的需求工作之中，看看问题是不是出在GUI设计上。

GUI是设计，不是需求

凯伦，程序经理

我在一家新公司工作时，试图拯救一个陷入“需求地狱”的项目。需求文档已经达到300多页，而且远未完成。

阅读这些文档后，我找到了原因。所有的GUI设计都被记录在需求文档中。GUI设计没有放在项目的设计阶段，业务分析人员和GUI设计人员试图将所有的GUI需求都放在需求文档中。他们使用了功能强大的图形设计工具，并在需求文档中定义GUI。

我向他们询问原因，他们看着我，说道：“这些是GUI需求。”我建议他们认真看看GUI设计，并且考虑这些设计是否应该跟希望系统解决的问题放在一起。GUI设计不应放在需求文档中。

最终，他们同意采纳我的建议，我们也可以逃离需求地狱了。而且，由于我按照逐个功能重新组织了项目，GUI设计也就跟各个功能结合在一起了。我们定期检查整个GUI的一致性，但是这与需求无关，这属于设计。

人们很容易在项目开始阶段设计GUI，并称其为需求。如果要这么做，项目就永远无法找到自己的节奏。它会一直陷于需求的泥沼之中，直到最后，无法完成任何客户需要的功能，虽然到时候能够得到精美无比的GUI。

要减少不必要的代码，有一个好方法：想想谁会使用系统，又该如何开发用户需要的系统。

有很多项目都试图通过定义功能性和非功能性需求来确定需求。可是这些需求没有说明一个人如何使用系统，以及一个功能在何种场景下必须运行。需求收集的方法应该为项目团队提供上下文，这样才能深入理解需求。

谁需要那个支票账户？

克拉丽莎，资深经理

我的项目团队陷入困境。他们实现了一堆只开发完一部分的功能，可是没有哪个能够真正运行。我召开了一个会议，以决定接下来该做什么。

在会议上，我想知道：为了完成项目，哪些用户是他们的首要服务对象。他们看着我，脸上毫无表情。“你们看，我们是一家银行。我们希望年满18岁、将要进入大学的人们首先使用我们的服务。还有住在郊外的妈妈们，她们还有其他资产，75岁的老奶奶，以及年方15已经靠做家务挣得零花钱的孩子们。我们可以为他们提供不同的理财服务。如果他们走进来，我们希望他们成为我们的客户。对于这些不同类型的客户，我们真地想过要给他们提供什么样的产品么？”

他们以前太过专注于系统的内部功能，忽视了系统真正要为之服务的用户。我们把期望捕获的用户重新进行了排序，项目团队因此得以完成需求定义，并完成系统的功能。

人，总是人的因素，不是么？ 

只要大家了解需求的上下文，开发人员、测试人员和文案人员就能知道如何开发、测试、编写文案。如果他们不能了解，要是需求以功能性和非功能性需求的方式罗列，他们也可以问一些更好的问题，从而深入了解需求。