讲讲团队工程化内的规范化

最近碰到很多很多及其不规范的代码，看的简直会爆炸，重复代码、疯狂ifelse语句、逻辑语句不做模块，文件乱扔不整理类别等等，那么这篇文章我就去讲一些，怎么去注意或者实现我们的前端团队的规范化呢？
点击进入 自建博客原文链接

先来看图：




看完图片了，我们先平复下心情！！！
好，现在继续说文章吧。

一、案例

在某次 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
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

我认为是不是可以从这几方面入手：

1.命名是否规范？

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

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

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

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

• 是否需要 else if ?

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

// 我修复了一下，嘿嘿
// 点击定位按钮，获取县市地址方法
const getLocation = function(type) {
    let address
    // 地址列表
    let addressList = ['北京市'，'上海市', '广州市', '深圳市']
    if([1, 2, 3].includes(type)) {
	  // do something
	  return address
    }
    if ([4, 5].includes(type)) {
	  // do something
	  return address
    }
    // default
    return address
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

二、团队或本身的问题

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

1. 老旧业务代码的技术负债：
   由于历史原因，仍旧还有一些老业务在旧项目中运行（想改又不敢改）；或者上一份同事写的垃圾代码留下的巨坑（图二就是我接手辞职同事留下的坑 ifelse300行，完全没有写枚举和模块化业务的思想）
   所以这种技术负债就必不可少了，例如同个页面多个 jQuery 版本，多个不同的 UI 组件库，代码 n 种格式化，风格思想异同等等的问题；
2. 要研发进度，不要研发质量：
   在需求进度和黑心老板的催促下，许多同学的代码逻辑以及代码质量可以说是一塌糊涂了；
   这时候在进度与质量中到底如何取舍就耐人寻味了 ~
3. 无 GitFlow 协同工作流：
   Git 的使用仍旧停留在 commit、pull、push 等简单使用中；
   或者还在用 SVN；
4. 团队更迭文档负债：
   存在最大的问题就是对一些老旧业务的不熟悉；因为人员的更迭，许多业务产品无记录、代码无注释，导致许多业务逻辑只能靠猜，极大的降低了团队的研发效率；
5. 后端接口文档的缺失：
   接口文档有多重要，就不需要我说了吧，在座的各位前端大佬们应该深有体会；
6. 沟通少，导致效率：
   可以少沟通，但是聊天工具永远无法比当面沟通有效率 ~
7. 研发与产品的爱恨情仇：
   这个不好描述，在某些公司产品和研发简直是天敌(ノ°ο°)ノ。

正是由于这些问题的存在，从而 影响到团队之间的协作，使团队的效率整体降低，严重的甚至会影响团队和谐；
可想而知 牵一发而动全身 究竟有多大力量了吧！
其实作为一名 “优秀” 的程序员，写的代码无论是可读性、可维护性 还是可复用性 都是必不可少的；
那么如何去写 可读性、可维护性、可复用性 的代码呢？
就值得我们每个人深思熟虑了；

三、规范？？？

规范包含的内容有许多，不同公司在针对现有团队所做的规范标准或许会有出入；
但无论是技术栈的统一，还是代码质量的把控，还是 Git 的钩子函数，亦或者团队文档的输出等等，其实都可以归纳至规范的范畴；
所以咱们可以这么定义（仅限博主的理解）：
在日常开发中，任何能 提高代码可维护性、降低代码理解成本、降低代码的容错率 和 提高项目可扩展性 的统一标准，称之为 规范标准；

四、规范的好处？？？

1. 代码的一致性
2. 降低开发成本
3. 提升团队效率
4. 减少沟通成本
5. 有助于自身成长
6. 提高团队和谐（Code Review）
   笔者个人见解：养成编写代码规范的习惯，有助于程序员自身的成长；

五、前端规范？？？

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

前端命名规范

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

一些常见的不规范命名：

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

一些常见好的命名：

1.驼峰式命名法介绍：

• eg：studentInfo、userInfo、productInfo
• eg：StudentInfo、UserInfo、ProductInfoCamel
• Pascal Case 大驼峰式命名法：首字母大写；
• Case 小驼峰式命名法：首字母小写；

2.文件资源命名：

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

• 文件名不得含有空格；
• 文件名建议只使用小写字母，不使用大写字母；
• 名称较长时采用半角连接符(-)分隔；

3.变量命名：

• 普通变量(number, string, date)；
• 布尔类型：需要一个标识变量含义的前缀，比如has, is, wether, can, should等；
• 数组/集合等复数形式：最好以s或list等能够标识复数形式的后缀结尾，标识当前变量是复数形式，提高可读性；
• 命名方式 : 采用小驼峰式命名方法；
• 命名规范 :
• 常量全部大写，且用下划线来分割单词，eg：MAX_LENGTH = 1

4.函数：

// 更新用户信息
function updateUserInfo(){
    return {};
}
// 获取用户信息
function getUserInfo{
    return {};
}
1
2
3
4
5
6
7
8

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

5.css 命名：

.super-card {
  font-weight: 600;
}
1
2
3

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

文件规范

我们在创建vue项目的时候，脚手架会自动帮我们生成几个文件，比如说pages,assets等等，我们也会去创建一些比如util, components,api等。我最近接手的代码，订单模块在ui/mine/order内，但是这个order文件夹内有30多个.dart文件，里面还有一个文件夹view用来放置组件，我惊呆了。其实可以针对业务拆分成 order/list , order/search, order/detail, order/refund，再对各自的细分模块内建对应的数据模型和组件文件夹，所以，当业务扩充起来的时候，文件规范还是有必要的。就算不扩充，文件规范也要做起来。

技术栈规范

请选出下列合适的答案：
到底是用 TypeScript 还是 JavaScript ？
到底是用 Vue 还是 React ？
到底是用 Less 还是 Sass ？
到底是用 Webpack 还是 Vite ？
到底是用 Koa 还是 Express ?
do some…
其实我相信不同的人肯定都有不同的答案，因为在不同的公司技术栈肯定是不一致的，技术栈不仅取决于领导的拍案叫板，也取决于业务的支持，所以会出现同一个业务部门会有不同的技术栈的情况；

我们公司选择的答案：
为什么用 TypeScript 而不用 JavaScript 呢？

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

为什么用 Vue而不用 React ？

• 这是一个容易引战的话题；
• 所以我的答案是：领导决定的
• 我擅长vue，其实更倾向于react，因为react团队大哈哈(▽)q

为什么用 Sass 而不是 Less ？
Sass 功能齐全；

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

为什么用 Webpack 而不是 Vite？

• 团队数量webpack的更多
• 在谷歌上 问题的解决方案会更多
• 社区成熟

TIPS：使用新技术前要考量其学习成本、带来的收益以及存在的风险等等，切勿盲目追行情。就比如说最近又出了一个Turbopack，比vite快10倍，不是不想用，是技术迭代太快了吧，根本学不过来！！！！

编程规范

为什么需要编程规范？
实际开发中因为没有规范而导致的问题真的不要太多太多；有因为 JavaScript 不规范的，也有因为 CSS 不规范的；
但是我们究其原因，无非就是没有一个所谓的统一标准而导致；
正所谓：无规矩不成方圆，有了规范才有好的团队~
编程规范的意义：

• 统一团队的编码规范，有助于代码的维护；
• 提升编码效率；
• 减少沟通成本；
• 提升团队气氛；
• 有利于 Code Review；

Git 规范

为什么要 Git 规范？

• 方便跟踪工程历史；
• 方便快速回溯代码；
• 方便 Code Review；
• 方便生成 CHANGELOG；
• 提高项目的整体质量，提高个人工程素质；

如何去做 Git 规范？

Git Commit 规范

// 这事我本人一直在用的规范
feat：新功能 feature
bug：测试反馈 bug 列表中的 bug 号
fix： 修复 bug
ui：更新UI；
docs： 文档注释变更
style： 代码格式(不影响代码运行的变动)；
refactor： 重构、优化(既不增加新功能，也不是修复bug)；
perf： 性能优化；
release：发布；
deploy：部署；
test： 增加测试
chore： 构建过程或辅助工具的变动
revert： 回退
build： 打包
scope 表示 commit 的作用范围，如用户中心、购物车中心，也可以是目录名称，一般可以限定几种；
subject 用于对 commit 进行简短的描述；
type 必填，表示提交类型，值一般有以下几种：

//如 [feat]增加用户中心的 xx 功能
//如 [fix]增加用户二维码的 xx 功能
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

统一格式：

• 结合工具强制使用 Git Commit 规范：
• 使用 commitlint 、commitizen 和 husky 来进行提交检查；
• 使用 commitlint-config-cz 规范命令行提示消息（可选）；
• 使用 conventional-changelog 提交日志

其实还有很多 比如

• 前后端协作规范，版号，接口定义，接口注释，入参描述，状态码定义，RESTful 架构，数据类型，空值，是true false 还是0 1等等
• UI规范，设计风格统一吗，组件复用率高吗，图标怎么搞，图片几x，主题色背景色标题色正文色，阴影交互点击悬浮model shfet等等

其他的比如说前端测试规范，CR规范等等，单元测试没写过哈哈哈哈所以暂时先讲到这，大家也可以提提意见，我来补充文章。