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