从几次事故引起的对项目质量保障的思考
近期发生了几件事故，第一件是封禁设备的事故，在后台有张页面，只要输入指定的设备号，就能禁止在该手机上登录。
问题就出在这个输入框，因为这个输入框什么也不填，点击按钮，也能发起禁用的接口。
有些用户记录中，设备号是空的，那么这些记录就会被命中，从而导致这些用户的账号被莫名禁用。
这么敏感的操作，居然没有加任何验证限制，轻轻松松就将几十万的用户封禁了，让人甚是意外，把人家产品都吓坏了，因为她点的这个按钮。
第二个事故是一张榜单活动的事故，页面没有真实数据，而是一堆假数据。又把产品吓坏了，一查就发现调用的接口居然是预发环境的。
当时是硬编码在代码中，QA也发现不了，因为确实可以读取到线上的数据。但是最近预发环境https的域名到期了，导致无法访问，从而就发生了假数据事故。
硬编码域名，遗留的假数据，这些都是比较细节的代码问题，在我看来，都是可以避免的。
这些问题虽然低级，但造成的危害可不小，如何有效的进行规避，是我近期一直在思考的事情。
一、Code Review
我首先想到的是Code Review，QA并不能帮忙验证代码的问题，但是Code Review可以。
大家坐下来，一起检查下代码的写法，一起判断业务逻辑是否合理，很容易就能发现上述两个事故中的问题。
其实从去年开始，我就着手组织过屈指可数的几次Code Review，是能发现些问题，但是忙碌的业务压得我们没有时间来做Code Review。
今年在人员补充后，工作产出大大提升，也有时间做Code Review了，并且公司环境也比较开放，上级领导不会干涉我们组内的这些非业务工作。
我们在会议中检查的主要内容包括：
- 是否遵循团队的代码风格，例如命名是否清晰、代码是否冗余等
- 代码是否满足质量特征，例如可读性、安全性等
- 业务逻辑是否合理
- 有没有潜在的安全风险
在进行多场Code Review后，我们得到的收获还是蛮多的，具体包括：
- 提升代码质量，降低开发成本和风险，发现测试或代码检查工具无法检测到的细节问题
- 提高、巩固和分享开发人员的专业技能和知识概念，了解第三方库的原理
- 保障软件开发的工艺，代码是一种基于知识和卓越标准的工艺
- 互相了解彼此的开发特点，能更顺畅的修改其他成员的代码
有句话叫磨刀不误砍柴工，Code Review不仅能提升团队的学习氛围，而且还能提高组员们的工作效率和生产力。
在Code Review的过程中，我们也会遵循一些黄金法则，来更好更和谐的完成Code Review，具体包括：
- 友善，清楚和具体的提问
- 在告诉别人代码需要修改时，需要给出修复建议
- 试图理解代码意图
- 表达感谢和欣赏同事的工作
网上有些团队是将Code Review合并到开发流程中，若未做Code Review，代码是无法合并到主分支的。
我们团队，目前还并未执行这类操作，还想先再做些探索，待到Review意识比较深入时，再做打算。
二、TypeScript
TypeScript也是我在近期引入到公司的一个项目中的，目的就是想利用其强类型来更好的约束变量的使用。
在将部分组件改造成TS的语法时，也遇到了些障碍，经常需要要去google上搜索一下，很多时候需要阅读英语资料。
首先是在将文件后缀从 js 修改成 ts 或 tsx 后，文件中的代码需要添加类型声明，并且不能直接引入 js 文件。
然后是引入的文件要么也进行改造，要么在文件目录中添加 *.d.ts 声明文件。
- 在使用 Ant Design 组件的属性时，也需要声明其类型，可以在”antd/lib/XXX“中查询到
- 当使用 Ant Design 组件传递参数时，需要传递必填属性
- 在各种函数中，需要声明传递的对象参数的类型
一些没有用ts写的第三方 npm 模块，可以在typings.d.ts中声明。
declare module 'query-string'; declare module 'lodash'; declare module 'react-sortable-hoc'; declare module 'papaparse';
最后还有些组件的改造，例如在底部导出组件时，若调用了 Form.create()，就不能像下面这样导出了，在使用组件的页面会报“has no properties in common with type 'IntrinsicAttributes”
export default connect((data: {template: TemplateModelState}) => ({state: data.template}))(Form.create()(CreateModal));
很多问题基本都是从 Github 和 StackOverflow 找到了答案，目前团队对TS的推进还比较缓慢。
三、ESLint
在我刚出道时，开发的是.NET，当时有一款ReSharper惊艳到了我， 非常智能，能自动优化我写的糟糕代码。
在改写其他语言之后，就没遇到合适的代码分析工具，几年后了解到ESLint。
这是一款非常有名的代码检测工具，是一个组员在做团队内部分享时，极力推荐的一款工具。
其实去年的时候，她就推荐过一次，但因为种种原因，并没有在组内推广。
今年的话，正好有个契机，那就是我制订了一份项目质量保障的计划，这款工具很适合。
先在VS Code中安装ESLint插件，修改配置文档。
{
//.vue文件template格式化支持，并使用js-beautify-html插件
"vetur.format.defaultFormatter.html": "js-beautify-html",
//js-beautify-html格式化配置，属性强制换行
"vetur.format.defaultFormatterOptions": {
"js-beautify-html": {
"wrap_attributes": "force-aligned"
}
},
//根据文件后缀名定义vue文件类型
"files.associations": {
"*.vue": "vue",
"*.cjson": "jsonc",
"*.wxss": "css",
"*.wxs": "javascript"
},
//配置 ESLint 检查的文件类型
"eslint.validate": [
"javascript",
"javascriptreact",
"vue"
],
"window.zoomLevel": 1,
"diffEditor.ignoreTrimWhitespace": false,
"explorer.confirmDelete": false,
"editor.wordWrap": "on",
//保存时eslint自动修复错误,,并不能修复所有问题，多数还是需要手动修复
"editor.codeActionsOnSave": {
"source.fixAll.eslint": true
},
"emmet.includeLanguages": {
"wxml": "html"
},
"minapp-vscode.disableAutoConfig": true,
"eslint.alwaysShowStatus": true,
"eslint.debug": true,
}
然后将本地的ESLint包升级到最新版本，顺便说句，原先是将依赖库的声明写在了package.json中，但是线上环境node版本太低，不支持ESLint的最新版，只得先去掉依赖。
npm install eslint npm install eslint-plugin-react npm install eslint-plugin-jsx-a11y npm install eslint-plugin-react-hooks npm install eslint-config-airbnb npm install eslint-plugin-import npm install typescript npm install @typescript-eslint/parser npm install @typescript-eslint/eslint-plugin
由于之前的代码都没有经过ESLint的洗礼，所以会出现大片大片的红色波浪线，这个要习惯。
缩进好弄，保存一下就会自动排版。还会报其他错误，但是在控制台中会给出错误描述和在线说，点击就能跳转，甚是方便。
ESLint的编码风格比较严，很多我之前的写法都是不允许的，例如 i++，修改函数参数，a元素必须包含href属性等。
所以在修改代码的时候需要做些权衡，并不是要完全照搬这些规则，可适当的关闭。
但一些比较明显的错误用法，还是需要遏制的，例如数组的 map()需要有返回值，调用的方法或函数在调用前的位置声明，依赖循环等。
ESLint对console.log会有警告提示，搜索了一下几个项目，遗留的console.log大概有1000多个，蛮占用日志的容量，也不利于日志翻查，需要清除。
但是既不能在构建打包的时候清除，也不能直接重写console.log，因为有些console.log是用于在监控系统中做调试的。
打开VS Code后，就发现可以全项目替换，在全局搜索中就有替换功能，只是之前一直没有注意到，这次派用场了。
参考资料：