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

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

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

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

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

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

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

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

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

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

二、規範的制定

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

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

三、review機制的落實

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

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

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