程序员：前任留下的代码你要怎么处理？(4)

这个理论指出，如果似乎已经没人关心这个物品或事物，那么我们就会忽视对物品或事物的照顾，这是人的天性。例如，如果一栋建筑物看上去已经凌乱不堪，那么它更有可能被肆意破坏。在软件方面，这个理论意味着如果开发人员发现代码已经是一团糟，那么人的本性会让他弄坏代码。从本质上说，我们心里想的是（即使心理活动没有这么丰富），“既然最后一个人不在乎这代码，我为什么要在乎？”或“都是乱糟糟的代码，谁知道是谁写的。”
但是，这不应该成为我们的借口。只要我们接触以前属于其他人的代码，那么我们就要对这些代码负责，并且如果它不能有效工作的话，我们得担负后果。为了战胜这种人的天性行为，我们需要采取一些小措施以避免我们的代码更少地被弄脏（及时更换破掉的窗户）。
一个简单方法是删除来自我们正在使用的整个包或模块中的所有警告。至于未使用或添加注释的代码，删除它。如果我们稍后需要这部分代码，那么在存储库中，我们总是可以从先前的提交中检索它。如果存在无法直接解决的警告（例如原始类型警告），那么使用@SuppressWarnings注解注释该调用或方法。这样可以确保我们对代码进行过仔细的考虑：它们不是因为疏忽而发出的警告，而是我们明确地注意到了警告（如原始类型）。
一旦我们删除或明确地禁止所有警告，那么我们就必须确保代码保持免除警告。这有两个主要作用：
迫使我们仔细考虑我们创建的任何代码。
减少代码腐败的变化，现在的警告会导致以后的错误。
这对其他人，以及我们自己都有心理暗示作用——我们其实关心我们正在处理的代码。它不再是条单行线——我们强逼着自己更改代码，提交，然后永不回头。相反，我们认识到我们需要对这代码负责。这对之后的软件开发也是有帮助的——它向将来的开发人员展示，这不是一间窗户都破了的仓库：而是一个维护良好的代码库。
4.重构
在过去几十年中，重构已经成为了一个非常重要的术语，并且最近被当作是对当前工作代码做任何改变的代名词。虽然重构确实涉及对当前正在工作的代码的更改，但并非整个大局。Martin Fowler在他关于这个话题的重要着作——《Refactoring》一书中将重构定义为：
对软件的内部结构进行更改，使其更容易理解并且修改起来更便宜，而不改变其可观察的行为。
这个定义的关键在于它涉及的更改不会改变系统可观察的行为。这意味着当我们重构代码时，我们必须要有方法来确保代码的外部可见行为不会改变。在我们的例子中，这意味着是在我们继承或自己开发的测试套件中。为了确保我们没有改变系统的外部行为，每当我们进行改变时，都必须重新编译和执行我们的全部测试。
此外，并不是我们所做的每一个改变都被认为是重构。例如，重命名方法以更好地反映其预期用途是重构，但添加新功能不是。为了看到重构的好处，我们将重构SuccessfulFilter。执行的第一个重构是提取方法，以更好地封装个人净工资的逻辑：