# 前端进阶--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

结语

咱们应该根据公司状况、业务场景和团队具体状况来制定适合本身的开发规范，开发规范不须要最好，也没有最好的开发规范，只有适合本身的。例如谷歌的开发规范未必适合小的、须要快速迭代的实验性项目。

后期我将和你们分享如何制定开发规范。