如何处理前任程序员留下的代码

作为软件工程师不可避免会遇到的一个场景是：我们在改变或添加一个功能到不是我们创建的、我们不熟悉的、与我们负责的系统部分无关的代码中时，会遇到麻烦。虽然这可能会是一个繁琐而艰巨的任务，但是由于使用其他开发人员编写的代码有很大的灵活性，所以我们可以从中得到大大的好处，包括增加我们的影响范围，修复软件腐烂以及学习我们以前不了解的系统部分(更何况，还可以学习其他程序员的技术和技巧)。

考虑到使用其他开发人员编写的代码既有其厌烦之处，又有其优势所在，所以我们必须小心不要犯一些严重的错误：

• 对未知的恐惧：很多时候，我们将要接触的代码是我们知之甚少或完全一无所知的。令人害怕的是：我们将对我们所做的任何改变负责，但是我们基本上就像是在没有光线的黑暗屋子里走动一样。其实我们不需要担心，而是应该构建一种使我们能够在大小不一的改变中感到舒适的结构，并允许我们确保没有破坏现有的功能。

1.确保测试的存在

要想确保在其他开发人员编写的代码中所存在的现有功能实际能够按照预期的方式工作，并且我们对其进行的任何更改都不会影响到功能的实现，唯一真正令人信心十足的方式是用测试来支持代码。当我们遇到另一位开发人员编写的代码时，代码有两种所处的状态：(1)没有足够的测试水平，或(2)有足够的测试水平。遇到前一种情况，我们得负责创建测试，而在后一种情况下，我们可以使用现有的测试来确保我们做出的任何更改都不会破坏代码，并尽可能多地从测试去了解代码的意图。

创建新测试

这是一个悲伤的例子：我们在改变其他开发人员的代码时，要对更改结果负责，但是我们没有办法保证我们在进行更改时不破坏任何东西。抱怨是没有用的。无论我们发现代码处在什么样的条件下，我们总归是要接触代码，因此如果代码坏掉了，就是我们的责任。所以我们在改变代码时，一定要掌控自己的行为。确定不会破坏代码的唯一方法是自己写测试。

虽然这是乏味的，但它允许我们通过编写测试来学习，这是它的主要优点。假设代码现在可以正常工作，而我们需要编写测试，以便预期的输入会导致预期的输出。在我们完成这个测试的过程中，我们逐渐了解到代码的意图和功能。例如，给出以下代码

1. public class SuccessfulFilterTest { 
2.     private static final double THRESHOLD_NET_SALARY = 68330.0; 
3.     @Test 
4.     public void under30AndNettingThresholdEnsureSuccessful() { 
5.         Person person = new Person(29, THRESHOLD_NET_SALARY); 
6.         Assert.assertTrue(new SuccessfulFilter().test(person)); 
7.     } 
8.     @Test 
9.     public void exactly30AndNettingThresholdEnsureUnsuccessful() { 
10.         Person person = new Person(30, THRESHOLD_NET_SALARY); 
11.         Assert.assertFalse(new SuccessfulFilter().test(person)); 
12.     } 
13.     @Test 
14.     public void under30AndNettingLessThanThresholdEnsureSuccessful() { 
15.         Person person = new Person(29, THRESHOLD_NET_SALARY – 1); 
16.         Assert.assertFalse(new SuccessfulFilter().test(person)); 
17.     } 
18. } 

我们对代码的意图以及为什么在代码中使用Magic number知道得并不多，但是我们可以创建一组测试，已知输入产生已知输出。例如，通过做一些简单的数学和解决构成成功的阈值薪水问题，我们发现如果一个人的年龄在30岁以下，且每年大概赚68,330美元，那么他被认为是成功的(按照本规范的标准)。虽然我们不知道那些magic number是什么，但是我们知道它们确实减少了初始的薪水值。因此，68,330美元的阈值是扣除前的基本工资。通过使用这些信息，我们可以创建一些简单的测试，例如：

1. public class SuccessfulFilterTest { 
2.     private static final double THRESHOLD_NET_SALARY = 68330.0; 
3.     @Test 
4.     public void under30AndNettingThresholdEnsureSuccessful() { 
5.         Person person = new Person(29, THRESHOLD_NET_SALARY); 
6.         Assert.assertTrue(new SuccessfulFilter().test(person)); 
7.     } 
8.     @Test 
9.     public void exactly30AndNettingThresholdEnsureUnsuccessful() { 
10.         Person person = new Person(30, THRESHOLD_NET_SALARY); 
11.         Assert.assertFalse(new SuccessfulFilter().test(person)); 
12.     } 
13.     @Test 
14.     public void under30AndNettingLessThanThresholdEnsureSuccessful() { 
15.         Person person = new Person(29, THRESHOLD_NET_SALARY – 1); 
16.         Assert.assertFalse(new SuccessfulFilter().test(person)); 
17.     } 
18. } 

