软件工程师经常会遇到一个问题，就是在改变和创建一个不属于自己创建的功能时，该怎样完美的将这一功能继续开发下去。可以说，这项工作是繁琐而艰巨的，上一任程序员将已经编写好的代码留给现任程序员，虽然获益匪浅，但同时也给现任程序员增加了难度。

现任开发人员在处理其他开发人员编写的代码时，会遇到哪些问题呢？在本文中，我们将确保我们可以使用的五种技术，以确保我们对人性的理解成为我们的优势，从现有代码和原始作者那里获得尽可能多的帮助，并使其他开发人员编写的代码更加优秀。虽然这里列出的五种方法并不全面，但使用下面的技术将确保当其他开发人员编写的代码结束时，我们有信心保持现有特性的工作状态，同时确保我们的新特性与现有的代码库保持一致。

1.确保测试的存在

为了确保其他开发人员编写的代码中的现有功能实际按预期工作，并且我们对其所做的任何更改不会影响功能的实现，测试用于支持代码的唯一真正自信的方式。当我们遇到开发人员编写的另一个代码时，代码有两种状态：1。没有足够的测试级别2，并且有足够的测试级别。在前一种情况下，我们必须负责创建测试，在后一种情况下，我们可以使用现有的测试来确保我们所做的任何更改都不会破坏代码并尽可能地远离测试。理解代码的意图。

2.与编写代码的人交流

在任何涉及多人的工作中，沟通都是必不可少的。无论是商务、跨国旅游还是软件项目，缺乏沟通都是破坏任务最有效的手段之一。即使我们在创建新代码时进行通信，当我们接触到现有代码时，风险也会增加。因为我们目前对现有代码不太了解，所以我们所知道的可能会被误导，或者只代表其中的一小部分。为了真正理解现有的代码，我们需要与编写代码的人进行交流。

3.删除所有警告

心理学中有一个众所周知的概念叫做“破窗理论”。这个理论指出，如果没有人关心这个项目或事物，那么我们将忽略对项目或事物的关心。这是人性。在软件方面，这个理论意味着如果开发人员发现代码已经是混乱，那么人性将使他破坏代码。从本质上讲，我们的想法是（即使心理活动不那么丰富），“因为最后一个人不关心这个代码，我为什么要关心？”或者“这是一个混乱的代码，谁知道谁写了它。”

但这不应该成为我们的借口。只要我们接触到以前属于他人的代码，我们就要对该代码负责，如果它不能有效地工作，我们就必须承担后果。为了克服这种人性，我们需要采取一些小步骤来防止代码变脏。

一种简单的方法是从我们正在使用的整个软件包或模块中删除所有警告。对于未使用或注释的代码，请将其删除。如果以后需要此代码，在存储库中，我们可以始终从以前的提交中检索它。如果存在无法直接解析的警告（例如，原始类型警告），请使用the@SuppressWarnings注释注释呼叫或方法。这确保我们仔细考虑了代码：它们不是由于疏忽造成的警告，但我们已清楚地注意到警告（如原始类型）。