一個好的程序員肯定是要能書寫可維護的代碼，而不是一次性的代碼，怎么能讓團隊當中的其他人，甚至過一段時間之后的你，再看自己某個時期寫的代碼，依然能看懂?這就涉及到規(guī)范你的代碼了。

一、規(guī)范代碼的好處

1.從根本上降低開發(fā)成本：

提高代碼整體的可讀性、可維護性、可復用性。

2.保證代碼的一致性：

軟件系統中最重要的因素之一就是編碼的一致性。如果編碼風格一致，也更加易于維護，因為團隊內任何人都可以快速理解并修改。

3.提升團隊整體效率：

開發(fā)人員通常需要花費大量的時間來解決代碼質量問題，如果都按照規(guī)范編寫，也有助于團隊盡早發(fā)現問題，這將提高整個交付過程的效率。

二、不規(guī)范代碼的弊端

1.增加團隊成員間的協作負擔：

由于缺乏規(guī)范，導致代碼風格不一，極端情況下，某段代碼只有某個人能修改。

2.團隊間協作更加困難：

由于開發(fā)人員要適應不同的風格，會導致效率低下。

3.回顧困難：

在review期間，可能經常為類似的事情做過多的討論。

4.影響降低團隊整體效率：

影響團隊的生產力和質量，嚴重的甚至會影響團隊和諧。

三、為什么很多團隊缺乏規(guī)范

1.當開發(fā)人員被要求在短時間內完成任務時，通常會回避質量標準。

2.長時間養(yǎng)成的開發(fā)習慣很難在短時間內去改變。

3.有的時候雖然達成了一致，但在開發(fā)中依舊我行我素。

四、規(guī)范包含哪些內容

我們平時理解的前端開發(fā)規(guī)范，更多層面的是編碼層面的規(guī)范，實際上遠不止這一個。比如技術棧規(guī)范、瀏覽器兼容規(guī)范、項目文件結構規(guī)范、UI設計規(guī)范、前后端協作規(guī)范等，以下主要從這六個方面簡單介紹下前端開發(fā)規(guī)范。

1.技術棧規(guī)范

前端目前主要有三大框架Vue、React和AngularJS。每一個框架背后都是一個架構、一個生態(tài)。每個框架背后牽涉著開發(fā)思維、生態(tài)系統、配套工具、最佳實踐、性能調優(yōu)。要精通和熟練一個框架需要付出的成本是很高。

所以說團隊的開發(fā)效率是基于穩(wěn)定且熟練的技術棧的。穩(wěn)定的技術棧規(guī)范有利于團隊協作和溝通; 另外如果團隊精通這個技術棧，當出現問題或者需要深入調優(yōu), 會相對輕松。

前端技術棧規(guī)范主要包含下面這些類型:

① 編程語言 - Typescript或Javascript。

② UI框架及其配套生態(tài)(路由、狀態(tài)管理、組件庫、國際化、動畫、服務端渲染、腳手架、CLI工具、組件測試等)。

③ 樣式。命名規(guī)范、預處理器等。

④ 動畫引擎。

⑤ 項目構建工具流。webpack、vue-cli。

⑥ 包管理器。npm、yarn。

⑦ 開發(fā)工具、工具庫(moment.js)、版本管理(gitlab)等。

2.瀏覽器兼容規(guī)范

前端團隊應該根據應用所面對的用戶情況、應用類型、開發(fā)成本、瀏覽器市場統計數據等因素，來制定自己的瀏覽器兼容規(guī)范。不過確定哪種兼容策略，應該取決于用戶比重，如果大部分用戶使用的是現代瀏覽器，就應該使用優(yōu)雅降級，為現代瀏覽器提供最好的體驗，而舊瀏覽器則退而求之次，保證大概的功能，反之選擇漸進增強，保證低版本瀏覽器的體驗，對于支持新特性的新瀏覽器提供稍好的體驗。

有了瀏覽器兼容規(guī)范，前端開發(fā)和兼容性測試就有理有據，避免爭議; 同時它也是前端團隊的一種對外聲明，除非特殊要求，不符合瀏覽器兼容規(guī)范的瀏覽器，前端開發(fā)人員可以選擇忽略。

我們也可以根據瀏覽器市場分布情況、用戶占比、開發(fā)成本等因素對將瀏覽器劃分為多個等級，不同等級表示不同的支持程度：

① 完全兼容: 保證百分百功能正常。