通过这三个测试，我们现在对现有代码的工作方式有了大致的了解：如果一个人不到30岁，且每年赚$ 68,300，那么他被认为是成功人士。虽然我们可以创建更多的测试来确保临界情况(例如空白年龄或工资)功能正常，但是一些简短的测试不仅使我们了解了原始功能，还给出了一套自动化测试，可用于确保在对现有代码进行更改时，我们不会破坏现有功能。

使用现有测试

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

1. @Test 
2. public void under30AndNettingThresholdEnsureSuccessful() { 
3.     Person person = new Person(29, 75000.0); 
4.     Assert.assertTrue(new SuccessfulFilter().test(person)); 
5. } 

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

2.与编写代码的人交流

在涉及多个人的任何工作中，沟通至关重要。无论是企业，越野旅行还是软件项目，缺乏沟通是损害任务最有效的手段之一。即使我们在创建新代码时进行沟通，但是当我们接触现有的代码时，风险会增加。因为此时我们对现有的代码并不太了解，因此我们所了解的内容可能是被误导的，或只代表了其中的一小部分。为了真正了解现有的代码，我们需要和编写它的人交流。

当开始提出问题时，我们需要确定问题是具体的，并且旨在实现我们理解代码的目标。例如：

• 这个代码片段最适合放到系统的哪里/li>
• 你有什么设计或图表吗/li>
• 我应该注意什么陷阱/li>
• 这个组件或类是做什么的/li>
• 有没有什么你想放到代码里，但当时没有做的什么/li>

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

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

3.删除所有警告

心理学中有一个众所周知的概念，称为“破窗理论”，Andrew Hunt和Dave Thomas在《 The Pragmatic Programmer 》(第4-6页)中详细描述了这个概念。这个理论最初是由James Q.Wilson和George L. Kelling提出的，描述如下：

假设有一个建筑物有几扇破了的窗户。如果窗户没有修好，那么破坏者会趋向于打破更多的窗户。最终，他们甚至可能会破门而入，如果建筑物是没人住的，那么他们可能会非法占有或者在里面点火。也可以考虑人行道的情况。如果道路上面有垃圾堆积，那么不久之后，就会有更多的垃圾累积。最终，人们甚至会开始往那里扔外卖垃圾，甚至打破汽车。

这个理论指出，如果似乎已经没人关心这个物品或事物，那么我们就会忽视对物品或事物的照顾，这是人的天性。例如，如果一栋建筑物看上去已经凌乱不堪，那么它更有可能被肆意破坏。在软件方面，这个理论意味着如果开发人员发现代码已经是一团糟，那么人的本性会让他弄坏代码。从本质上说，我们心里想的是(即使心理活动没有这么丰富)，“既然最后一个人不在乎这代码，我为什么要在乎或“都是乱糟糟的代码，谁知道是谁写的。”

但是，这不应该成为我们的借口。只要我们接触以前属于其他人的代码，那么我们就要对这些代码负责，并且如果它不能有效工作的话，我们得担负后果。为了战胜这种人的天性行为，我们需要采取一些小措施以避免我们的代码更少地被弄脏(及时更换破掉的窗户)。

一个简单方法是删除来自我们正在使用的整个包或模块中的所有警告。至于未使用或添加注释的代码，删除它。如果我们稍后需要这部分代码，那么在存储库中，我们总是可以从先前的提交中检索它。如果存在无法直接解决的警告(例如原始类型警告)，那么使用@SuppressWarnings注解注释该调用或方法。这样可以确保我们对代码进行过仔细的考虑：它们不是因为疏忽而发出的警告，而是我们明确地注意到了警告(如原始类型)。

一旦我们删除或明确地禁止所有警告，那么我们就必须确保代码保持免除警告。这有两个主要作用：

• 迫使我们仔细考虑我们创建的任何代码。
• 减少代码腐败的变化，现在的警告会导致以后的错误。

这对其他人，以及我们自己都有心理暗示作用——我们其实关心我们正在处理的代码。它不再是条单行线——我们强逼着自己更改代码，提交，然后永不回头。相反，我们认识到我们需要对这代码负责。这对之后的软件开发也是有帮助的——它向将来的开发人员展示，这不是一间窗户都破了的仓库：而是一个维护良好的代码库。

4.重构

在过去几十年中，重构已经成为了一个非常重要的术语，并且最近被当作是对当前工作代码做任何改变的代名词。虽然重构确实涉及对当前正在工作的代码的更改，但并非整个大局。Martin Fowler在他关于这个话题的重要着作——《Refactoring》一书中将重构定义为：

• 对软件的内部结构进行更改，使其更容易理解并且修改起来更便宜，而不改变其可观察的行为。

这个定义的关键在于它涉及的更改不会改变系统可观察的行为。这意味着当我们重构代码时，我们必须要有方法来确保代码的外部可见行为不会改变。在我们的例子中，这意味着是在我们继承或自己开发的测试套件中。为了确保我们没有改变系统的外部行为，每当我们进行改变时，都必须重新编译和执行我们的全部测试。

