经过这三个测试，我们如今对现有代码的任务方式有了大致的了解：假设一团体不到30岁，且每年赚$ 68,300，那么他被以为是成功人士。虽然我们可以创立更多的测试来确保临界状况(例如空白年龄或工资)功用正常，但是一些冗长的测试不只使我们了解了原始功用，还给出了一套自动化测试，可用于确保在对现有代码停止更改时，我们不会破坏现有功用。

运用现有测试

假设有足够的代码测试组件，那么我们可以从测试中学到很多东西。正如我们创立测试一样，经过阅读测试，我们可以了解代码如何在功用层面上任务。此外，我们还可以知道原作者是如何让代码运转的。即使测试是由原作者以外的人(在我们接触之前)撰写的，也依然可以为我们提供关于其别人对代码的看法。

虽然现有的测试可以提供协助，但我们依然需求对此持保留态度。测试能否与代码的开发更改一同与时俱进是很难说的。假设是的话，那么这是一个很好的了解基础;假设不是，那么我们要小心不要被误导。例如，假设初始的工资阈值是每年75,000美元，然后来更改为我们的68,330美元，那么下面这个过时的测试能够会使我们悬崖勒马：

@Test 

public void under30AndNettingThresholdEnsureSuccessful() { 

    Person person = new Person(29, 75000.0); 

    Assert.assertTrue(new SuccessfulFilter().test(person)); 

} 

这个测试还是会经过的，但没有了预期的作用。经过的缘由不是由于它正好是阈值，而是由于它超出了阈值。假设此测试组件包含这样一个测试用例：当薪水低于阈值1美元时，过滤器就前往false，这样第二个测试将会失败，表明阈值是错误的。假设套件没有这样的测试，那么陈旧的数据会很容易误导我们弄错代码的真正意图。当有疑问时，请置信代码：正如我们之前所表述的那样，求解阈值表明测试没有对准实践阈值。

另外，要查看代码和测试用例的存储库日志(即Git日志)：假设代码的最后更新日期比测试的最后更新日期更近(对代码停止了严重更改，例如更改阈值)，则测试能够曾经过时，应慎重查看。留意，我们不应该完全无视测试，由于它们也许依然能为我们提供关于原作者(或最近撰写测试的开发人员)意图的一些文档，但它们能够包含过时或不正确的数据。

2.与编写代码的人交流

在触及多团体的任何任务中，沟通至关重要。无论是企业，越野游览还是软件项目，缺乏沟通是损害义务最有效的手腕之一。即使我们在创立新代码时停止沟通，但是当我们接触现有的代码时，风险会添加。由于此时我们对现有的代码并不太了解，因此我们所了解的内容能够是被误导的，或只代表了其中的一小部分。为了真正了解现有的代码，我们需求和编写它的人交流。

当末尾提出成绩时，我们需求确定成绩是详细的，并且旨在完成我们了解代码的目的。例如：

这个代码片段最适宜放到系统的哪里?

你有什么设计或图表吗?

我应该留意什么圈套?

这个组件或类是做什么的?

有没有什么你想放到代码里，但事先没有做的?为什么?

一直要保持谦逊的态度，积极寻求原作者真正的答案。简直每个开发人员都碰到过这样的场景，他或她看着别人的代码，自问自答：“为什么他/她要这样做?为什么他们不这样做?”然后花几个小时来得出本来只需原作者回答就能失掉的结论。大少数开发人员都是有才华的顺序员，所以即使假设我们遇到一个看似蹩脚的决议，也有能够有一个很好的理由(能够没有，但研讨别人的代码时最好假定他们这样做是有缘由的;假设真的没有，我们可以经过重构来改动)。

沟通在软件开发中起主要反作用。1967年最后由Melvin Conway创立的康威定律规则：

设计系统的任何组织…都将不可避免地产生一种设计，该设计结构反映了组织的通讯结构。

(责任编辑：admin)