两个数的简单计算器_那是我两个小时都不会回来的

两个数的简单计算器

正如我之前关于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

两个数的简单计算器