java代碼識別

作為軟件開發人員，我們不僅要編寫有效的代碼，而且還要編寫可維護的代碼，這是我們的責任。 Martin Fowler在他的《重構：改進現有代碼的設計》中將代碼氣味定義為：

通常對應于系統中更深層問題的表面指示

重構是在不影響代碼外部行為的情況下改進代碼內部結構的過程。 理想情況下，我們應該在添加新功能的同時重構舊代碼。 與嘗試一次完成所有操作相比，這將節省我們一些時間。

Fowler的書是極好的資源，可以幫助我們識別并消除一些常見的代碼異味。 在編寫代碼以滿足新要求時，我們還應該避免這些代碼的味道。

在本教程中，我們將探索其中的一些。

1.評論：

理想情況下，我們應該編寫能說明一切的代碼。 進行大量評論被認為是不好的做法。 當我們使用大量評論時，它們通常會隨著時間的推移而失去同步。 對于有時設計不當的系統，它們有時還會起到除臭劑的作用。

如果我們有一個好的設計并且正確地命名了我們的類，方法和變量，那么代碼將輕松地將其目的傳達給另一個開發人員。

一些開發人員喜歡在他們創建的新類上簽名自己的名字。 我個人不建議這樣做，因為使用任何版本控制系統都可以輕松地跟蹤作者。

注釋在某些情況下可能會很有用，但請謹慎使用。

2.重復的代碼：

復制代碼是當我們在代碼庫的多個位置分布相似的代碼時看到的代碼味道。 這是一個結構不良的代碼，我們應該找到某種方法以單獨的方法提取出通用功能。

代碼重復的問題在于，如果要進行更改，則必須修改所有這些文件以適應該更改。 我們有可能錯過一些代碼塊中的更新。

讓我們盡一切可能堅持DRY（不要重復自己）的原則。 根據DRY原則，我們不應該重寫已經編寫的功能。

3.長方法：

我們應該避免使用長方法，這是一種不好的代碼味道。 太長的方法很難閱讀，很難適應它的新變化。 在開發人員中經常爭論多長時間。 就我個人而言，我更喜歡遵循方法大小的規則，該規則的大小不應超過十五行代碼。 在大多數情況下，此規則對我來說效果很好。

每當我看到自己違反此規則時，就會問自己： “此方法僅做一件事情（SRP原理）嗎？” 。 如果沒有，那么我嘗試在邏輯上將我的方法拆分為更有意義的方法。

盡管使用長方法有時會很好，但約束是我們應該有足夠的理由來證明它合理。

4.大班：

不出所料，我們列表中的下一個是大型類代碼氣味。 大型課程通常也稱為“上帝課程”或“斑點或黑洞課程”。

在大型系統中，我們經常會遇到這種代碼異味。 隨著系統的發展，某些類最終會在一段時間內支持添加到其中的許多功能。 盡早捕獲此代碼氣味是個好主意。 如果一個類變得太大，則稍后將花費大量時間和精力進行修復。

根據“ 單一職責原則”（SRP），一個類必須恰好做一件事，并且要做到這一點。 在向現有類添加一些代碼時，讓我們利用開發人員的直覺并自問： “此類是否真的應該支持此功能？”。 如果沒有，最好將其放置在其他位置。

5.長參數列表：

另一個類似的代碼味道是長參數列表。 長參數列表的方法可能難以使用，并且由于疏忽而增加了錯誤映射的可能性：

public void doSomething(String name, int id, String deptCode, String regNumber) { ?... }

此處的解決方案是引入捕獲上下文的參數對象。 因此，我們可以將上述方法改進為：

public void doSomething(Student student) { ... }

在這里，我們已經實現了正確的封裝。

6.數據類別：

數據類是僅包含數據成員及其獲取器和設置器的類：

