怎麼去約束程式碼的統一性

語言: CN / TW / HK

Hello,各位鐵鐵,今天聊一聊怎麼去約束程式碼的統一性。

當你著手的專案隨著協同人員的越來越多,始終會面臨著一個問題,那就是程式碼的統一性,俗話說,千人千面,放在程式碼裡,也是百家爭鳴,畢竟每個人都有自己的思想,也有著自己書寫程式碼的風格,如何讓一個專案,朝著一個統一的風格前去,這個是很難的,難的不是規範的制定,而是規範的落實。

為什麼要進行統一?談到這個問題,想必各位鐵鐵,是最有發言權的,雖然說不統一,也能夠讓專案正常的執行,正常的上線,但隨著而來的問題也會不斷的暴露出來,比如,程式碼冗餘,冗餘到一個專案可能會有N個網路請求,N個同樣功能的工具類,N個同樣程式碼的方法等等,再比如說程式碼規範,以多個命名方式的存在,可能是下劃線,也可能是駝峰,以及出現多個技術選型的問題,你用A技術,他用B技術,等等類似的問題,造成專案的體積越來越大,後續接手人員越來越難以入手,長此以往,專案的穩定性將大大的折扣。

程式碼的統一性,在專案的啟動之初,就應該有一套屬於的自己的技術架構以及技術選型,必須有一個主導人員的參與,前期可以大家一起商討落實的方案,比如,技術選型,程式碼規範等等,所有的前期制定完之後,形成文件,這個是很重要的,不僅僅是針對當下的開發人員,更是為日後其他人更好的接手,形成一個有效的參考。程式碼的統一性,雖然一定程度上約束了開發人員的拓展思維,但在專案的穩定,可持續發展上,有著一定的作用,畢竟作為開發人員的我們,專案的穩定與否,直接關係自己的生存與否,鐵鐵們,這絕對不是危言聳聽,想想看,一個隨時崩潰的專案,你覺得你的處境會如何?

約束程式碼的統一性,無論從零開始的專案,還是已經開發中的專案,都是有必要進行實施的,簡單羅列下幾點。

一、架構的統一,技術選型的統一,各基礎庫的統一

架構,技術選型,基礎庫,基本上形成了一個專案的基石,在開發之初,就應該有足夠的時間進行整理開發,俗話說,磨刀不誤砍柴工,這些基礎的前提,很有必要來細心的整理。一個專案一個架構,這個必須是前提,如果說,出現了多個架構,那麼這個專案維護的成本將增加幾倍,後續接入的人也耗時耗力。技術選型的統一,像網路請求,資料儲存,圖片載入等,一個專案保持一種模式存在即可,多種方式,勢必造成程式碼上的冗餘,後續人員的接入成本的增加。基礎庫的統一,比如專案中常用的工具類,Dialog,Banner等等,進行統一的抽取,統一的使用,避免出現多種情況的存在,和技術選型基本是一致的。

所有的進行統一之後,務必有一份文件存在,架構,各個技術點的使用,基礎庫的呼叫等等,儘量涵蓋周全,畢竟大部分情況下這不是一個人單獨開發,而是多個人協同開發,以及後續也會有人蔘與進來,相對於這一套架構,技術選型,基礎庫等,肯定有不明白,不清晰的地方,如果有一份周全的文件,那麼熟悉起來就比較快了,而且可以快速的進入到開發狀態,大大的提高開發效率。

下圖是去年我根據現有的架構,技術選型,基礎庫等,書寫的一份文件。

image.png

二、規範的制定

有了基礎的架構,技術選型,基礎庫之後,也形成了一定的文件,那麼進入到開發中,規範是一定要重視的,比如程式碼的規範,git分支管理以及提交的規範,三方依賴的規範等等,務必要堅定的執行,無規矩不成方圓,只有規範的落地,才能保證專案的統一,程式碼的整潔,專案的穩定與健壯。

同樣的,根據以上的這些,也必須有文件的產出,口頭宣講很難達成記憶,只有文件的依據,才能不斷的加深印象,文件也儘量,細緻周全,涵蓋面要廣,規範的制定中,肯定會有遺漏,後期維護中可以不斷的進行健全。

三、review機制的落實

開頭就說過,規範制定特別容易,但是執行起來巨困難,畢竟協同開發的人員很多,每個人都有自己的思想,開發過程中,難免會出現很多不同的聲音,各種錯綜複雜的程式碼場景,所以,必須要建立一套review機制,以每次提交還是以日單位,看自己實際情況,來不間斷的針對程式碼進行review,發現一處,指正一處,只有這樣,才能長此以往的讓程式碼保持統一性,按照既定的規則去執行。

review這個是很有必要的,現有的規範下,你永遠發現不了別人是如何騷操作的,簡單舉個例子,例如下圖,是我之前review查出的某個問題,這些問題真的匪夷所思,鐵鐵們,你能察覺什麼問題嗎?

image.png

其實說到底,怎麼去約束程式碼的統一性,一句話,重在執行與檢查。