对于大型或超大型公司，规范引入和实施工作通常由对应的自研Cli工具来完成。
规范引入
eslint规则检查提示
通常项目会引入eslint来检查代码，以期望能够统一代码风格。
rules用来自己来定义所有的规则，但是通常都会使用业界流行的规范，可使用extends配置来引入。
"extends": [ // 推荐使用默认配置好的
"eslint:recommended",
"plugin:react/recommended",
'plugin:@typescript-eslint/recommended',
"plugin:import/typescript",
"plugin:prettier/recommended"
],
在特定场景下的检查需求可以使用plugin来检查
"plugins": [
"@typescript-eslint",
"react",
"prettier"
],
prettier代码格式化
我们在eslint配置中引入了prettier插件，还需要对他进行一些配置.prettierrc
module.exports = {
"printWidth": 100, // 指定代码长度，超出换行
"tabWidth": 2, // tab 键的宽度
"useTabs": false, // 不使用tab
"semi": false, // 结尾加上分号
"singleQuote": true, // 使用单引号
...
}
因此根据我们配置的eslint规则和prettier规则
typescript引入
作为多人协作的必备js增强语言，ts的作用已基本不可替代，ts的优点不再赘述。
要使用ts或react的tsx，那么先配置tsconfig.json告诉编译器把ts转换为js的规则。
{
"compilerOptions": {
"target": "es5",
"module": "esnext",
"moduleResolution": "node",
"allowJs": true,
"lib": ["DOM", "ES5", "ES6", "ES7", "ESNext"],
"jsx": "react",
"sourceMap": false,
"strict": true,
"noImplicitAny": true,
"baseUrl": "./",
"paths": {
"@/*": ["src/*"]
},
"allowSyntheticDefaultImports": true,
"esModuleInterop": true,
"experimentalDecorators": true,
"forceConsistentCasingInFileNames": true,
"skipLibCheck": true
},
"exclude": [
"node_modules",
],
"include": [
"src",
"typings/**/*"
]
}
接下来配置babel使用预设的babel插件来负责转换
"presets": [
"@babel/preset-typescript", //实际就是@babel/plugin-transform-typescript
...
],
最后就是webpack配置使用loader处理jsx|tsx文件了。
rules: [
{
test: /\.(jsx?|tsx?)$/,
exclude: /(node_modules)/,
use: [
{
loader: "babel-loader",
options: {
cacheDirectory: true
}
}
]
},
]
开发过程
IDE插件和配置
开发过程中通常会习惯性的格式化代码，可以安装prettier的vscode插件。插件安装好了还需要配置统一的.vscode下settings.json，使其使用项目规定的prettier规范而不是其他的格式化工具。
settings.json配置
ts定义文件自动生成
公司级别应规范后端服务引入swagger，主流的后端应用框架和语言都有swagger接入库，或满足openAPI标准。在此基础上使用dtsgenerator可根据后端接口标准自动生成全量API接口的d.ts定义文件。
有了全量的API接口d.ts定义文件后，业务开发只需要书写少量的接口既可满足全ts类型覆盖。相应的noAny要求就可以上了。
编译构建
在前面已经配置好了eslint规则的配置文件，那么在构建阶段只需要跑eslint命令进行代码规范检查和自动格式化就好了。
//webpack指令配置
{
test: /\.(jsx?|tsx?)$/,
use: [
loader: "eslint-loader",
options: {
fix: true
}
]
}
借助webpack的eslint-loader在构建，通常是本地调试时启用自动格式化。
提交检查
在git的提交时添加hook做代码检查和修复
"pre-commit": [ "eslint src --fix --quiet --ext .ts,.tsx",],
或者使用husky
"husky": { "hooks": { "pre-commit": "eslint src --fix --quiet --ext .ts,.tsx" }}
当然一般来说提交代码的时候不需要检查和修复所有代码，只需要对暂存区staged的文件进行处理，所以一般都使用lint-staged来处理。
"husky": { "hooks": { "pre-commit": "lint-staged" }},"lint-staged": { "src/**": [ "prettier --config .prettierrc --write", "eslint --fix", "git add" ]}
代码扫描
sonar作为静态代码检查工具，可以从7个方面进行代码扫描，用于管理代码质量。
从开发侧入手，关注点主要在于: 注释率和重复代码
而复杂度分析和代码结构和设计扫描就仁者见仁智者见智了
代码规则检查已经在前几个阶段进行了规范，所以在这一阶段不用太关注
潜在bug和单元测试覆盖率属于质量管控，不在代码规范和开发侧的范围。
代码审查
代码审查主要审查什么？
这个问题是很多团队都会遇到的问题，大部分团队对于怎么做code review并没有一个很清晰的标准，通常流于形式或者是用来怼人，久而久之也就没有code review了。
要明确审查什么，需要首先知道代码审查的目的，个人认为代码审查的首要目的还是在于可维护性。因此可以从2个方面入手：
-
代码风格
这个由前面的规范来固化，这样整个团队的代码风格是趋于统一的。
-
代码易读性
结合sonar的扫描结果来辅助进行，在code Review的时候就注释率和重复代码进行审查。同时可以在核心模块或复用模块对代码结构和设计进行一定的审查，通常由技术leader或经验充足的资深来做。
还有一个点是代码效率，但是执行效率通常在ToB业务场景不是大问题，只能case by case当遇到有较严重问题的时候进行分析和团队复盘。
