一定要知道的代码规范
大家好，我是晨光，5 年前端开发，现在携程担任高级前端开发。上次分享了我转岗的适应过程，原贴见 https://t.zsxq.com/0fNqoDYW9 ，今天分享我转岗后，被老板蹂躏的两周我有哪些收获。
一、被蹂躏过程
换了新团队，组内的各种代码规范，让我感觉有些拘束，每次提交代码，都需要同事 code review，而且还不是简简单单的帮你点 merge 按钮，而是实实在在的一行一行的读你的代码。
一开始，这种方式，让我有种很不舒服的感觉，就好像自己在不断的被他人质疑，不停的更正写法，更准确的说，是在不断的更正你的思维习惯，一时间确实让人有些无法接受。
清楚的记得，一开始写的代码，提交后有12个 overview，并且更正了3次，才 merge 通过。相比之前让同事 CR，就是让帮忙点一下按钮，同事不忙的话，会问问你写的什么内容，逻辑是怎样的；忙的话，就直接 merge。
现在，不管你忙不忙，同事忙不忙，CR 是一个必须的环节，就算同事很忙，也会认真查看并确认没有需要调整的内容，才会点击 merge，可以说， 新团队的 CR 是一个很负责任的行为。
二、代码规范
写了快两周的代码，现在 commit，没有太多的问题了。所以把同事之前给我提的问题，大致归纳整理了下，如下：
1、注释规范
- 方法内注释使用 //
- 方法及类注释使用/** */
- 类成员变量注释使用/** */
- 注释需要规范，且要清晰，描述字段或方法的意义和用处以及如何使用，如果字段命名很清晰，也可不写注释
- 待完成的内容可加 //TODO ， TODO 后可跟上自己的姓名缩写，代表个人的 TODO，不和他人的发生混淆，也防止时间间隔太久忘记哪里需要 TODO
加 TODO 很有必要，之前还遇到过两次就是忘记加 TODO，写了默认值的情况，虽然那个参数不是很重要，但是相当于一直传了默认值给接口，总之就是能少给自己挖坑。
2、命名规范
- 点击事件方法名统一使用 onPress开头
- 布尔类型的命名都以is, has, any等开头
- 除了接口字段使用大驼峰，其余统一使用小驼峰
- 方法名和字段名命名时，要注意抽象程度，比如获取姓名的方法，就可以命名为 getName
3、常量使用
- icon 使用统一的静态资源文件，不要直接写 code码
- 数据处理，字段拼接步骤 可直接放在 model 层
4、基础代码规范
- switch case 语句必须包含 default: break;
- 删除无效代码
- 配置 eslint，安装 eslint插件
- 每个方法之间应该有且仅有一个空行
- page，Module，View 需严格区分，可以体现在文件命名上
- 一个页面为一个 pageModule 对应的文件夹为 pageModule， 内部就是一个 module的组合，也可以包含一些小组件 View
- 页面中的一个模块为一个 module， 对应的文件名也为 xxxModule.tsx
- module 中的 View 拆分的小组件也为 View ，对应文件命名为 xxxView.tsx
- 数据类型不要使用 any， 尽量都定义 interface
- if语句，如果第二行只有一条语句，也尽量新启一行，并用{}括起来，代码可读性高些
- 字段兜底需要做好，某些该为空字符串，或者初始值或默认值也要写好
- 若 presenter 层有监听方法，需要添加 destroy 方法，在页面卸载时清空 subscriptions
- 频繁使用的字段可以放在 viewModel 或 state 中，不用每次获取都调用方法
注：presenter 层，类似 MVC 的 C 层，主要是 model 层和 view 层的桥梁目前团队采用 MVP 的模式书写代码，主要就是为了视图和逻辑分离，并采用发布订阅的模式，通过 P 层把 model 层的方法传给 view层，并在 P 层调用接口，并监听接口返回，并在 P层调用 model 层的方法，存储接口返回的数据。每种设计模式都有它的利弊，目前的 MVP 模式逻辑复用率很高，可以实现多端逻辑复用，利于代码的维护。
MVP 框架是我们团队写的一个框架，采用了发布订阅的模式，保证从上至下是单向数据流，能够解决传统 redux 数据 set 混乱的情况，该框架可以让我们查问题更容易。虽然一开始接触这个框架的时候，感觉各种被限制，但是熟了之后，就非常的香！
以上的代码规范，可以根据目前自己团队的规范调整，但 vscode 一些插件可以安装，利于遵守代码书写规范。推荐插件
- Eslint 代码规范校验
- Prettier 代码一键格式化
- GitLens 方便查看提交记录
- Git Graph 方便查看提交记录
以上，全文完，有启发的话，点个赞呗～
