來源：juejin.cn/post/6844904142960328718 前言 剛剛與同事開了一個分享會，筆者分享了一些了代碼設計模式相關的內容。 以及復盤了一下項目中有些複雜的業務場景，為什麼沒有很好的應用到設計模式。 業務雖然肯定保密的，但是拋開項目，業務層面，縱觀回顧了一下筆者以往的項目， ...
來源：juejin.cn/post/6844904142960328718
前言
剛剛與同事開了一個分享會，筆者分享了一些了代碼設計模式相關的內容。
以及復盤了一下項目中有些複雜的業務場景，為什麼沒有很好的應用到設計模式。
業務雖然肯定保密的，但是拋開項目，業務層面，縱觀回顧了一下筆者以往的項目，
關於設計模式和代碼規範問題還是有一些內容還是值得落筆和大家分享的。
設計模式究竟是什麼？
主流的說法，大致如此：
設計模式是解決可在許多不同情況下使用的問題的描述或模板，一般在OOP中最作為最佳實踐的解決方案。
最佳實踐一詞筆者再幾處介紹設計模式的地方，都有看到。但是設計模式真的就是OOP中，業務開發的最佳實踐嗎？
首先聲明筆者的觀點，我是如何理解設計模式的：
設計模式是一種代碼規範，不同於空格，縮進這類容易被插件檢測的入門規範，是一種中級代碼規範，不宜被入門者理解，不易被插件所檢測。
所以筆者認為設計模式是屬於代碼規範級別的，能不能成為最佳實踐，也要看使用者。
設計模式在常規業務開發的存在感
常常在網上能看到，很多人曬自己碰到的“祖傳代碼”，“龜派氣功式代碼”，“shǐ山代碼”等等。
我們不是有設計模式嗎？不是有代碼規範嗎？
幸存者偏差是一部分原因，只有爛代碼才會被掛出來讓人吐槽。
綜合來看這種情況還是很多，那麼是如何造成這種局面的，難道是這屆程式員水平不行？
代碼規範性或使用設計模式的痛點
筆者首先復盤了一些在業務開發中為什麼不能很好應用設計模式的因素。
性能
在極端的考慮下，例如Java語言，設計模式面臨著更多的類文件以及更多的代碼。
在類載入和記憶體使用上的成本，自然是略微高於不使用設計模式。
但是也不能一概而論，有些設計模式(如：單例模式，享元模式等)就是為了提高性能或節約資源成本而出現的。
以及大多數情況下，良好的代碼維護性優點要遠遠大於這點微小的性能開銷，所以性能用了刪除線。
類爆炸
雖然網上已經有各種設計模式的小Demo代碼，但是還是可能會出現設計存在缺陷，過度設計等情況。
複雜的設計模式，需要依靠業務建模，並不能拿來即用，甚至“生抄硬套”。
設計缺陷和過度設計，兩者對開發人員都是一樣痛苦的，會出現“不該用設計模式而用”，或者單純為了”迎合缺陷的設計模式”，寫出對應邏輯複雜的代碼，這樣類爆炸不可避免。
而且，就算正常使用的設計模式在業務複雜情況，類爆炸也不可避免。比如策略模式，如果業務情況就是有很多，你也必須把每個情況實現類寫出來。
這就對開發的時間成本有一些細微的影響了。
甚至據筆者所知，有些傳統公司，或者對日項目，幾乎一個類要有一個Excel文檔，詳細說明類和其中元素的作用。
你可能和我想的一樣，找個javadoc的api，逆向從註釋生成Excel不就完了嗎？
但實際上這類公司大多數還是靠人力完成這些工作的，類的數量多了起來，對維護文檔的人也是巨大挑戰。
團隊成員編碼水平
在傳統的軟體公司，出於節約成本考慮，很難做到人員全部“高配”並且能夠有自驅動的精神。
通常都是1拖N的人員配備，想讓薪資寥寥的初級工程師就有“高內聚，低耦合，以及開閉原則為代表的設計模式六大原則等”這類的設計思想，也是有點難為情。
此處說句題外話，
而且很多初級工程師其實對框架很“有適應性”的，當然並非真正的適應性。
比如：如果代碼里沒有統一異常處理，那麼時間長了你就會發現，到處都是自己的try catch。
再比如，項目里沒有引入工具類庫，那麼時間長了你就會發現，到處都是網上奇怪的util類，甚至每個類中都有重覆的工具方法。
這些不能算是初級工程師的問題，要歸結於技術負責人，比如觀察到了項目中還沒有工具庫，那麼是不是應該先去公司內部的二方庫中尋找，如果沒有是不是應該引入commons-lang3，hutool，guava這類的第三方優秀庫等等。
項目大環境
我們生存在一個高度架構為主的流量時代。高併發，大流量，各種微服務，以及中間件建設等等已經是主流趨勢。
那麼代碼層面的設計模式以及代碼規範性的地位，就有些微妙了。
筆者也見過不少項目，架構師只去考慮是不是該“加機器，加中間件，加配置”等上層建設。由於團隊成員水平斷檔，對代碼的要求幾乎為0，也沒有review等規則，能實現即可。
時間成本與敏捷開發
在敏捷開發場景，業務頻繁變動，項目快速迭代，這當然也是因素之一。
比如常說的可以優化if else的策略模式，如果初期只有一個分支，你會用設計模式嗎？那麼需求變動加了一個呢？如果又加了一個呢？
什麼時點選擇使用設計模式優化代碼，或者用不用優化，以及有沒有時間優化都是個問題。
通常有經驗的工程師，一般不會說出“這不就一行代碼嘛，一分鐘改完”這樣的話。
畢竟修改代碼，要思考全局性(是否其它代碼也有相同修改需求)，正確性，以及分支影響性(是否影響其他邏輯的執行)。
甚至也有公司對覆蓋率和測試類有要求，所以用打字速度判定需求落地速度，並不是業內人士的經驗之談。
這樣時間成本也成為了一個因素。
人員流動
人員流動在互聯網不是一個稀奇的事情。
一方面是公司原因，隨著改革春風吹滿地，已經到了遍地“老闆”的年代，一些公司，要求不合理，甚至條款都是違fa行為導致人才流失。二是個人原因，水平高為高薪所走，水平低被低薪勸退。
那麼不管那種原因，在人員頻繁流動下，代碼質量要想做好，對管理上也是一種挑戰。
畢竟如果你接手一個邏輯複雜的龜派氣功代碼，業務邏輯還沒完全清晰的場景下，大多數人會老老實實的添加if else以完成需求。
分析
代碼規範&設計模式重要嗎？
上文列舉了一些，在項目開發中代碼規範，以及使用設計模式上的一些痛點。
之所以稱之為痛點而不是缺點，原因就像上文有些場景，代碼都不是重要的一環，代碼規範更不值一提，何來缺點一說。
所以重不重要，綜合上文來看，除了主觀因素，團隊因素，甚至還有團隊管理者的原因。畢竟的確在一些場景，只是對開發人員友好，對KPI來講毫無用處，導致了不重視。
如何持續做好代碼規範
如果我們是有geek精神的團隊，或者要設計長時間維護的產品，還是建議做好代碼規範和設計模式的落地。
那麼就不妨從筆者總結的痛點上，結合自己當下場景逐條分析，取得一個“平衡”點。
筆者也大致總結了幾點，以應對上面的措施，但每個人都有每個人的情況，和設計模式本身一樣，不能“生抄硬套”。
- 深入理解業務，做好業務預判，這樣就為了底層設計打出良好基礎。
- 在保障人力成本的情況下，自驅性的成員在當今也不在少數，要給予信心一起做好基礎建設。
- 複雜的業務點頻繁迭代某個早期時刻，技術負責人需要切入，衡量工時分析業務，以便斷定是否需要重構，或者出代碼設計方案。
- 人員頻繁流動下，工作要儘量形成文檔，不能以“走形式”為主，不僅要良好交接代碼，還要良好交接業務。
- 傳統項目，對日項目要充分利用自動化工具，儘量多多代替人工的文檔維護。
當然了，本文提到的痛點，在中小公司最不難發現，更不是三言兩語就能解決，所以儘力做到平衡就非常好了。
如果不存在這些痛點，人員自驅性強，基礎建設良好等。大概率是足夠優秀的企業了，如果你是這樣企業的員工，還堅持看到這裡，那就當瞭解一下中小企業的小問題。
結尾
剛入行時，筆者也曾看著歷史代碼發出笑聲，“這麼亂的代碼，怕是喝了散裝假酒”。
時過境遷，隨著工作年限的增長，看問題的角度也在不斷發生變化，現在不僅不會發出嘲笑了，還總結了亂代碼出現的原因。
關於設計模式和代碼規範方面的思考也有了新的理解，也如上文所說，碰巧與同事開會提到了，所以整理成文。
近期熱文推薦：
1.1,000+ 道 Java面試題及答案整理(2022最新版)
4.別再寫滿屏的爆爆爆炸類了，試試裝飾器模式，這才是優雅的方式！！
覺得不錯，別忘了隨手點贊+轉發哦！