② 部分兼容: 只能保證功能、樣式與需求大致一致。對于一些不影響主體需求和功能的bug，會做降低優(yōu)先級處理或者不處理。

③ 不兼容: 不考慮兼容性。

3.項目文件結構規(guī)范

主要包含項目的命名、項目的文件結構、版本號規(guī)范等。

下面簡單列舉一類項目文件結構：

① README.md: 項目說明。你可以在這里提供關于項目的關鍵信息或者相關信息的入口。一般包含下列信息:

• 簡要描述、項目主要特性;
• 運行環(huán)境/依賴、安裝和構建、測試指南;
• 簡單示例代碼;
• 文檔或文檔入口, 其他版本或相關資源入口;
• 聯系方式、討論群;
• 許可、貢獻/開發(fā)指南。

② CHANGELOG.md: 放置每個版本的變動內容, 通常要描述每個版本變更的內容。方便使用者確定應該使用哪個版本。

③ package.json: 前端項目必須. 描述當前的版本、可用的命令、包名、依賴、環(huán)境約束、項目配置等信息。

④ .gitignore: 忽略不必要的文件，避免將自動生成的文件提交到版本庫。

⑤ docs/: 項目的細化文檔, 可選。

⑥ examples/: 項目的示例代碼，可選。

⑦ build: 項目工具類腳本放置在這里，非必須。如果使用統一構建工具，則沒有這個目錄。

⑧ dist/: 項目構建結果輸出目錄。

⑨ src/: 源代碼目錄。

    - src 開發(fā)目錄
      - pages 視圖
          - module-a 模塊A
            - components 私有組件
              - ComA.tsx
              - ComB.tsx
            - index.module.less
            - index.tsx
            - Content.tsx
          - module-b 模塊B
      - components 公共組件
        - index.ts 導出所有組件
        - header
          - index.tsx
          - index.module.less
          - User.tsx
          - useGetBaseInfo.hooks.ts
      - routers 路由文件
      - store redux中的數據
      - utils 這里是以utils為后綴
        - index.ts
        - a.utils.ts
        - b.utils.ts
      - hooks 這里是以hooks為后綴
        - index.ts
        - a.hooks.ts
        - b.hooks.ts
      - styles 靜態(tài)資源文件
      - service api請求,這里是以api為后綴
        - a.api.ts 按照后端微服務進行劃分
        - b.api.ts
      - constans 常量

⑩ tests/: 單元測試目錄。

? tests: 全局的測試目錄，通常放應用的集成測試或E2E測試等。

? .env*: 項目中我們通常會使用環(huán)境變量來影響應用在不同運行環(huán)境下的行為。可以通過dotEnv來從文件中讀取環(huán)境變量. 通常有三個文件:

• env 通用的環(huán)境變量;
• env.development 開發(fā)環(huán)境的環(huán)境變量;
• env.production 生成環(huán)境的環(huán)境變量。

4.編碼規(guī)范

每一個程序員心目中對‘好代碼’都有自己的主見，統一的編碼規(guī)范可以避免不必要的論戰(zhàn)和爭議，有利于團隊項目的長遠維護。一致性的代碼規(guī)范可以增強團隊開發(fā)協作效率、提高代碼質量、減輕系統維護的負擔。

以下主要從HTML、JS、CSS、代碼格式化這四個方面談談編碼規(guī)范：

① HTML規(guī)范

使用 HTML5 的文檔聲明類型 :

DOCTYPE標簽是一種標準通用標記語言的文檔類型聲明，它的目的是要告訴標準通用標記語言解析器，它應該使用什么樣的文檔類型定義(DTD)來解析文檔。

使用文檔聲明類型的作用是為了防止開啟瀏覽器的怪異模式。

沒有DOCTYPE文檔類型聲明會開啟瀏覽器的怪異模式，瀏覽器會按照自己的解析方式渲染頁面，在不同的瀏覽器下面會有不同的樣式。

如果你的頁面添加了，那么就等同于開啟了標準模式。瀏覽器會按照W3C標準解析渲染頁面。

詳細規(guī)范可查看：https://codeguide.co/#html

② JS規(guī)范

函數變量命名、代碼注釋等。JS/TS主流的大致有這幾種:

• Airbnb JavaScript Style Guide：

??https://github.com/airbnb/javascript??

• Google JavaScript Style Guide：

??https://google.github.io/styleguide/jsguide.html]??

• Idiomatic JavaScript Style Guide：

??https://github.com/rwaldron/idiomatic.js??

• JavaScript Standard Style Guide

