非大厂的我们，如何去卷一套标准的前端团队规范？

作者：易师傅 、github

声明：文章为稀土AdminJS技术社区首发签约文章，14天内禁止转载，14天后未获授权禁止转载，侵权必究！

前言

大家好，我是易师傅，一个专门搞前端的搬砖师傅 ~

在上一篇文章《非大厂的我们，要如何去搞基建》中主要带领了大家入门了 如何搞基建，以及基建都有什么；

写文章就要踏踏实实，正所谓：大饼画的再多，吃不到也是白瞎，下面正式开始我们的规范篇 ~

一、场景重现

如果 Leader 在某次 Code Review 时，发现你的代码是如下这样子的；

问：如果 Leader 让你优化，你会如何优化呢？

- 你是选择无视他（Leader），还是无视它（Code）？

// 点击定位按钮，获取县市地址方法
const clickDw = function(type) {
    let dz
    // 地址列表
    let dzTable = ['北京市'，'上海市', '广州市', '深圳市']

    if(type === 1 || type === 2 || type === 3) {
	// do something
	return dz
    } else if (type === 4 || type === 5) {
	// do something
	return dz
    } else {
	// default
	return dz
    }
}

咱们可以从这几方面入手：

1. 命名是否规范？

   • 方法名 clickDw 可否用 getLocation 代替？
   • 变量名 dz 可否变成 address？
   • 地址列表可否用 addressList 代替？

2. if 判断是否可以简化？

   • if(type === 1 || type === 2 || type === 3) 可以用 [1, 2, 3].includes(type) 代替吗？

3. 亦或还有其它优化空间？

   • 是否需要 else if ?

4. 大家觉得还有其它优化空间吗？

   • 欢迎讨论

二、团队存在的问题

我相信许多中小型公司都会面临下面几个问题：

1. 老旧业务代码的技术负债：

• 由于历史原因，仍旧还有一些老业务在旧项目中运行（想改又不敢改）；
• 所以这种技术负债就必不可少了，例如同个页面多个 jQuery 版本，多个不同的 UI 组件库，代码 n 种格式化等等的问题；

2. 要研发进度，不要研发质量：

• 在需求进度的催促下，许多同学的代码逻辑以及代码质量可以说是一塌糊涂了；
• 这时候在进度与质量中到底如何取舍就耐人寻味了 ~

3. 无 GitFlow 协同工作流：

• Git 的使用仍旧停留在 commit、pull、push 等简单使用中；
• 或者还在用 SVN；

4. 团队更迭文档负债：

• 存在最大的问题就是对一些老旧业务的不熟悉；因为人员的更迭，许多业务产品无记录、代码无注释，导致许多业务逻辑只能靠猜，极大的降低了团队的研发效率；

5. 后端接口文档的缺失：

• 接口文档有多重要，就不需要我说了吧，在座的每个前端大佬们应该深有体会；

6. 沟通少，导致效率低

• 可以少沟通，但是聊天工具永远无法比当面沟通有效率 ~

7. 研发与产品的爱恨情仇：

• 上联：兵熊熊一个
• 下联：将熊熊一窝
• 横批：懂的都懂 ~

正是由于这些问题的存在，从而 影响到团队之间的协作，使团队的效率整体降低，严重的甚至会影响团队和谐；

可想而知 牵一发而动全身 究竟有多大力量了吧！

其实作为一名 “优秀” 的程序员，写的代码无论是可读性、可维护性 还是可复用性 都是必不可少的；

那么如何去写 可读性、可维护性、可复用性 的代码呢？

就值得我们每个人深思熟虑了；

接下来我们带着疑问一起进入规范的世界！

三、规范的定义

规范包含的内容有许多，不同公司在针对现有团队所做的规范标准或许会有出入；

但无论是技术栈的统一，还是代码质量的把控，还是 Git 的钩子函数，亦或者团队文档的输出等等，其实都可以归纳至规范的范畴；

所以咱们可以这么定义（仅限笔者理解）：

在日常开发中，任何能 提高代码可维护性、降低代码理解成本、提高代码的容错率 和 提高项目可扩展性 的统一标准，称之为 规范标准；

四、规范的好处

1. 代码的一致性

2. 降低开发成本

3. 提升团队效率

