經驗分享：乾淨整潔程式碼(clean code)的特點 - oliver

banq發表於2020-11-15

乾淨的程式碼很重要，乾淨的程式碼可以幫助其他人理解您的程式碼，但是乾淨的程式碼也很主觀！我想分享給您我的看法，它是由多年的開發人員領導技術團隊領導經驗和團隊合作而成。
乾淨的程式碼可以幫助人們理解程式碼。根據大多數開發人員的意見，您的程式碼結構越多（不是一地雞毛一盤散沙），其他開發人員就越可能理解您的程式碼！
乾淨程式碼的一些原則是：
  • 使用有意義且易於理解的識別符號
  • 使用函式並使其儘可能短
  • 如果您的程式碼易於閱讀，大部分時間您不需要註釋
  • 不要重複自己（DRY）
  • 保持簡單，愚蠢！(KISS)
  • 過早的最佳化是萬惡之源
  • 告訴一聲即可，不要索要（TDA：Tell, dont ask ）
  • Demeter定理
  • 關注點分離
  • 單一責任原則（SRP）
  • 開放封閉原則（OCP）
  • Liskov替代原則（LSP）
  • 介面隔離原則（ISP）
  • 依賴倒置原則（DIP）

簡潔的程式碼可幫助他人理解您的程式碼，每個開發人員都有自己的編碼風格。他們喜歡某些東西，而他們不喜歡。他們喜歡以某種方式做事，因為這對他們最有效。
透過利用眾所周知的原則並將其整合到我們自己的工作中，我們為其他意識到這些原則的人開啟了可能性，使他們更容易地進入我們的程式碼庫。
就像使用標準化技術一樣！以Dockerfile為例。如今，語法大多已標準化。如果您可以編寫一個可與​​Docker一起使用的Dockerfile，則還可以使用podman建立一個容器，因為大多數命令都是標準化的！
現在將其轉移到我們編寫程式碼的方式。您肯定可以想象，當許多開發人員利用相同的原理來編寫和構建其程式碼時，理解會變得更加容易！
乾淨的程式碼是主觀的，如上所示，乾淨的程式碼利用了許多原理。但是原則就是它們的名字。在某些情況下，幾乎不可能給所有人一個嚴格的方法來做事情。這導致對乾淨程式碼的許多解釋。
以可讀的識別符號為例。函式getDogs（ctx）{[...]}與函式getDogs（context）{[...]}對比，您能確定哪個更易讀嗎？如果您問5個開發人員，您會收到10個不同的答案。這是主觀部分的一個例子。
對於某些開發人員而言，縮寫ctx是眾所周知的，對於其他開發人員而言則並非如此，他們更喜歡識別符號上下文。方法的長度，介面太多或不足是同樣的。
與同事討論乾淨的程式碼，並將每條原則轉化為團隊的特定規則集。以團隊的方式共同決定程式碼的外觀。再次討論是否有人改變主意。
建立一套所有團隊成員都可以同意的規則和最佳實踐。這樣，接受度就會大大提高，人們將更願意遵循給定的規則。儘可能利用自動化，如linter等！
只要根據您的團隊的決定來配置工具，就無需進行人工工作或進行冗長的討論。如果工具說您做錯了，則必須進行調整。如果您認為該規則很糟糕，請作為一個團隊進行討論！
 
對於乾淨程式碼，許多初學者和/或新手程式設計師往往不知所措，這是可以理解的。他們不僅必須學習編寫程式碼，而且每個人都要求他們正確地編寫程式碼。
首先，最好將重點放在基礎知識上，然後在基礎堅實的情況下嘗試使用簡潔乾淨的程式碼。




 

相關文章