大廠代碼重構最佳實踐，你真的會代碼重構嗎？

WHAT：什麼是重構？

Martin Fowler：重構是一種對軟件內部結構的改善，目的是在不改變軟件的可見行爲的狀況下，使其更易理解，修改爲本更低。

• 大型重構
  • 對象：對系統、模塊、代碼結構、類與類之間的關係等的重構
  • 方法：有分層垂直拆分、模塊化水平拆分、解耦、抽象UI組件、抽象業務組件、抽象區塊
  • 方法論：編程範式、設計原則、設計模式
  • 影響：代碼改動多，影響面廣，難度較大，耗時較長，引入BUG風險高
• 小型重構
  • 對象：對類、函數、變量等代碼級別的重構
  • 方法：規範命名(見名知意)、規範註釋、函數拆分、提取重複代碼、eslint等
  • 方法論：統一代碼風格、制定規範、語義化編程、eslint
  • 影響：影響面小，難度小，次數頻繁，引入BUG風險低

WHY：爲何要重構？

• 軟件最初設計的時候沒有考慮到所有的功能和細節
• 軟件需求變動和持續迭代致使原先的設計已不適用
• 消除破窗效應，當代碼裏面有了壞味道而不及時改善，容易破罐子破摔加速惡化

HOW：如何重構代碼？

• 靈活運用編程範式思想
  • 面向對象
  • 面向過程
  • 函數式編程
• 以設計原則爲核心
  • SOLID
  • KISS
  • DRY
  • YAGNI
  • LOD
  • CRP
• 以eslint爲基礎手段
  • airbnb
  • standard
  • recommanded
  • prettier
  • 自定義
• 以漸進式持續重構代碼爲方法論
• 優勢：持續集成、進度可控、過程可逆、不影響正常業務開發進度
• 按金字塔原則對項目代碼進行拆分
  • 業務模塊水平拆分
  • 代碼分層垂直拆分
• 評估出每個重構單元的耗時
  • 合理評估工做量
  • 權衡重構的性價比
  • 增長重構的可控性
• 正在作或規劃中的業務單元順手完成重構，其餘部分安排空閒時間依次重構
• 注意
  • 從0->1一次性完成重構的理想場景只存在於理想中。若是真實存在，只能說明項目太小或者已經趨於穩定迭代不多，這種狀況要考慮是否真的有重構的必要！！！
  • 不要有了錘子(重構方法論)，就滿世界去找釘子
  • 重構不是軟件開發的必要流程，而是現有代碼的組織缺陷或不合理的補救方式。
  • 養成好的代碼風格和code review的習慣避免代碼的壞味道纔是根本

WHEN：何時重構？

• 不要等到積重難返有了瓶頸以後再進行重構，大規模高層次的重構耗時耗力難度劇大
• 應該創建起漸進式持續重構的意識，發現當前業務代碼寫的有問題就應該及時進行小規模的重構，而不是欠一屁股技術債

BUG：重構會不會引入新的BUG？

會，因此怎麼辦呢？

• 經過完整的單元測試保證重構先後的外部可見性一致
• 有條件的話找專業的測試進行端到端測試和灰度測試

RISK：重構上線帶來BUG的風險怎麼解決？

若是不通知業務方直接將重構的代碼上線，一旦出現問題，你確定全責而且重構沒有功勞也沒有苦勞了

• 有條件的話找專業的測試進行端到端測試和灰度測試
• 必須通知業務方並說服業務方贊成，讓業務方作好準備上線後檢查一下。若是真的引入了bug也不太會追責，由於在預期內而且咱們的目標也是爲了項目的長遠發展呀

FEASIBILITY：如何讓業務方意識到現階段重構是必要的並贊成？

• 讓業務方、產品、測試看到開發中的痛點和技術上的瓶頸
• 讓全部人意識到縫縫補補破窗效應致使問題加重，已經積重難返了
• 強調重構帶來的技術收益和業務收益
• 提供切實可行並可控的重構計劃方案

PERFORMANCE：重構價值不被承認怎麼辦？

• 明明是你代碼寫的爛才致使的重構，浪費時間，還有臉要績效？想屁吃呢
  • 認可本身會寫bug，代表沒有不寫bug的程序員（敢於擔當並弱化責任，代表owner身份和地盤）
  • 指出致使重構的其餘緣由：需求頻繁變動，緊急需求倒排工時，沒有將業務長期規劃方向信息同步給開發，多人協做團隊沒有統一風格，團隊沒有code review，沒有eslint規範等等（代表主要責任不在我，可是我意識到了問題並主動解決了）
  • 強調重構帶來的優勢：BUG數量減小，維護成本降低，BUG排查變快，開發速度增高等（業務價值纔是績效的根本）

(ps：本博客用於學習總結，歡迎友好交流)