# 前端進階--1.爲何要制定開發規範？

0 爲何要有規範？

• 與性能無關
• 與功能無關
• 與效果無關
• 與能力無關
• 與工期無關

可是，規範必不可少

• 與效率相關（開發、迭代和維護，重點提高維護及迭代效率）
• 與團隊相關（減小團隊之間的不一致性）
• 與面試相關（提升代碼健壯性，經過面試）
• 與習慣相關（保證最近實踐）
• 與開源相關（開源項目均有嚴格的開發規範）

1 效率

• 代碼風格（eslint）
• 書寫規範（eslint）

1.1 易讀

1.1.1 空格（英文、數字與中文結合）

// 不理想

<p>AlexShan畢業於2008年</p>
複製代碼

// 理想

<p>AlexShan 畢業於 2008 年</p>
複製代碼

數字、英文與中文直接左右應該留有 1 個空格

1.1.2. 習慣

• 佈局 // 很差的佈局風格，用行內元素包裹塊級元素（新的 ESlint 規則默認禁止如此佈局）

<span>
  <div>
    <p><div class='strong'>很差</div>的佈局風格</p>
  </div>
</span>
複製代碼

// 較好的佈局

<div>
  <p><strong class="strong">較好</strong>佈局風格</p>
</div>
複製代碼

咱們應該合理選擇和使用html中的DOM元素進行頁面佈局

• 換行 // 無換行

<div v-vstop class="moreData" @mouseenter="showWin(index,'showindex')" @mouseleave="showindex=-1" >
  <i class="icon iconfont icon-showdown" :class="{'icon-showup':showindex==index}" ></i>
  <i class="icon iconfont icon-left-arrow" v-show="showindex==index"></i>
  <div class="mpanel" v-show="showindex==index">
    <div v-for="(logo,index) in productIds" @click="goProDetail(logo.id)" :title="logo.name" ></div>
  </div>
</div>
複製代碼

// 換行

<div v-vstop class="moreData" @mouseenter="showWin(index,'showindex')" @mouseleave="showindex=-1" >
  <i class="icon iconfont icon-left-arrow" v-show="showindex==index"> </i>
  <div v-for="(logo,index) in productIds" @click="goProDetail(logo.id)" :title="logo.name" ></div>
</div>
複製代碼

咱們應儘可能保證代碼清晰，按結構佈局，若是代碼密密麻麻，估計review的時候就會被打回來。而且嚴重影響閱讀速度。

1.1.3. 命名

變量	對象、類	常量	函數	布爾值	私有屬性
小駝峯	大駝峯	大寫	小駝峯	小駝峯	小駝峯
區分單複數	單數		動詞開頭	is has can 確定	_ 下劃線開頭
myName='' colleagues=['', ''] names =[]	class DogHouse	MAX_WIDTH	createUser deleteUser	available hasUser showName	_sum()
避免無心義變量名	避免衝突	全局存儲	多用確定詞	不對外暴露

1.2 精簡

應該儘量讓代碼精簡，越少的代碼犯錯的機率越低。維護和迭代成本也越低。

函數應該保持單一功能原則，避免大而全的函數。哪怕一個函數只有 1 行代碼，也應該成爲一個獨立的函數。

2 團隊

團隊協做是稍具規模公司必不可少的問題，也是項目開發進度保證的重要基石。只有團隊協做，各自的功力發揮到極致，才能保證團隊生產力最大化。

我曾經遇到過一個團隊，各自爲營，都按照本身想法和風格寫代碼，對代碼風格也沒有統一，關鍵是並不是每一個人都是大佬，寫出的代碼仍然具備很是多的問題，也麼有嚴格按照最近實踐進行編寫，個人編譯器紅彤彤一片。

這個是線上環境的真實代碼，問題很是多。

1. 無用代碼未及時去除
2. 未遵循Vue.js最佳實踐進行開發vuejs.org/v2/style-gu…
3. 使用行內樣式

咱們不總結更多的存在的問題，可想而已，多人一塊兒去維護這樣一套代碼，後期問題將很是多，很是有必要制定統一的規範。至少保證你們代碼風格相同，不然提交代碼時因格式問題也會引起大量衝突。解決衝突可不是我喜歡的事情。

3 面試

面試這個環節是每一個開發人員都必不可少的經歷，若是想進大廠，或者拿到好的薪酬。就必須經過面試，咱們做爲老司機，必須讓本身的代碼足夠健壯，書寫足夠規範，邊界條件的處理，哪怕很簡單的面試題，也是可以看出一我的的編碼能力的。

4 習慣

有人可能在偷樂，公司無規範，編碼無人管，本身說了算。想怎麼寫就怎麼寫，若是你想本身一直是個碼農，或者放棄本身進入大廠或者成爲大牛的機會。那天然能夠瀟灑走下去。若是但願本身可以快速成長，何不作個領導者，領導本身，給本身給公司制定一個規範，也會讓領導另眼相看。我想，好的領導，應該沒有不喜歡有規範、有約束的代碼風格吧？

5 開源

想成爲開源的貢獻者、或者參與開源項目，咱們就必須遵照開源項目的規範。像Angular，連提交代碼的格式和書寫都有嚴格的要求，而且開發了本身的代碼提交命令行工具。有興趣的同窗能夠深刻了解。 使用Commitizen代替 git commit 可使用cz-cli工具代替 git commit

結語

咱們應該根據公司狀況、業務場景和團隊具體狀況來制定適合本身的開發規範，開發規範不須要最好，也沒有最好的開發規範，只有適合本身的。例如谷歌的開發規範未必適合小的、須要快速迭代的實驗性項目。

後期我將和你們分享如何制定開發規範。