public class Student { ?private int id; private String name; ?//constructor, getters and setters ? }

這通常表明它可能不是一個很好的抽象。

盡管我們創建參數對象來解決“長參數”代碼的味道， 但理想情況下 ， 我們應該設計類，而不僅僅是存儲數據。

我們應該問類似的問題： “我可以向當前在其他地方處理的此類添加一些功能嗎？”

有時，當我們在代碼庫中的多個地方處理了這些數據類的功能時，就會意識到出現重復的代碼味道。

7.發散類：

當我們意識到由于許多不同的原因而不得不以許多不同的方式更改一個類時，就會產生不同的類代碼氣味。

正如我們前面討論的，類應僅具有一個特定的目的。 如果是這樣，我們將有較少的理由要對類進行更改，并且要在其中進行的更改也較少。

如果我們發現自己以多種方式更改了一個類，那么這很好地表明該類的職責需要分解為單獨的類。

8.消息鏈：

消息鏈是一種代碼氣味，我們在對象上調用一個方法，然后在該返回的對象上調用另一個方法，依此類推：

int id = obj.getDept().getSubDept().getHOD().getId();

較長的消息鏈使我們的系統變得僵硬，難以獨立測試。

它通常還違反Demeter法則，該法則規定了良好的面向對象設計應允許調用哪些方法。

9. Shot彈槍手術：

realize彈槍手術是一種代碼氣味， 當我們意識到我們必須觸摸許多類以針對一個簡單的要求進行更改時 ， 就會發生這種氣味。 當觸及我們代碼庫中的許多地方時，很可能會引入錯誤并破壞現有的實現。

對于設計良好的系統，較小的更改將理想地要求將本地更改更改為一兩個位置。 雖然，這很難實現，但是無論我們對代碼的設計水平如何，有時都需要進行shot彈槍手術。

我們可以通過移動方法來解決the彈槍外科手術代碼的氣味。 如果更改要求我們修改多個類中的方法，我們應該問自己： “這些方法應該合并為一兩個類嗎？” 然后讓我們的開發者本能引導我們。

10.功能嫉妒：

功能嫉妒是一種代碼氣味，當我們擁有的方法對其他類的詳細信息比對其中的類更感興趣時，就會發生這種情況。

如果兩個或多個方法總是互相交談，則它們很可能必須屬于同一類。

11.不適當的親密關系：

當兩個類通過雙向通信彼此之間過于依賴時，這是不適當的親密代碼氣味。

在班級之間進行雙向交流使他們緊密地聯系在一起。 我們至少應將某些方法分解為一個單獨的類，并以消除這種循環為目標。 我們應該設計易于理解和維護的類。

12.原始癡迷：

顧名思義，我們有時過于依賴原始類型。 盡管我們在代碼中需要基元，但它們應存在于代碼的最低級別。

我們應該避免過度使用原語，并在需要時定義合適的類。

13.投機性：

有時， 我們會過度設計諸如定義超類或某些當前不需要的代碼之類的東西，但是我們認為有一天可能會有用。 此代碼氣味被稱為推測性普遍性。

敏捷開發促進采用準時設計。 我們的設計應該保持簡單，并且應該足以支持當前的功能。 用戶需求經常快速變化，因此，僅在必要時才應引入概括。 否則，我們可能最終將時間浪費在最終從未使用過的設計上。

14.拒絕的請求：

當子類繼承某些東西但不需要它時，就會出現拒絕請求代碼的氣味。

如果子類繼承了它們不使用的東西，則它們可能不是超類的適當子類：

public class Bird { ?void fly() { System.out.println( "Flying!!" ); } } ? public class Ostrich extends Bird { ?void fly() { throw new IllegalStateException( "An ostrich can't fly" ); } }

顯然，鴕鳥不會飛行，因此這是拒絕請求代碼氣味的一個示例。 我們可以通過以下方式之一來處理此代碼異味：

• 要么不要在超類中定義不需要的行為，要么
• 將它們創建為單獨的獨立類

結論：

在本教程中，我們研究了一些代碼氣味，并學習了如何避免和處理它們。

該列表顯然并不詳盡，但可以證明是快速入門指南。

翻譯自: https://www.javacodegeeks.com/2019/09/identifying-code-smells-in-java.html

java代碼識別

總結

以上是生活随笔為你收集整理的java代码识别_识别Java中的代码气味的全部內容，希望文章能夠幫你解決所遇到的問題。

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