我建議您做一個(gè)練習(xí)：明天早上返回工作時(shí)，瀏覽項(xiàng)目的源代碼，并嘗試尋找重構(gòu)的機(jī)會(huì)。 即使您的老板不要求也這樣做。 這樣做是因?yàn)槟胍恍┘?dòng)人心的工作時(shí)間。

重構(gòu)是改變已經(jīng)可以正常工作的藝術(shù) 。 但是要進(jìn)行重構(gòu)，您需要一個(gè)借口。 可能是設(shè)計(jì)改進(jìn)，性能問題，安全角色以及許多其他原因。 您要冒這個(gè)風(fēng)險(xiǎn)，以減少應(yīng)用程序的技術(shù)支出，使其更加穩(wěn)定，并在將來以某種方式提高您的生產(chǎn)率。

這不是與公司或老板相處融洽，而是與自己相處融洽。 為什么？ 因?yàn)閱栴}往往會(huì)累積，在某些時(shí)候，您將失去對代碼的控制。 您將面臨艱難的時(shí)期來交付結(jié)果，這將毀掉您的職業(yè)生涯。

好吧，讓我們從一個(gè)更光明的角度來看這件事。 在此過程中，您將學(xué)到很多東西，并且很快就會(huì)意識(shí)到，您正在生產(chǎn)比以前更好的代碼。 您進(jìn)行的重構(gòu)越多，您就變得越聰明，直到達(dá)到創(chuàng)新水平為止。 但是，這是什么意思，您怎么知道自己要到達(dá)那里？

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

它與Java中的字符串連接有關(guān)：這是多年來許多專家強(qiáng)調(diào)的經(jīng)典問題，如今可能已被忽略。 在JDK 1.5之前，盡管可讀性和簡單性強(qiáng)，但使用運(yùn)算符“ +”進(jìn)行的字符串連接可能會(huì)產(chǎn)生非常低效的代碼。 在后臺(tái)，此運(yùn)算符被替換為等效的字節(jié)碼
StringBuffer ，實(shí)際上實(shí)現(xiàn)了串聯(lián)。 您使用“ +”運(yùn)算符的次數(shù)越多，則在內(nèi)存中擁有的String和StringBuffer實(shí)例將越多，并且需要大量的處理時(shí)間來管理所有這些對象。 因此，開發(fā)人員被迫立即使用StringBuffer并忽略“ +”運(yùn)算符。 看下面的例子：

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

開發(fā)人員習(xí)慣于這樣寫，但是他們被迫編寫這樣的寫法：

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

您可能同意我的觀點(diǎn)，第一個(gè)示例比第二個(gè)示例更具可讀性。 開發(fā)人員在連接字符串時(shí)使用“ +”運(yùn)算符是很自然的，因此放棄該語法是不公平的。 幸運(yùn)的是，編譯人員為此做了一些工作，確保JDK 1.5可以優(yōu)化串聯(lián)。 他們沒有使用線程安全的類StringBuffer，而是創(chuàng)建了一個(gè)稱為StringBuilder的新類（非線程安全的，因此速度更快），并確保它的單個(gè)實(shí)例可以處理所有串聯(lián)，如第一個(gè)示例所示。 這是一個(gè)重要的舉措，因?yàn)樗麄兏嗖A優(yōu)雅而不是技術(shù)。 第一個(gè)示例在編譯時(shí)自動(dòng)轉(zhuǎn)換為如下形式：

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

但是，非平凡邏輯中的串聯(lián)仍然需要您在代碼中編寫StringBuilder，因?yàn)榫幾g器還不那么聰明。 例如：

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);

像這樣寫會(huì)更有效：

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！ 您注意到那里有什么奇怪的東西嗎？ 乍一看可能并不明顯，但是請先看一下它們?nèi)绾卧诙x分隔符之前檢查變量namedNames是否為空。 String類在JDK 1.6中引入了一個(gè)不錯(cuò)的可讀方法isEmpty（），但StringBuilder仍然使用這種相當(dāng)古老的比較方式。 他們?yōu)槭裁床粚tringBuilder和StringBuffer也這樣做呢？

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

這可能很簡單，但是當(dāng)Java因其過于冗長而受到嚴(yán)厲批評(píng)時(shí)，每個(gè)細(xì)節(jié)都很重要。 因此，進(jìn)行一些重構(gòu)，找到機(jī)會(huì)來改進(jìn)代碼以及用于編寫代碼的語言！ 讓我們前進(jìn)Java！

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

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。