代碼規(guī)范 設(shè)計(jì)模式落地之路

??Java大聯(lián)盟
? 致力于最高效的Java學(xué)習(xí)
關(guān)注




原文鏈接
https://juejin.cn/post/6844904142960328718


B 站搜索：楠哥教你學(xué)Java
獲取更多優(yōu)質(zhì)視頻教程

前言

關(guān)于設(shè)計(jì)模式和代碼規(guī)范問題還是有一些內(nèi)容還是值得落筆和大家分享的。

正文

設(shè)計(jì)模式究竟是什么？

主流的說法，大致如此：

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

最佳實(shí)踐一詞筆者再幾處介紹設(shè)計(jì)模式的地方，都有看到。但是設(shè)計(jì)模式真的就是OOP中，業(yè)務(wù)開發(fā)的最佳實(shí)踐嗎？

首先聲明筆者的觀點(diǎn)，我是如何理解設(shè)計(jì)模式的：

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

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

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

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

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

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

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

代碼規(guī)范性或使用設(shè)計(jì)模式的痛點(diǎn)

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

性能

在極端的考慮下，例如Java語言，設(shè)計(jì)模式面臨著更多的類文件以及更多的代碼。

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

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

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

類爆炸

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

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

設(shè)計(jì)缺陷和過度設(shè)計(jì)，兩者對開發(fā)人員都是一樣痛苦的，會(huì)出現(xiàn)“不該用設(shè)計(jì)模式而用”，或者單純?yōu)榱恕?strong style="outline: 0px;color: rgb(255, 53, 2);line-height: 1.5;">迎合缺陷的設(shè)計(jì)模式”，寫出對應(yīng)邏輯復(fù)雜的代碼，這樣類爆炸不可避免。

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

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

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

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

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

團(tuán)隊(duì)成員編碼水平

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

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

此處說句題外話，

而且很多初級(jí)工程師其實(shí)對框架很“有適應(yīng)性”的，當(dāng)然并非真正的適應(yīng)性。

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

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

這些不能算是初級(jí)工程師的問題，要?dú)w結(jié)于技術(shù)負(fù)責(zé)人，比如觀察到了項(xiàng)目中還沒有工具庫，那么是不是應(yīng)該先去公司內(nèi)部的二方庫中尋找，如果沒有是不是應(yīng)該引入commons-lang3，hutool，guava這類的第三方優(yōu)秀庫等等。

項(xiàng)目大環(huán)境

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

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

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

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

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

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

什么時(shí)點(diǎn)選擇使用設(shè)計(jì)模式優(yōu)化代碼，或者用不用優(yōu)化，以及有沒有時(shí)間優(yōu)化都是個(gè)問題。

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

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

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

這樣時(shí)間成本也成為了一個(gè)因素。

人員流動(dòng)

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

一方面是公司原因，隨著改革春風(fēng)吹滿地，已經(jīng)到了遍地“老板”的年代，一些公司，要求不合理，甚至條款都是違fa行為導(dǎo)致人才流失。二是個(gè)人原因，水平高為高薪所走，水平低被低薪勸退。

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

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

分析

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

上文列舉了一些，在項(xiàng)目開發(fā)中代碼規(guī)范，以及使用設(shè)計(jì)模式上的一些痛點(diǎn)。

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

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

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

如果我們是有geek精神的團(tuán)隊(duì)，或者要設(shè)計(jì)長時(shí)間維護(hù)的產(chǎn)品，還是建議做好代碼規(guī)范和設(shè)計(jì)模式的落地。

那么就不妨從筆者總結(jié)的痛點(diǎn)上，結(jié)合自己當(dāng)下場景逐條分析，取得一個(gè)“平衡”點(diǎn)。

筆者也大致總結(jié)了幾點(diǎn)，以應(yīng)對上面的措施，但每個(gè)人都有每個(gè)人的情況，和設(shè)計(jì)模式本身一樣，不能“生抄硬套”。

• 深入理解業(yè)務(wù)，做好業(yè)務(wù)預(yù)判，這樣就為了底層設(shè)計(jì)打出良好基礎(chǔ)。
• 在保障人力成本的情況下，自驅(qū)性的成員在當(dāng)今也不在少數(shù)，要給予信心一起做好基礎(chǔ)建設(shè)。
• 復(fù)雜的業(yè)務(wù)點(diǎn)頻繁迭代某個(gè)早期時(shí)刻，技術(shù)負(fù)責(zé)人需要切入，衡量工時(shí)分析業(yè)務(wù)，以便斷定是否需要重構(gòu)，或者出代碼設(shè)計(jì)方案。
• 人員頻繁流動(dòng)下，工作要盡量形成文檔，不能以“走形式”為主，不僅要良好交接代碼，還要良好交接業(yè)務(wù)。
• 傳統(tǒng)項(xiàng)目，對日項(xiàng)目要充分利用自動(dòng)化工具，盡量多多代替人工的文檔維護(hù)。

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

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

結(jié)尾

剛?cè)胄袝r(shí)，筆者也曾看著歷史代碼發(fā)出笑聲，“這么亂的代碼，怕是喝了散裝假酒”。

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