两个时间之间是多少小时_那是两个小时我不会回来

两个时间之间是多少小时

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

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

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

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

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

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

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

我希望我回来的两个小时

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

 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

两个时间之间是多少小时