設計模式 + 代碼規(guī)范落地之路

前言

剛剛與同事開了一個分享會，筆者分享了一些了代碼「設計模式」相關的內(nèi)容。

以及復盤了一下項目中有些復雜的業(yè)務場景，為什么沒有很好的應用到「設計模式」。

業(yè)務雖然肯定保密的，但是拋開「項目」，「業(yè)務」層面，縱觀回顧了一下筆者以往的項目，關于「設計模式」和「代碼規(guī)范」問題還是有一些內(nèi)容還是值得落筆和大家分享的。

正文

設計模式究竟是什么？

主流的說法，大致如此：

設計模式是解決可在許多不同情況下使用的問題的描述或模板，一般在OOP中最作為最佳實踐的解決方案。

最佳實踐一詞筆者在幾處介紹設計模式的地方，都有看到。

但是設計模式真的就是 OOP 中，業(yè)務開發(fā)的最佳實踐嗎？

首先聲明筆者的觀點，我是如何理解設計模式的：

設計模式是一種代碼規(guī)范，不同于「空格」，「縮進」這類容易被插件檢測的入門規(guī)范，是一種「中級代碼規(guī)范」，不宜被入門者理解，不易被插件所檢測。

所以筆者認為「設計模式」是屬于「代碼規(guī)范」級別的，能不能成為「最佳實踐」，也要看使用者。

設計模式在常規(guī)業(yè)務開發(fā)的存在感

常常在網(wǎng)上能看到，很多人曬自己碰到的“祖?zhèn)鞔a”，“龜派氣功式代碼”，“shǐ山代碼”等等。

我們不是有設計模式嗎？不是有代碼規(guī)范嗎？

幸存者偏差是一部分原因，只有爛代碼才會被掛出來讓人吐槽。

綜合來看這種情況還是很多，那么是如何造成這種局面的，難道是這屆程序員水平不行？

代碼規(guī)范性或使用設計模式的痛點

筆者首先復盤了一些在「業(yè)務開發(fā)」中為什么「不能很好應用設計模式」的因素。

性能

在極端的考慮下，例如Java語言，設計模式面臨著「更多的類文件」以及「更多的代碼」。

在類加載和內(nèi)存使用上的成本，自然是略微高于不使用設計模式。

但是也不「能一概而論」，有些設計模式(如：單例模式，享元模式等)就是為了「提高性能」或「節(jié)約資源」成本而出現(xiàn)的。

以及大多數(shù)情況下，良好的代碼維護性優(yōu)點要遠遠大于這點微小的性能開銷，所以性能用了刪除線。

類爆炸

雖然網(wǎng)上已經(jīng)有各種設計模式的小 Demo 代碼，但是還是可能會出現(xiàn)「設計存在缺陷」，「過度設計」等情況。

復雜的設計模式，需要依靠業(yè)務建模，并不能拿來即用，甚至“「生抄硬套」”。

設計缺陷和過度設計，兩者對開發(fā)人員都是一樣痛苦的，會出現(xiàn)“「不該用設計模式而用」”，或者單純?yōu)榱恕?strong style="color: rgb(53, 148, 247);">「迎合缺陷的設計模式」”，寫出對應邏輯復雜的代碼，這樣類爆炸不可避免。

而且，就算正常使用的設計模式在業(yè)務復雜情況，類爆炸也不可避免。比如策略模式，如果業(yè)務情況就是有很多，你也必須把每個情況實現(xiàn)類寫出來。

這就對開發(fā)的時間成本有一些細微的影響了。

甚至據(jù)筆者所知，有些「傳統(tǒng)公司」，或者對日項目，幾乎一個類要有一個Excel文檔，詳細說明類和其中元素的作用。

你可能和我想的一樣，找個 javadoc 的 api，逆向從注釋生成 Excel 不就完了嗎？

但實際上這類公司大多數(shù)還是靠「人力」完成這些工作的，類的數(shù)量多了起來，對維護文檔的人也是巨大挑戰(zhàn)。

團隊成員編碼水平

在傳統(tǒng)的軟件公司，出于節(jié)約成本考慮，很難做到人員全部“高配”并且能夠有自驅動的精神。

通常都是 1 拖 N 的人員配備，想讓薪資寥寥的初級工程師就有“「高內(nèi)聚」，「低耦合」，以及「開閉原則」為代表的設計模式六大原則等”這類的設計思想，也是有點難為情。

此處說句題外話。

而且很多初級工程師其實對框架很“「有適應性」”的，當然「并非真正的適應性」。

比如：如果代碼里沒有「統(tǒng)一異常處理」，那么時間長了你就會發(fā)現(xiàn)，到處都是自己的 try catch。

再比如，項目里沒有引入工具類庫，那么時間長了你就會發(fā)現(xiàn)，到處都是網(wǎng)上奇怪的 util 類，甚至每個類中都有重復的工具方法。

這些不能算是初級工程師的問題，要歸結于「技術負責人」，比如觀察到了項目中還沒有工具庫，那么是不是應該先去公司內(nèi)部的「二方庫」中尋找，如果沒有是不是應該引入 commons-lang3，hutool，guava 這類的第三方優(yōu)秀庫等等。

