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

總結

以上是生活随笔為你收集整理的那是两个小时我不会回来的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。