高質量程式碼的三大要素：

可讀性、可維護性和可變更性

做好程式碼規範、提高程式碼質量，能顯著增強程式碼的可讀性、可維護性和可變更性。努力提高程式碼的讀寫可維護性，是做好程式碼規範的必要非充分條件。程式碼規範和架構設計是軟體的靈魂所在，程式碼質量偏低，就像是人失去了三魂七魄中的一魄，就會喪失活力，影響正常執行，增加軟體交付後維護成本，出現推遲完成、超出預算、特性缺失等現象。

任何語言都需要強調編碼風格的一致性。只要是團隊開發，每個人都以相同的方式編寫程式碼就是至關重要的。這樣大家才能方便地互相看懂和維護對方的程式碼。

實際上，每家公司都會有一份（或多份）程式碼規範，因此提高程式碼的讀寫可維護性的關鍵在於是否能落實公司的相關文件，公司的技術總監、專案經理或相關程式碼審查機關是否具有應有的執行力。如果不能落實，那麼即便程式碼規範畫得再美，具體的程式碼也會醜到崩潰。

程式碼規範

如果不想為以後挖坑，做好程式碼規範是程式設計師和團隊負責人、專案經理的必修課。如何保證當前專案開發過程中壓力正常，而不是在後期面對過多的壓力、以至於噩夢纏身？最簡單的辦法就是照看好你的程式碼，也就是落實好公司的程式碼規範工作。每天為此付出一丁點的努力，便可以避免程式碼腐爛，並保證程式碼產品日後不至於變得難以理解（可讀性）和維護（可維護性）。

程式碼的可讀性

程式碼的可讀性是指程式碼讓人容易閱讀、跟蹤和理解的程度。提高程式碼的可讀性可以為程式碼閱讀者節約時間（避免閱讀時浪費過多無謂的時間）和精力（Debug、擴充套件功能或是效能優化的前提條件是你要讀懂這段程式碼）。以下是摘選的可供參考的策略：

• 編碼風格一致
• 程式碼清晰表達意圖
  • 寫別人看得懂的單詞，如果選用英語，那麼避免日語、法語和漢語拼音等，儘量使用語義化的命名組合；
  • PIE 原則：意圖清楚而且表達明確地程式設計；
  • 能夠讓人快速看懂（最低限度的要求是自己一個月後能快速讀懂）；
• 恰到好處的註釋
  • 不能太多或太少，註釋的形式根據程式碼具體的情況有不同；
  • 避免用註釋包裹程式碼；
  • 儘量留下簡明扼要的註釋；
• 評估取捨（不要編寫大段的程式碼）
  • 避免寫一些現在不需要、將來也不太可能需要的功能：
    • 不完美主義：不多寫程式碼（如會話儲存拆分）；
  • 避免做沒有太大價值的優化工作；
  • 區分任務的輕重緩急：
    • 頭疼醫頭也醫腳：先容忍失敗，再解決問題（如節點關閉邏輯）；
    • 不頭疼不醫頭：量化分析（如引數調整回滾等）；
  • 綜合考慮一下效能、便利性、生產力、成本和上市時間……
• 簡單就是美，避免簡單的功能寫出複雜的程式碼；
  • 保持簡單的程式碼遠比寫出複雜程式碼要難得多，但這是值得的；
  • 不編寫討巧的程式碼；
  • 避免無謂的條件巢狀和過度封裝；
  • 第一眼看上去就能知道其用處的程式碼，才是簡單而美的程式碼
  • 堅持操作方法的原子性，而後使用組合模式實現業務邏輯；
  • 避免大段程式碼，要寫高內聚、低耦合的程式碼；

程式碼的可維護性

軟體可維護性是指理解、改正、改動、改進軟體的難易程度。通常影響軟體可維護性的因素有可理解性、可測試性和可修改性。筆者這裡將其分為兩大類：編寫時可維護性和執行時可維護性。

編寫時可維護性

編寫時可維護性是指在程式或系統上線後爆出 BUG，開發團隊能夠及時撲滅這個 BUG 且不會爆出其他 BUG。保持方法的原子性，提高程式碼內聚，能使某處修改的影響降到最低，這樣某處方法出現 BUG，也不太會影響到其他模組的正常運作。編寫時可維護性還包括了程式碼的可測試性。

執行時可維護性

執行時的可維護性是指在系統執行過程中（或無需再次編碼釋出、只需系統重啟一次）修改系統的某項配置並使其生效，且不影響現在正在進行的業務和使用者的操作。這要求軟體工程師不能把程式碼寫死。例如配置檔案、資料庫連線字串、資原始檔、日誌等。

以下是摘選的可供參考的策略：

不要把程式碼寫死；

預測可能發生的變化

通過提高程式碼的複用性提高程式碼的可維護性

程式碼的可寫性

程式碼的可寫性包括程式碼的可變更性，程式碼的可變更性是軟體理論的核心。

程式碼的可寫性是建立在程式碼的可維護性上的，而程式碼的可寫性與可維護性又都建立在程式碼的可讀性上。如果程式碼難以閱讀，那麼 BUG 的修正將變得難以入手，新功能的新增就更是無從入手了。