此外，并不是我们所做的每一个改变都被认为是重构。例如，重命名方法以更好地反映其预期用途是重构，但添加新功能不是。为了看到重构的好处，我们将重构SuccessfulFilter。执行的第一个重构是提取方法，以更好地封装个人净工资的逻辑：

1. public class SuccessfulFilter implements Predicate { 
2.     @Override 
3.     public boolean test(Person person) { 
4.         return person.getAge() < > 60000; 
5.     } 
6.     private double getNetSalary(Person person) { 
7.         return (((person.getSalary() – (250 * 12)) – 1500) * 0.94); 
8.     } 
9. } 

在我们进行这种改变之后，我们重新编译并运行我们的测试套件，测试套件将继续通过。现在更容易看出，成功是通过一个人的年龄和净薪酬定义的，但是getNetSalary方法似乎并不像Person类一样属于SuccessfulFilter(指示标志就是该方法的唯一参数是Person，该方法的唯一调用是Person类的方法，因此对Person类有很强的亲和力)。 为了更好地定位这个方法，我们执行一个Move方法将其移动到Person类：

1. public class Person { 
2.     private int age; 
3.     private double salary; 
4.     public Person(int age, double salary) { 
5.         this.age = age; 
6.         this.salary = salary; 
7.     } 
8.     public void setAge(int age) { 
9.         this.age = age; 
10.     } 
11.     public int getAge() { 
12.         return age; 
13.     } 
14.     public void setSalary(double salary) { 
15.         this.salary = salary; 
16.     } 
17.     public double getSalary() { 
18.         return salary; 
19.     } 
20.     public double getNetSalary() { 
21.         return ((getSalary() – (250 * 12)) – 1500) * 0.94; 
22.     } 
23. } 
24. public class SuccessfulFilter implements Predicate { 
25.     @Override 
26.     public boolean test(Person person) { 
27.         return person.getAge() < > 60000; 
28.     } 
29. } 

1. public class Person { 
2.     private static final int MONTHLY_BONUS = 250; 
3.     private static final int YEARLY_BONUS = MONTHLY_BONUS * 12; 
4.     private static final int YEARLY_BENEFITS_DEDUCTIONS = 1500; 
5.     private static final double YEARLY_401K_CONTRIBUTION_PERCENT = 0.06; 
6.     private static final double YEARLY_401K_CONTRIBUTION_MUTLIPLIER = 1 – YEARLY_401K_CONTRIBUTION_PERCENT; 
7.     private int age; 
8.     private double salary; 
9.     public Person(int age, double salary) { 
10.         this.age = age; 
11.         this.salary = salary; 
12.     } 
13.     public void setAge(int age) { 
14.         this.age = age; 
15.     } 
16.     public int getAge() { 
17.         return age; 
18.     } 
19.     public void setSalary(double salary) { 
20.         this.salary = salary; 
21.     } 
22.     public double getSalary() { 
23.         return salary; 
24.     } 
25.     public double getNetSalary() { 
26.         return getPostDeductionSalary(); 
27.     } 
28.     private double getPostDeductionSalary() { 
29.         return getPostBenefitsSalary() * YEARLY_401K_CONTRIBUTION_MUTLIPLIER; 
30.     } 
31.     private double getPostBenefitsSalary() { 
32.         return getSalary() – YEARLY_BONUS – YEARLY_BENEFITS_DEDUCTIONS; 
33.     } 
34. } 
35. public class SuccessfulFilter implements Predicate { 
36.     private static final int THRESHOLD_AGE = 30; 
37.     private static final double THRESHOLD_SALARY = 60000.0; 
38.     @Override 
39.     public boolean test(Person person) { 
40.         return person.getAge() < > THRESHOLD_SALARY; 
41.     } 
42. } 

重新编译和测试，发现系统仍然按照预期的方式工作：我们没有改变外部行为，但是我们改进了代码的可靠性和内部结构。有关更复杂的重构和重构过程，请参阅Martin Fowler的Refactoring Guru 站。

5.当你离开的时候，代码比你发现它的时候更好

• 每当我们修改代码时，请确保当你离开的时候，代码比你发现它的时候更好。

前面提到过，我们需要对类造成的损坏和对改变的代码负责，如果它不能工作，那么修复是我们的职责。为了战胜伴随软件生产而出现的熵，我们必须强制自己做到离开时的代码比我们发现它的时候更佳。为了不逃避这个问题，我们必须偿还技术债务，确保下一个接触代码的人不需要再付出代价。说不定，将来可能是我们自己感谢自己这个时候的坚持呢。

原文链接

文章知识点与官方知识档案匹配，可进一步学习相关知识Git技能树首页概览2872 人正在系统学习中 相关资源：软件标书范本(技术部分)_软件技术标书-项目管理文档类资源-CSDN文库