4. 减少沟通成本

5. 有助于自身成长

6. 提高团队和谐（Code Review）

笔者个人见解：养成编写代码规范的习惯，有助于程序员自身的成长；

五、前端规范都有什么？

因为文章主要讲的是与前端相关，所以下面所述主要是前端相关的主题；

关于前端规范，我大致划分出了下列的内容，具体实施还需以自身公司实际情况为准；

下面让我们一起去看看吧！

1. 前端命名规范

命名 有多重要，我相信每位工程师都能明白其中的重要程度；

一个不好的命名，可能就会引起别人的错误理解；

遵循一套严格的命名规范，无论是对自己还是接手的他人，都会大大降低代码的维护成本，所以想要成为一名合格的前端开发，命名规范是必须的；

一些常见的不规范命名：

• 单词拼写错误：到底是 form 还是 from ？
• 中英文混用：到底用 dzTable 还是 addressList 呢？
• 以 1-9，a-z 命名：不同类型直接用 type1、type2、type3？
• 混用命名格式：一会 addressList 一会 addresslist 一会 addresses，这样不太好吧？
• 单复数不分: 到底 address 还是 addresses 啊？到底是 photoes 还是 photos 啊？
• 正反义词错用：到底用 showDialog 还是 isDialog 还是 visibleDialog 啊啊啊啊？

一些常见好的命名：

1. 驼峰式命名法介绍：

   • Pascal Case 大驼峰式命名法：首字母大写；

     • eg：StudentInfo、UserInfo、ProductInfoCamel

   • Case 小驼峰式命名法：首字母小写；

     • eg：studentInfo、userInfo、productInfo

2. 文件资源命名：

   • 文件名不得含有空格；

   • 文件名建议只使用小写字母，不使用大写字母；

   • 名称较长时采用半角连接符(-)分隔；

       usr/dev/document/front-end/project-vue3
   

3. 变量命名：

   • 命名方式 : 采用小驼峰式命名方法；

   • 命名规范 :

     • 普通变量(number, string, date)；
     • 布尔类型：需要一个标识变量含义的前缀，比如has, is, wether, can, should等；
     • 数组/集合等复数形式：最好以s或list等能够标识复数形式的后缀结尾，标识当前变量是复数形式，提高可读性；

   • 常量全部大写，且用下划线来分割单词，eg：MAX_LENGTH = 1

4. 函数：

   • 命名方式 : 小驼峰方式 lowerCamelCase ( 构造函数使用大驼峰命名法 )
   • 命名规则 : 前缀为动词，动词 eg：add / update / delete / detail / get

   // 更新数据
   function updateData(){
       return {};
   }
   
   // 获取用户信息
   function getUserInfo{
       return {}
   }
   

5. css 命名：

   • 样式类名使用小写字母，以半角连接符(-)分割；
   • id 采用驼峰式命名；
   • scss / less 中的变量、函数、混合、placeholder 采用驼峰式命名

   .heavy {
     font-weight: 800;
   }
   .important { 
     color: red; 
   }
   

2. 技术栈规范

问答题，请选出下列合适的答案：

• 到底是用 TypeScript 还是 JavaScript ？

• 到底是用 Vue 还是 React ？

• 到底是用 Less 还是 Sass ？

• 到底是用 Webpack 还是 Vite ？

• 到底是用 Koa 还是 Express ?

• ……

我相信不同的人肯定都有不同的答案，因为在不同的公司技术栈肯定是不一致的，技术栈不仅取决于领导的拍案叫板，也取决于业务的支持，所以会出现同一个业务部门会有不同的技术栈的情况；

我司选择答案：

1. 为什么用 TypeScript 而不用 JavaScript 呢？

   • 静态类型语言要较于动态类型语言更安全；
   • TypeScript 代码更可靠且更易于重构；
   • TypeScript 更明确类型；

2. 为什么用 Vue 而不用 React ？

   • 这是一个容易引战的话题；
   • 所以我们的答案是：领导让用

3. 为什么用 Sass 而不是 Less ？

   • Sass 功能齐全；
   • 不仅有变量和作用域，还有函数和进程控制的概念；
   • 更像一门正规的编程语言；

4. 为什么用 Vite 而不是 Webpack？

   • 开发效率极高 ——