iT邦幫忙

2021 iThome 鐵人賽

DAY 8
0
Software Development

成為乾淨的開發者吧! Clean Code, Clean Coder, Clean Architecture 導讀之旅系列 第 8

Day 08: 【結語】程式碼的氣味和啟發 (持續編輯中 54%... )

https://ithelp.ithome.com.tw/upload/images/20210923/20138643Xzv7RnxUF1.png

「這個手環就像是為我的職業道德做出了公開聲明。它是一個明顯的指示,代表我承諾 『我將盡己所能把程式寫到最好』。所以它仍在我的手腕上,當我寫程式時,不斷提醒著我對自己曾經做出過,撰寫 Clean Code 的承諾」

It’s a promise made to one’s self: "I will do a good job. I will not rush. I will write tests. I will go fast by going well. I will not write crap. And I will practice, practice practice so that I can be a professional."

取自: Clean Code (p.449)、What Software Craftsmanship is about


  • 關於本書 (Clean Code, aka 無瑕的程式碼)
    目前為止,Clean Code 70% 以上的內容都已概括介紹到 (筆者需要點時間修稿,敬請見諒 QQ),其中:
    • CH11: 系統,將於 Clean Architecture 一書開頭合併介紹 (省略 AOP 部分)
      作者本章花了些篇幅介紹 Java AOP,有興趣的讀者可自行研究: AOP 觀念與術語
    • CH13: 平行化,超出筆者能力所及 Orz...,故略過
    • CH.14-16 則算是作者針對 Java 某些函式庫進行實際重構的案例探討,這邊筆者嘗試將其改成很簡單的範例於系列文中穿插介紹

CH17: 程式碼的氣味和啟發 (Code Smells & Inspiration)

  • 這一節其實是一套有關軟體紀律的價值體系統整 (Clean 學派?)
  • 開發者們也可快速複習與檢核自己的專案是否犯過這些錯誤
  • 有興趣深入了解的讀者可自行購買 Uncle Bob 另一本專書: Refactoring

註解 (Comments)

C1: 不適當 & 不相關的資訊

C2: 廢棄 (Obsolete) & 不正確的註解

C3: 冗餘的註解

C4: 寫得不好的註解

C5: 被註解掉的程式碼 (Commented-Out Code)

  • 作者 Bob 表示: 這是非常令人厭惡的事物,會令人抓狂

開發環境 (Environments)

E1: 需要多個步驟以建立專案或系統

E2: 需要多個步驟以進行測試


函式 (Functions)

F1: 過多的參數 (Too Many Arguments)

F2: 輸出型參數 (Output Arguments)

F3: 旗標參數 (Flag Arguments)

F4: 被遺棄的函式 (Dead Function)


一般狀況 (General): Bad Examples

G1: 同份原始檔存在多種語言 (Multiple Languages in One Source File)

G2: 明顯該有的行為未被實現 (Obvious Behaviour is Unimplemented)

G3: 在邊界上的不正確行為 (Incorrect Behavior at the Boundaries)

G4: 無視安全規範 (Overridden Safeties)

G5: 重複的程式碼 (Duplication)

  • 這是本書中最重要的規範之一

G6: 在錯誤抽象層次上的程式碼 (Code at Wrong Level of Abstraction)

G7: 基底類別相依於其衍生類別 (Base Classes Depending on Their Derivatives)

G8: 過多的資訊 (TMI)

G9: 被遺棄的程式碼 (Dead Code)

G10: 垂直分隔 (Vertical Separation)

G11: 不一致性 (Inconsistency)

G12: 雜亂的程式 (Clutter)

G13: 人為的耦合 (Artificial Coupling)

G14: 特色留戀 (Feature Envy)

  • 這是作者 Martin Fowler 所提出的強烈程式碼氣味之一

G15: 選擇型參數 (Selector Arguments)

  • 沒有什麼比函式呼叫掛上一個 True / False 參數要來的令人厭惡

G16: 模糊的意圖 (Obscured Intent)

  • 魔術數字 (Magic Number)
  • 匈牙利命名法 (避免編碼)

G17: 錯置的職責

G18: 不適當的靜態宣告


一般狀況 (General): Good Examples

G19: 使用具解釋性的變數 (Use Explanatory Variables)

G20: 函式名稱要說到做到 (Function Names Should Say What They Do)

G21: 瞭解演算法 (Understand the Algorithm)

G22: 讓邏輯相依變成實體相依 (Make Logical Dependencies Physical)

G23: 用多型取代 If/Else 或 Switch/Case

G24: 遵循標準的慣例

  • 可回頭參見 Day 02

G25: 用有名稱的常數取代魔術數字

G26: 要精確

G28: 封裝條件判斷 (Encapsulate Conditionals)

G29: 避免否定的條件判斷

G30: 函式應該只做一件事

G31: 時序耦合 (Temporal Couplings)

G33: 封裝邊界條件 (Encapsulate Boundary Conditions)

G34: 函式內容只該下降一個抽象層

  • 劃分抽象層次概念,是進行函式重構時,最重要的行為之一

G35: 可調整的資料應放置於高階層次

G36: 避免傳遞性導覽


命名 (Names)

N1: 選擇具描述性質的名稱

  • 命名因素在程式可讀性上所佔的比率達 90%

N2: 在適當的抽象層次選擇適當的命名

N3: 盡可能使用標準命名法

N4: 非模稜兩可的名稱

N5: 較大範圍的視野使用較長的名稱


其他

J2: 不要繼承常數

J3: 常數 vs. 列舉 (Constants versus Enums)


測試 (Tests)

T2: 使用涵蓋率工具

T5: 測試邊界條件

T6: 在程式錯誤附近進行詳盡的測試

T7: 失敗的模式是某種啟示

T9: 測試要夠快速


  • 感謝所有追蹤到這邊的各位讀者們,您的支持與訂閱是我創作的最大動力
  • 希望各位開發者們都能夠在未來持續發揮專業精神,撰寫 Clean Code (無瑕的程式碼),如同 Martin Flower 所承諾:「我將盡己所能把程式寫到最好」

上一篇
Day 07: 類別、Kent Beck's 簡單設計守則 (持續編輯中 38%... )
下一篇
Day 09: 【番外篇】關於寫 Code 這件事 (持續編輯中 69%... )
系列文
成為乾淨的開發者吧! Clean Code, Clean Coder, Clean Architecture 導讀之旅31

尚未有邦友留言

立即登入留言