列出的 5 个方法并不全面，但是使用下面的技术将确保在结束改动其他开发人员编写的代码时，我们有信心保持现有功能的工作状态，同时确保我们的新功能与现有的代码库协调一致。
1. 确保测试的存在要想确保在其他开发人员编写的代码中所存在的现有功能实际能够按照预期的方式工作，并且我们对其进行的任何更改都不会影响到功能的实现，唯一真正令人信心十足的方式是用测试来支持代码。当我们遇到另一位开发人员编写的代码时，代码有两种所处的状态：（1）没有足够的测试水平，或（2）有足够的测试水平。遇到前一种情况，我们得负责创建测试，而在后一种情况下，我们可以使用现有的测试来确保我们做出的任何更改都不会破坏代码，并尽可能多地从测试去了解代码的意图。 创建新测试这是一个悲伤的例子：我们在改变其他开发人员的代码时，要对更改结果负责，但是我们没有办法保证我们在进行更改时不破坏任何东西。抱怨是没有用的。无论我们发现代码处在什么样的条件下，我们总归是要接触代码，因此如果代码坏掉了，就是我们的责任。所以我们在改变代码时，一定要掌控自己的行为。确定不会破坏代码的唯一方法是自己写测试。
虽然现有的测试可以提供帮助，但我们仍然需要对此持保留态度。测试是否与代码的开发更改一起与时俱进是很难说的。如果是的话，那么这是一个很好的理解基础；如果不是，那么我们要小心不要被误导。例如，如果初始的工资阈值是每年 75,000 美元，而后来更改为我们的 68,330 美元这个测试还是会通过的，但没有了预期的作用。通过的原因不是因为它正好是阈值，而是因为它超出了阈值。如果此测试组件包含这样一个测试用例：当薪水低于阈值 1 美元时，过滤器就返回 false，这样第二个测试将会失败，表明阈值是错误的。如果套件没有这样的测试，那么陈旧的数据会很容易误导我们弄错代码的真正意图。当有疑问时，请相信代码：正如我们之前所表述的那样，求解阈值表明测试没有对准实际阈值。
另外，要查看代码和测试用例的存储库日志（即 Git 日志）：如果代码的最后更新日期比测试的最后更新日期更近（对代码进行了重大更改，例如更改阈值），则测试可能已经过时，应谨慎查看。注意，我们不应该完全忽视测试，因为它们也许仍然能为我们提供关于原作者（或最近撰写测试的开发人员）意图的一些文档，但它们可能包含过时或不正确的数据。 2. 与编写代码的人交流在涉及多个人的任何工作中，沟通至关重要。无论是企业，越野旅行还是软件项目，缺乏沟通是损害任务最有效的手段之一。即使我们在创建新代码时进行沟通，但是当我们接触现有的代码时，风险会增加。因为此时我们对现有的代码并不太了解，因此我们所了解的内容可能是被误导的，或只代表了其中的一小部分。为了真正了解现有的代码，我们需要和编写它的人交流。
蓝鸥科技西安中心，移动互联网科技育人专家，教育部产学合作协同育人项目承办企业，专注西安Java培训、西安大数据培训、西安unity培训，西安VR/AR培训、西安UI设计，西安HTML5培训、西安PHP培训，选择蓝鸥，不止高薪更是高起点！
898995850
