工作多年后,越發覺得代碼整潔真的是太重要了!尤其是在團隊開發中,寫出優雅工整的代碼,能讓同事更樂于跟你合作。
下面,將通過命名、類、函數、測試這四個章節,使我們的代碼變得整潔。
1.為什么要保持代碼整潔?
不整潔的代碼隨著時間的增加而增加時,生產力會隨之降低. 導致的結果就是:
代碼不易擴展或擴展容易引發其他問題
程序崩潰
加班
增加公司成本(加人) 甚至可能造成公司倒閉 一圖勝千言
1.1 所以從一開始就要保持整潔
所以在一開始就要寫整潔的代碼,如果有不整潔的代碼就要及時的整改. 絕對不要有以后再改,以后再說的想法, 因為!
laterequalnever
想想是不是這個道理,你有多少以后再說、以后再改的東西都拋諸腦后了.
如果是一定要做的事情,那就趁早做!
1.2 如何寫出整潔的代碼?
那么現在的問題就是,怎樣的代碼才算是整潔的代碼呢:
可讀性要高: 代碼要像散文一樣優雅易讀,見碼知意
拒絕重復代碼
滿足設計模式原則
單一職責
開閉原則
里氏替換原則
依賴倒轉原則
接口隔離原則
迪米特法則
合成復用法則
基于 Spring Boot + MyBatis Plus + Vue & Element 實現的后臺管理系統 + 用戶小程序,支持 RBAC 動態權限、多租戶、數據權限、工作流、三方登錄、支付、短信、商城等功能
2.命名
好的命名可提高代碼的可讀性,讓人見碼知意, 降低理解成本,提高效率, 減少加班.
2.1 不好的命名方式
沒有任何意義的命名方式
publicinterfaceAnimal{ voidabc(); }
現在我們有一個動物的接口, 里面有一個方法abc(),看了讓人一頭霧水, 調用這個方法的人也完全不知道這個方法是干什么的,因為他的命名毫無意義
有意義的命名方式:
publicinterfaceAnimal{ voidcry(); }
我們將方法名命名為cry(喊叫,呼喊),調用的人就知道這個方法的作用是什么了.
所以命名一定要有意義且讓人見碼知意.
命名前后不一致 這種情況體現在明明是同一行為,但是卻有不同的命名,前后不一致,讓人造成混淆.
publicinterfaceStudentRepositoryextendsJpaRepository{ StudentfindOneById( @Param("id")Stringid ); ListqueryAllStudent( ); } ,>
上面兩個方法都是查詢 xxx, 但是命名一會叫 query 一會叫 find,這種情況應該加以規范,保持一致, 修改后:
publicinterfaceStudentRepositoryextendsJpaRepository{ StudentfindOneById( @Param("id")Stringid ); ListfindAll( ); } ,>
命名冗余 體現在命名有很多沒必要的成分在里面, 并且這些"廢話"并不能幫助區分它們的區別, 例如在變量命名中添加了 Variable 這個詞, 在表名中添加了 Table 這個詞.所以命名中不要出現冗余的單詞 , 并且提前約定好命名的規范.
//獲取單個對象的方法用get做前綴 getXxx(); //獲取多個對象用list做前綴 listXxxx();
基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 實現的后臺管理系統 + 用戶小程序,支持 RBAC 動態權限、多租戶、數據權限、工作流、三方登錄、支付、短信、商城等功能
3.類
整潔的類應滿足一下內容:
單一職責
開閉原則
高內聚性
3.1單一職責
類應該短小,類或模塊應有且只有一條加以修改的理由 , 如果一個類過于龐大的話,那么說明它承擔的職責過多了.
優點:
降低類的復雜度
提高類的可讀性
提高系統的可維護性
降低變更引起的風險
如何判定類是否足夠短小?
通過計算類的職責來判斷是否夠短小,類的名稱描述其全責, 如果無法為某個類命以準確的名稱, 這個類大概就太長了, 類名越含糊,可能擁有越多的職責.
職責過多的例子,可以看到以下類有兩個職責:
publicabstractclassSql{ //操作SQL的職責 publicabstractvoidinsert(); //統計SQL操作的職責 publicabstractvoidcountInsert(); }
將統計的職責抽取到另一個類
publicabstractclassCountSql{ publicabstractvoidcountInsert(); }
3.2 開閉原則
開閉原則: 面向修改關閉, 面向擴展開放.
面向修改關閉意味著增加新的邏輯不會修改原有的代碼,降低了出錯的可能性.
面向擴展開放則是提高了代碼的可擴展性,可很容易的增加新的代碼邏輯.
不滿足開閉原則的例子:
publicabstractclassSql{ publicabstractvoidinsert(); publicabstractvoidupdate(); publicabstractvoiddelete(); }
如果我們現在要新增查詢的操作,就需要修改Sql這個類,沒有做到面向修改關閉
重構后:
publicabstractclassSql{ publicabstractvoidgenerate(); } publicclassCreateSqlextendsSql{ @java.lang.Override publicvoidgenerate(){ //省略實現 } } publicclassUpdateSqlextendsSql{ @Override publicvoidgenerate(){ //省略實現 } }
當我們要增加刪除方法時可以很容易的擴展.
使用大量的短小的類看似比使用少量龐大的類增加了工作量(增加了更多的類),但是真的是這樣嗎? 這里有一個很好的類比:
你是想把工具歸置到有許多抽屜、每個抽屜中裝有定義和標記良好的組件的工具箱呢, 還是想要少數幾個能隨便把所有東西扔進去的抽屜?
最終的結論:
系統應該由許多短小的類而不是少量巨大的類組成,每個小類封裝一個權責,只有一個修改的原因,并與少數其他類一起協同達成期望的系統行為.
3.3 內聚
方法操作的變量越多,就越粘聚到類上. 如果一個類中的每個變量都被每個方法所使用, 則該類具有最大的內聚性. 我們應該將類的內聚性保持在較高的位置. 內聚性高意味著方法和變量互相依賴, 互相結合成一個邏輯整體.
為什么要保持高內聚? 保持內聚性就會得到許多短小的類,就越滿足單一職責.
內聚性低怎么辦? 如果類的內聚性就不夠高,就將原有的類拆分為新的類和方法.
4.函數
要想讓函數變得整潔,應保證:
只做一件事
好的命名
整潔的參數
注意返回內容
4.1 只做一件事
what? 函數的第一規則是短小 第二規則是更短小 短小到只做一件事情. (沒錯和類的原則很像)
why? 函數越短小,越能滿足單一職責.
how? 以下是重構前的代碼, 這個方法有三個職責,并且該方法很長達到了80+50+5 = 135行
publicclassPicService{ publicStringupload(){ //校驗圖片的方法偽代碼80行 //壓縮圖片的方法偽代碼50行 //返回成功或失敗標識0,1偽代碼5行 return"0"; } }
原有的upload方法做了很多的事情, 重構后只做了一件事情: 把大一些的概念(換言之,函數的名稱)拆分為另一抽象層上的一系列步驟:
publicStringupload(){ //校驗圖片的方法 check(); //壓縮圖片的方法 compress(); //返回成功或失敗標識0,1 return"0"; }
而里面的每個方法,也都有著自己各自的職責(校驗圖片 、壓縮圖片 、返回結果).
4.2 函數命名
1. 函數名應見名知意
函數要有描述性的名稱,不要害怕長名稱.
不好的命名方式:
publicStringaddCharacter(StringoriginString,charch);
這個函數,一咋看,還不錯,從函數字面意思看是給某個字符串添加一個字符。但是到底是在原有字符串首部添加,還是在原有字符串末尾追加呢?亦或是在某個固定位置插入呢?從函數名字完全看不出來這個函數的真正意圖,只能繼續往下讀這個函數的具體實現才知道。
而下面這幾個名字就比上面要好得多:
//追加到末尾 publicStringappendCharacter(StringoriginString,charch); //插入指定位置 publicStringinsertCharacter(StringoriginString,charch,intinsertPosition);
2. 函數應該無副作用
函數應該無副作用, 意思就是函數應該只做一件事,但是做這件事的時候做了另一件有副作用的事情.
例如: 校驗密碼時會初始化 session,導致會話丟失。如果無法移除這種副作用,應該在方法名中展示出來,避免用戶誤用 checkPasswordasswordAndInitializeSession, 從命名上就要體現副作用.
4.3 參數
1. 參數越少越好
參數越少,越容易理解,參數超過三個可以將參數進行封裝,要按參數的語義進行封裝,不一定封裝成一個大而全的參數,可以封裝為多個,原則是按語義補充; 示例:
publicListfindStudent(intage,Stringname,Stringcountry,intgender); //封裝參數 publicListfindStudent(Studentstudent);
2. 不要使用標識參數
標識參數是參數為 Boolean 類型, 用戶傳遞 true or false . 不要使用標識參數因為這意味著你的函數違背了單一職責(true false 兩套邏輯). 正確的做法是拆分為兩個方法:
//標識參數方法 render(BooleanisSuite); //重構為兩個方法 reanderForSuite(); renderForSingleTest();
3. 不要使用輸出參數
什么是輸出參數?
將變量作為參數傳入方法,并且將變量輸出, 這就是輸出參數
publicvoidfindStudent(){ Studentstudent=newStudent(); doSomething(student); returnstudent; } intdoSomething(Studentstudent){ //省略一些student邏輯 returnstudent; }
為什么不應該有輸出參數?
因為增加了理解成本在里面,我們需要查看 doSomething到底對 student 做了什么. student 是輸入還是輸出參數? 都不明確.
重構:
//將doSomething()方法內聚到student對象本身 student.doSomething();
4.4 返回值
1. 分離指令與訊問
示例代碼:
PulicBooleanaddElement(Elementelement)
指令為增加某個元素,詢問是否成功,
這樣做的壞處是職責不單一,所以應該拆分為兩個方法
publicvoidaddElement(Elementelement); publicBooleanisAdd(Elementelement);
2. 使用異常替代返回錯誤碼
直接拋出異常,而不是返回錯誤碼進行判斷, 可以使代碼更簡潔. 因為使用錯誤碼有可能會進行多層嵌套片段 代碼示例:
//使用錯誤碼導致多層嵌套... publicclassDeviceController{ publicvoidsendShutDown(){ DeviceHandlehandle=getHandle(DEV1); //Checkthestateofthedevice if(handle!=DeviceHandle.INVALID){ //Savethedevicestatustotherecordfield retrieveDeviceRecord(handle); //Ifnatsuspended,shutdown if(record.getStatus()!=DEVICE_SUSPENDED){ pauseDevice(handle); clearDeviceWorkQueue(handle); closeDevice(handle); }else{ logger.log("Devicesuspended.Unabletoshutdown"); } }else{ logger.log("Invalidhandlefor:"+DEV1.tostring()); } }
重構后:
//將代碼拆分為一小段一小段,降低復雜度,更加清晰 publicclassDeviceController{ publicvoidsendShutDowm(){ try{ tryToShutDown(); }catch(DeviceShutDownErrore){ logger.log(e); } privatevoidtryToShutDown()throwsDeviceShutDownError{ DeviceHandlehandle=getHandle(DEV1); retrieveDeviceRecord(handle); pauseDevice(handle); clearDeviceWorkQueue(handle); closeDevice(handle); } privateDeviceHandlegetHandle(DeviceIDid){ //省略業務邏輯 thrownewDeviceShutDownError("Invalidhandlefor:"+id.tostring()); } }
4.5 怎樣寫出這樣的函數?
沒人能一開始就寫出完美的代碼, 先寫出滿足功能的代碼,之后緊接著進行重構
為什么是緊接著? 因為 later equal never!
4.6 代碼質量掃描工具
使用 SonarLint 可以幫助我們發現代碼的問題,并且還提供了相應的解決方案. 對于每一個問題,SonarLint 都給出了示例,還有相應的解決方案,教我們怎么修改,極大的方便了我們的開發
比如,對于日期類型盡量用 LocalDate、LocalTime、LocalDateTime,還有重復代碼、潛在的空指針異常、循環嵌套等等問題。
有了代碼規范與質量檢測工具以后,很多東西就可以量化了,比如 bug 率、代碼重復率等.
5.測試
測試很重要,可以幫助我們驗證寫的代碼是否沒問題,同樣的測試代碼也應該保持整潔.
5.1 TDD
TDD 是測試驅動開發(Test-Driven Development),是敏捷開發中的一項核心實踐和技術,也是一種設計方法論。
優點:在任意一個開發節點都可以拿出一個可以使用,含少量bug并具一定功能和能夠發布的產品。
缺點:增加代碼量。測試代碼是系統代碼的兩倍或更多,但是同時節省了調試程序及挑錯時間。
how?
在開發代碼前先寫測試
只可編寫剛好無法通過的單元測試,不能編譯也算不通過
開發代碼不可超過測試
關于2的解釋: 單測與生產代碼同步進行,寫到一個不可編譯的單測就開始寫生產代碼,如此反復循環,單測就能包含到所有生產代碼。
5.2 FIRST原則
FIRST 原則就是一個指導編寫單元測試的原則
fast 快速 單測執行應該快速的完成
independent 獨立 單測之間相互獨立
repeatable 可重復 單測不依賴于環境,隨處可運行
self validating 程序可通過輸出的Boolean自我驗證,而不需要通過人工的方式驗證(看日志輸出、對比兩個文件不同等)
timely 及時 單測在生產代碼之前編寫
單元測試是代碼測試中的基礎測試,FIRST 是寫好單元測試的重要原則,它要求我們的單元測試快速,獨立,可重復,自我校驗,及時/完整。
5.3 測試代碼模式
開發測試代碼可以使用 given-when-then 模式
given 制造模擬數據
when 執行測試代碼
then 驗證測試結果
代碼示例
/** *Ifanitemisloadedfromtherepository,thenameofthatitemshould *betransformedintouppercase. */ @Test publicvoidshouldReturnItemNameInUpperCase(){ //Given ItemmockedItem=newItem("it1","Item1","Thisisitem1",2000,true); when(itemRepository.findById("it1")).thenReturn(mockedItem); //When Stringresult=itemService.getItemNameUpperCase("it1"); //Then verify(itemRepository,times(1)).findById("it1"); assertThat(result,is("ITEM1")); }
使用give-when-then 模式可提高測試代碼的可讀性.
5.4 自動生成單測
介紹兩款 IDEA 自動生成單測的插件
Squaretest 插件(收費)
TestMe 插件(免費)
6.結束語
編寫整潔的代碼可以讓我們 提高代碼的可讀性,使代碼變得更易擴展。
審核編輯:劉清
-
SQL
+關注
關注
1文章
762瀏覽量
44117 -
FIRST
+關注
關注
0文章
11瀏覽量
11685 -
TDD
+關注
關注
1文章
121瀏覽量
38182 -
RBAC
+關注
關注
0文章
44瀏覽量
9964
原文標題:這樣寫代碼,同事樂開花
文章出處:【微信號:芋道源碼,微信公眾號:芋道源碼】歡迎添加關注!文章轉載請注明出處。
發布評論請先 登錄
相關推薦
評論