項目大環(huán)境

我們生存在一個「高度架構」為主的「流量時代」。高并發(fā)，大流量，各種微服務，以及中間件建設等等已經(jīng)是主流趨勢。

那么代碼層面的「設計模式」以及代碼規(guī)范性的地位，就有些微妙了。

筆者也見過不少項目，架構師只去考慮是不是該“加機器，加中間件，加配置”等上層建設。由于團隊成員水平斷檔，對代碼的要求幾乎為「0」，也沒有review等規(guī)則，能實現(xiàn)即可。

時間成本與敏捷開發(fā)

在敏捷開發(fā)場景，業(yè)務頻繁變動，項目快速迭代，這當然也是因素之一。

比如常說的可以優(yōu)化 if else 的「策略模式」，如果初期只有一個分支，你會用設計模式嗎？那么需求變動加了一個呢？如果又加了一個呢？

什么時間點選擇使用「設計模式」優(yōu)化代碼，或者用「不用優(yōu)化」，以及「有沒有時間優(yōu)化」都是個問題。

通常有經(jīng)驗的工程師，一般不會說出“這不就一行代碼嘛，一分鐘改完”這樣的話。

畢竟修改代碼，要思考「全局性」(是否其它代碼也有相同修改需求)，「正確性」，以及「分支影響性」(是否影響其他邏輯的執(zhí)行)。

甚至也有公司對「覆蓋率」和「測試類」有要求，所以用打字速度判定需求落地速度，并不是業(yè)內(nèi)人士的經(jīng)驗之談。

這樣時間成本也成為了一個因素。

人員流動

人員流動在互聯(lián)網(wǎng)不是一個稀奇的事情。

一方面是「公司原因」，隨著改革春風吹滿地，已經(jīng)到了遍地“老板”的年代，一些公司，要求不合理，甚至條款都是違fa行為導致人才流失。

二是「個人原因」，水平高為高薪所走，水平低被低薪勸退。

那么不管那種原因，在人員頻繁流動下，代碼質(zhì)量要想做好，對管理上也是一種挑戰(zhàn)。

畢竟如果你接手一個邏輯復雜的「龜派氣功代碼」，業(yè)務邏輯還沒完全清晰的場景下，大多數(shù)人會老老實實的添加if else以完成需求。

分析

代碼規(guī)范&設計模式重要嗎？

上文列舉了一些，在項目開發(fā)中「代碼規(guī)范」，以及「使用設計模式」上的一些痛點。

之所以稱之為「痛點」而不是「缺點」，原因就像上文有些場景，代碼都不是重要的一環(huán)，代碼規(guī)范更不值一提，何來缺點一說。

所以重不重要，綜合上文來看，除了主觀因素，團隊因素，甚至還有團隊管理者的原因。畢竟的確在一些場景，只是對開發(fā)人員友好，對 KPI 來講毫無用處，導致了不重視。

如何持續(xù)做好代碼規(guī)范

如果我們是有「geek精神」的團隊，或者要設計長時間維護的產(chǎn)品，還是建議做好代碼規(guī)范和設計模式的落地。

那么就不妨從筆者總結的痛點上，結合自己當下場景逐條分析，取得一個“「平衡」”點。

筆者也大致總結了幾點，以應對上面的措施，但每個人都有每個人的情況，和「設計模式」本身一樣，不能“生抄硬套”。

• 深入理解業(yè)務，「做好****業(yè)務預判」，這樣就為了底層設計打出良好基礎。

• 在保障人力成本的情況下，自驅性的成員在當今也不在少數(shù)，要給予信心一起「做好基礎建設」。

• 復雜的業(yè)務點頻繁迭代某個「早期時刻」，技術負責人需要切入，衡量工時分析業(yè)務，以便斷定是否需要重構，或者出代碼設計方案。

• 人員頻繁流動下，工作要盡量形成文檔，不能以“走形式”為主，不僅要良好交接代碼，還要良好交接業(yè)務。

• 傳統(tǒng)項目，對日項目要充分利用自動化工具，盡量多多代替人工的文檔維護。

當然了，本文提到的痛點，在中小公司最不難發(fā)現(xiàn)，更不是三言兩語就能解決，所以盡力做到平衡就非常好了。

如果不存在這些痛點，人員自驅性強，基礎建設良好等。大概率是足夠優(yōu)秀的企業(yè)了，如果你是這樣企業(yè)的員工，還堅持看到這里，那就當了解一下中小企業(yè)的小問題。

結尾

剛入行時，筆者也曾看著歷史代碼發(fā)出笑聲，“這么亂的代碼，怕是喝了散裝假酒”。

時過境遷，隨著工作年限的增長，看問題的角度也在不斷發(fā)生變化，現(xiàn)在不僅不會發(fā)出嘲笑了，還總結了亂代碼出現(xiàn)的原因。

關于「設計模式」和「代碼規(guī)范」方面的思考也有了新的理解，也如上文所說，碰巧與同事開會提到了，所以整理成文。

文章的標簽設置為閱讀下的“代碼規(guī)范”，因為本文沒有技術干貨，算是經(jīng)驗分享，希望對你有所幫助。、