③ CSS規(guī)范

ID和class的命名、合理使用ID、css選擇器中避免使用標簽名、使用子選擇器、盡量使用縮寫屬性等，詳細可參考以下網站：

• Airbnb CSS / Sass Styleguide：

??https://css-tricks.com/bem-101/??

• Code Guide：

??https://codeguide.co/#css??

④ 代碼格式化規(guī)范

由于每個開發(fā)者的IDE不同，即使IDE相同也會因為每個人的配置不一樣導致格式化的結果不一樣。如何確保團隊內開發(fā)人員采用統一的格式化配置呢?

這里給推薦大家使用 prettier，它內置了一套格式化的規(guī)則。細可參考以下網站：https://prettier.io/

5.UI設計規(guī)范

UI 規(guī)范的最大好處就是能夠提質提效：

① 在開發(fā)者的角度，與設計規(guī)范同步形成研發(fā)資產，避免重復造輪子;

② 在測試的角度，能夠避免重復的無意義走查;

③ 在UI設計師的角度，減少設計成本，提高設計效率，可以快速承接新需求;

④ 在產品角度，提高產品迭代與優(yōu)化效率，降低試錯成本;

⑤ 在用戶角度，解決用戶體驗一致性。

如果團隊不打算制定自己的UI設計規(guī)范，則推薦使用現成的開源組件庫：Ant Design、Element UI、iView、WeUI等

6.前后端協作規(guī)范

前端往往不能脫離后端而存在，和后端協作的時間也是比較長的。

一個常用的前后端協作流程：

① 需求分析。參與者一般有前后端、測試、以及產品。由產品主持，對需求進行講解，接受開發(fā)和測試的反饋，確保大家對需求有一致的認知。

② 前后端開發(fā)討論。討論應用的一些開發(fā)設計，溝通技術點、難點、以及分工問題。

③ 設計接口文檔。可以由前后端一起設計;或者由后端設計、前端確認是否符合要求。

④ 并行開發(fā)。前后端并行開發(fā)，在這個階段，前端可以先實現靜態(tài)頁面; 或者根據接口文檔對接口進行Mock, 來模擬對接后端接口。

⑤ 前后端進行接口聯調。

五、前端開發(fā)規(guī)范實例

1.項目情況

多人開發(fā)同一個項目的不同模塊;由于開發(fā)前沒有制定規(guī)范，導致每個人的代碼都是一種單獨的風格;當其他人去修改代碼時需要熟悉不同風格的代碼，浪費了大量時間在閱讀代碼上;而且由于沒有全局的樣式規(guī)范，導致每個人都有一套自己的樣式，在后期如果想要做統一的界面風格時需要每個人都去修改樣式代碼，增加了大量工作量。

2.制定規(guī)范

根據項目的實際情況，由于項目已經開發(fā)到一定程度，已經選好了開發(fā)框架，所以可以從編碼和UI設計等方面進行規(guī)范。

由于項目是一個管理系統，所以對于前端UI來說可以統一頁面結構;制定一個統一風格的模板，開發(fā)的時候可以直接使用模板代碼去做適應性的修改;

由于缺乏統一的樣式標準，導致后期統一風格時會花費大量時間，所以進行統一的樣式分離，抽離公共的CSS樣式去引用，方便后期統一修改;

由于一些變量和函數命名過于簡單比如a、b、c等，規(guī)范多使用一些語義化的單詞去命名，方便理解和閱讀;

由于項目開發(fā)中前后端是同一個人開發(fā)，導致有些可能是后端的工作放到了前端去處理。比如分頁功能，雖然這個是前后端都可以做的，但是如果使用前端去分頁，這樣就要需要一次性返回全部數據，數據量大的時候接口可能會返回很慢，導致頁面空白時間比較長，所以建議有些邏輯功能要根據實際情況去決定是前端還是后端處理。

3.最終成果

項目代碼結構基本上有一個統一的風格;各模塊頁面也有了統一的風格;用戶體驗較好;也方便了開發(fā)和維護。

總結：

一個人走得更快，一群人可以走得更遠。統一規(guī)范的最根本目的是為了保證團隊成員的一致性，從而減少溝通成本，提高開發(fā)效率。學會熱愛標準，但要確保它們不是一成不變的。如果制定的規(guī)范不適合您的團隊，請確保可以適應和重寫所需要的任何規(guī)則。它并不是要強制執(zhí)行一種工作方式，而是為了幫助促進團隊之間的互動。