仔細看看

我建議您做一個練習：明天早上返回工作時，瀏覽項目的源代碼，并嘗試尋找重構的機會。 即使老板沒有要求也要這樣做。 這樣做是因為您想要一些激動人心的工作時間。

重構是改變已經可以正常工作的藝術 。 但是要進行重構，您需要一個借口。 可能是設計改進，性能問題，安全角色以及許多其他原因。 您要冒這個風險，以減少應用程序的技術支出，使其更加穩定，并在將來以某種方式提高您的生產率。

這不是與公司或老板相處融洽，而是與自己相處融洽。 為什么？ 因為問題往往會累積，在某些時候，您將失去對代碼的控制。 您將面臨艱難的時期來交付結果，這將毀掉您的職業。

好吧，讓我們從一個更光明的角度來看這件事。 您將在該過程中學到很多東西，并且很快就會意識到自己正在生產比以前更好的代碼。 您進行的重構越多，您就變得越聰明，直到達到創新水平為止。 但是，這是什么意思，您怎么知道自己要到達那里？

當您發現自己在做的事情上有明顯的改進機會時，就會發現創新，而您意識到到目前為止沒有人做過（至少您找不到）。 這并不容易，但是通常發生在您重復做某件事時，并且發現自己在考慮如何做才能更快或更干凈地做同一件事。 讓我用一個真實的故事來說明。

它與Java中的字符串連接有關：這是多年來許多專家強調的經典問題，如今可能已被忽略。 在JDK 1.5之前，盡管可讀性和簡單性強，但使用運算符“ +”進行的字符串連接可能會產生效率很低的代碼。 在后臺，此運算符被替換為等效的字節碼
StringBuffer ，實際上實現了串聯。 您使用“ +”運算符的次數越多，則在內存中將擁有更多的String和StringBuffer實例，以及用于管理所有這些對象的大量處理時間。 因此，開發人員被迫立即使用StringBuffer并忽略“ +”運算符。 看下面的例子：

String title = "Mr."; String name = "John"; String familyName = "Smith";String message = "Dear " + title + " " + name + " " + familyName + ",";

開發人員習慣于這樣寫，但是他們被迫寫這樣的：

StringBuffer sb = new StringBuffer(); sb.append("Dear "); sb.append(title); sb.append(" "); sb.append(name); sb.append(" "); sb.append(familyName); sb.append(",");

您可能同意我的觀點，第一個示例比第二個示例更具可讀性。 開發人員在連接字符串時使用“ +”運算符是很自然的，因此放棄該語法是不公平的。 幸運的是，編譯人員對此做了一些工作，確保JDK 1.5可以優化串聯。 他們沒有使用線程安全的類StringBuffer，而是創建了一個稱為StringBuilder的新類（非線程安全的，因此速度更快），并確保它的單個實例將處理所有串聯，如第一個示例所示。 這是一個重要的舉措，因為他們更喜歡優雅而不是技術。 第一個示例在編譯時自動轉換為如下形式：

StringBuilder sb = new StringBuilder(); sb.append("Dear ").append(title).append(" ").append(name).append(" ").append(familyName).append(",");

但是，非平凡邏輯中的串聯仍然需要您在代碼中編寫StringBuilder，因為編譯器還不那么聰明。 例如：

List<Student> students = studentBean.findStudents(); String intro = "The following students were approved:\n"; String listedNames = ""; String separator = ""; for(Student student: students) {if(student.approved()) {if(!listedNames.isEmpty()) {separator = ", ";}listedNames += separator + student.getName();} } String msg = intro + listedNames; messengerBean.sendMessage(msg);

像這樣寫會更有效：

List<Student> students = studentBean.findStudents(); String intro = "The following students were approved:\n"; StringBuilder listedNames = new StringBuilder(); String separator = ""; for(Student student: students) {if(student.approved()) {if(!listedNames.length() > 0) {separator = ", ";}listedNames.append(separator).append(student.getName());} } String msg = intro + listedNames.toString(); messengerBean.sendMessage(msg);

UPS！ 您注意到那里有什么奇怪的東西嗎？ 乍一看可能并不明顯，但請先看一下它們如何在定義分隔符之前檢查變量namedNames是否為空。 String類在JDK 1.6中引入了一個不錯的可讀方法isEmpty（），但是StringBuilder仍然使用這種相當古老的比較方式。 他們為什么不對StringBuilder和StringBuffer也這樣做呢？

在core-lib-dev郵件列表中討論了該問題 ，事實證明，他們之前沒有這樣做沒有明顯的原因。 也許他們只是忘記了。 由于進行了大量的重構，試圖改善 字符串連接的 低效 使用，因此有可能發現這種不一致 。 我相信他們仍有時間針對明年即將面世的Java 8進行修復。 他們將通過在CharSequence接口中添加isEmpty（）方法來解決此問題，以確保其他所有實現都同樣出色。

這可能很簡單，但是當Java因其過于冗長而受到批評時，每個細節都很重要。 因此，進行一些重構，找到機會來改進代碼以及用于編寫代碼的語言！ 讓我們前進Java！

參考： 仔細查看它，您會在Hildeberto的Blog博客上找到我們的JCG合作伙伴 Hildeberto Mendonca， 您需要改進 。

翻譯自: https://www.javacodegeeks.com/2013/05/look-at-it-carefully-and-you-will-find-something-to-improve.html

仔細看看

總結

以上是生活随笔為你收集整理的仔细看看_仔细看看，您会发现需要改进的地方的全部內容，希望文章能夠幫你解決所遇到的問題。

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