正如我之前关于linting主题所说的 ，花时间修改代码的好处很有限，因为自动工具告诉您这样做。 更糟糕的是，这些工具并非万无一失。

例如，我们一直在针对完美无害的try-with-resources构造周围的SpotBugs警告中添加排除项，这在Java 11中不太像。类似地，SonarQube看起来对特定的静态方法有麻烦进口。 不知道为什么，浪费时间安抚这些工具。

进行静态分析并执行所说的那样的两难选择是，如果您花时间去做它所说的话，很难看到好处，但是如果您不这样做，那么可能会有一些更糟的副作用：

• 一些代码布局开始成为人们的意见–整个团队的意见各不相同
• 代码中包含一些晦涩的问题，没有人注意到它们
• 总体质量和对质量的关注下降

这是第二个最令人沮丧的情况。 感谢一些静态分析工具，最近我修复了一个数字的性能，安全性和稳定性错误。 我不认为其中任何一个都是可以保证的失败，但是每个人都有可能浪费我们一些稀缺的计算资源，或者给项目增加风险。

如果我没有注意整个问题，并试图将计数降到最低，我可能没有注意到这些问题。

因此，这是必须要做的。 这就像在撒粉。 如果离开它，突然有很多事情要做，情况可能会比您想象的更糟。

我希望我回来的两个小时

SonarQube的建议之一是替换Java类Stack Deque 。 这是我们的代码：

 Stack<StringBuilder> tags = new Stack<>();  void onNewElement() { tags.add( new StringBuilder());  }  void onNewData(String data) { tags.peek().append(data);  }  void onEndElement() { save(tags.pop());  } 

我已经简化了一点。 它正在读取XML，并允许使用嵌套的层次结构，在该结构中您需要诸如元素堆栈之类的东西才能遍历该层次结构。

我想我能做的就是用Deque代替Stack ，尤其是将LinkedList替换为实现–一个很好的灵活数据结构。

此项目的构建大约需要15分钟。

失败了

我仔细查看了为SonarQube所做的所有更改，并开始做出有根据的猜测，可能会造成破坏。 尽管从这篇文章来看，似乎必须归咎于Stack重构（restacktor？），但我还有其他一些人选，因此丢失了一些构建周期。

最终，我回到了Stack ，大约15分钟后，构建了一个绿色版本。

在这一点上，我要感谢过去的我，因为我编写了足够敏感的测试自动化程序来发现此问题，特别是因为这是对原来没有有用测试的旧代码库的重做。

您发现错误了吗？

一旦确定了修复程序，我就不想因为不知道发生了什么而把自己扔了， 因为伏都教... oooooh！

因此，我问自己为什么Stack和LinkedList可能表现不同。

然后我注意到Stack方法的使用：

• peek –必须正确
• pop -经典
• add – w？

为什么我们将堆栈视为add / pop ？ 当然应该push / pop吗？

就是这样。 降低实现细节，事实证明LinkedList将head元素视为堆栈的顶部，但在尾部添加了新元素（这是链表的工作方式）。 相反， Vector ，底层实现的Stack增加了结束，也不会peek ，并pop从结束。 如果您是数组，则不希望在周围乱洗元素。

时间小偷

因此，这里有两个时间小偷：

• 有人不一致地使用API​​来实现堆栈-导致此奇怪的迁移错误
• 该死的15分钟建立

如果我的构建只有2分钟，那么所有这些都不会花费很长时间……此测试需要大量设备才能运行。 这样做有充分的理由，但是这仍然是巨大的开销，并且需要实时。

TL; DR

如果您编写肮脏的代码，迟早它将赶上您或其他人。 整理工具虽然可能会很痛苦，但它们最终在减少基线异常方面做得很好，但是它们可以在过程中浪费您的时间。

翻译自: https://www.javacodegeeks.com/2020/05/thats-two-hours-i-wont-get-back.html