简言：
不知不觉做了两年的前端leader，在这个美好的下午时光，对自己做个总结，同时也分享一下， 由于在这个公司待了多年，大大小小的项目做过十几个了，交付质量还算是可以的。两年前组织结构的调整，我就担任了一个部门的前端leader，从一个单纯的技术转变到了管理，从刚开始的四人小队逐渐发展到十人的团队，两年下来有很多的感触。
为什么要做管理？
1.有些时候，可能并不是我们主动需要的，在公司当时的发展情况下，需要有人来做这个事，所以部分高开都是在这样的情况转成管理的
2.在当代发展的趋势下，很少有大龄程序员始终在一线进行开发的，一部分公司对大龄程序员不太友好，加班加不过年轻人，由于家庭的负担，大龄程序员的成本相对也是比较高的，对于公司来说，做一般难度的项目，大龄程序员的性价比是远不如年轻人。从个人角度来说，开发转管理是大部分普通程序员所需要走的路，也是一种趋势，不同的年龄做不同的事情，大龄程序员所有的优势，在于你的积累与经验，遇见问题的解决能力，这些东西在管理上能更好的发挥作用，举个简单的例子，在同样的时间，你很好的做完一个项目，只有一个项目的价值，如果你带领其它几个萌新，你辅助与指导他们，在同样的时间能完成更多的项目，创造出更多的价值，同样由于你的指导和监管，其它几个项目的质量也是挺好的，如果不好，就是你的责任了。遵从价值最大化的原则，程序员也是慢慢的需要转管理的
3.利益金字塔模型，大家应该都知道，一线开发应该是处于最底层的，那么获取的利益可想而知的，管理层获取到的信息和利益一般是比开发高的，获取更多的信息为了能够及时应对变化，利益这个就不说了，打工不都是为了这个么。
4.做到管理自由度相对高一点，稍微有些权利能够选择自己要做的事，在管理妥当的情况下，你有更多的时间来进行技术的精进和研究，来精进自己
5.当然原因有很多，剩下的这一条由你来补充
管理需要做什么？
我想把这部分拆解成两类，向上和向下
向上管理
我们需要将领导的目标进行拆解
-
我们团队要做什么？
-
我们要产出什么？
-
我们需要什么资源，需要什么支持？
-
我们需要投入什么？
-
我们要怎么做？
我们要将规划、目标、产出详细的蓝图与上级达成一致，与上级的目标一致（这个很重要）
每个阶段（周、月、季度）量化出来更有帮助
一个团队存在的根本是要创造出价值，价值就是你的资本。当然公司也有很多人认为，向上管理换一种说法就是跪舔上级，怎么说呢，这也算是一种辅助能力，人性就是这样，都是趋利避害的，喜欢听好听的话语，需要有，但不推荐纯走这种路线，在公司昌盛的时候，可能不会有什么问题，在公司遇到危机的时候，价值能力才是你能留下的护身符，当然两者能并向发展的人都已经是大佬了。
向下管理
当向下管理的时候，就需要转变你的角色，你是这个团队的灵魂，你的性格和决策都会对这个团队有多多少少的影响，要有担当和责任感，兵怂就一个，可以fire掉，将怂就完了。
1.作为一个团队的带头人，首先需要稳住人心，人心一致，做什么都好干事。稳不住就需要去找原因了，是成员的问题还是自己的问题
2.人心一致，需要考虑的就是协作、分工的问题了，一个团队的运转，需要协作，有协助那么就需要有分工，每个环节都是一个正向需要的过程，你所做的就需要保持这个正向链路每个环节都不会出问题，不能因为分工的问题导致协作更加困难，不能因为协作而导致团队的运作出了问题，不能因为团队运转问题导致整个团队的价值变低。
3.在往下我们要搭班子，组团队，组团队我们不能都要能力一样的人，比如招了一堆js能力很强悍的人，碰见了一个比较棘手的css问题，一堆人坐那干瞪眼了。要根据公司的业务发展，有能力梯度建设，这样碰见难关的时候，更有作战能力。有踏实干活的，有js能力强悍，css能力强悍，工程化和框架擅长的，活跃团队气氛的，还需要来弥补你能力不足的人，招不来就需要自己来学习了。能力梯度是团队必须要考虑的
4.一个人来到一个新公司，无非就是为了薪资和成长，当然还有一些是养老的，组建自己想要的团队，薪资是自己无法决策的，我所能做的就是成长，团队要有自己的规范和技术规划
5.两年来自己在这个公司也做了很多，代码规范方面采用了husky+commitlint+eslint+stylelint+prettier强校验，由于大家在合作开发一个项目时，会因为代码风格问题出现各种各样的merge冲突问题，风格需要约束统一一致，这个是基础，有团队必须要有规范
git commit提交规范
（git commit提交时已加上husky和commit规范，希望大家能遵守这个规则,不按照规则提交的，无法提交代码）
1.commit 正常提交有两部分组成
type(scope?): subject // 本次提交代码修改的类型
body? // 本次提交的内容
示例 ： git commit -m "feat: xxxx"
git commit -m "feat: xxxx" --no-verify // 此指令是跳过检查的，不建议使用此操作（非特殊情况下不要使用）
下面是类型的介绍
| 类型 | 描述 |
|---|---|
| build | 主要目的是修改项目构建系统(例如 glup，webpack，rollup 的配置等)的提交 |
| ci | 主要目的是修改项目继续集成流程(例如 Travis，Jenkins，GitLab CI，Circle等)的提交 |
| docs | 文档更新 |
| feat | 新增功能 |
| merge | 分支合并 Merge branch ? of ? |
| fix | bug 修复 |
| perf | 性能, 体验优化 |
| refactor | 重构代码(既没有新增功能，也没有修复 bug) |
| style | 不影响程序逻辑的代码修改(修改空白字符，格式缩进，补全缺失的分号等，没有改变代码逻辑,css样式的更改) |
| test | 新增测试用例或是更新现有测试 |
| revert | 回滚某个更早之前的提交 |
| chore | 不属于以上类型的其它类型 |
前端编码规范-js
前端eslint检验规则，使用以下规则
1. 0或者off代表不检验，1 代表如果没有执行则报警告，2代表如果没有执行则报错，eslint报错，可以对应着这个进行修改
2. 具体官网详情：eslint.bootcss.com/docs/rules/ eslint.vuejs.org/rules/comme…
3. 如果出现某种情况下必须与lint规则冲突的话，或者lint报的错误较难修改，可使用 /* eslint-disable */，进行临时跳过检查，不建议较多使用破坏规则
'no-unreachable': 2, //不能有无法执行的代码
eqeqeq: 2, // 不要求非要使用 === 和 !== 新项目2
'no-empty-pattern': 2', // 禁止使用空解构
'space-in-parens': 2, // 强制在圆括号内使用一致的空格
'no-unused-vars': [2, { vars: 'all', args: 'after-used' }], //不能有声明后未被使用的变量或参数
'no-extra-semi': 2, //禁止多余的冒号
'no-dupe-args': 2, //禁止 function 定义中出现重名参数
'no-dupe-keys': 2, // 禁止对象字面量中出现重复的 key
'no-redeclare': 2, // 禁止多次声明同一变量
'no-prototype-builtins': 'off', // 禁止多次声明同一变量
'no-empty': 1, // 禁止出现空语句块
'no-useless-escape': 'off', // 禁用不必要的转义字符,先不开
'space-before-function-paren': [2, { anonymous: 'never', named: 'never' }], // 函数名后面加空格
'vue/no-unused-components': 2, // 没有使用的组件，报警告提示
'vue/require-prop-types': 1, // 在props中需要类型定义
'vue/require-default-prop': 1, // props中不需要默认值
'vue/no-lone-template': 2, // 禁止不必要的template标签
'vue/this-in-template': 2, // 禁止在模板中使用this
'vue/no-unused-vars': 2, // 如果未使用v-for指令或范围属性，定义的属性没有使用报警告
'vue/return-in-computed-property': 1, // 计算属性要存在return 返回值
'vue/require-prop-type-constructor': 2, // prop属性的type为基本数据类型，不能为构造函数
'vue/prop-name-casing':0, // 此规则强制在 vue 组件中正确地对 props 进行大小写（camelCase）本身应该开开
'vue/attribute-hyphenation':0, // 此规则强制在 Vue 模板中的自定义组件上使用带连字符的属性名称。本身应该开开
// 'space-before-function-paren': 1, // 定义函数时前面要空格
'eol-last': 2, //文本是否已单一换行符结束
'no-trailing-spaces': 1, // 禁用行尾空格
'vue/script-indent': [2, 2, { baseIndent: 1 }],
'vue/no-v-html':0, // 因为项目中有用富文本编辑器，对这个指令不进行校验
'vue/no-irregular-whitespace': [ 2, {
skipStrings: true,
skipComments: false,
skipRegExps: false,
skipTemplates: false,
skipHTMLAttributeValues: false,
skipHTMLTextContents: false
}
],
'vue/no-mutating-props': 2, // props的属性被修改，将报此问题
'vue/require-valid-default-prop': 2, //props声明的属性和默认值的类型不一样时，将报错执行
'vue/no-dupe-v-else-if': 2, // 防止重复的判断条件，无用的代码
'vue/require-v-for-key': 2, // v-for时写上key值，提高遍历效率
'vue/valid-v-model': 2, // v-model时不要写运算
'vue/valid-v-for': 2, // 对v-for的校验
'vue/no-use-v-if-with-v-for': 1, // 防止在同一元素上同时使用v-for指令和v-if指令
'vue/html-end-tags': 2, // 禁止缺少结束标签
// 'no-console': process.env.NODE_ENV === 'production' ? 'error' : 'off',
// 'no-debugger': process.env.NODE_ENV === 'production' ? 'error' : 'off',
quotes: ['error', 'single'], // 单引号
'comma-dangle': 0, // 根据项目自行添加
前端style书写规则-css
前端启用stylelint规则，书写统一的样式
具体详情可查看stylelint官网：stylelint.io/user-guide/…
'no-descending-specificity': null, // 禁止低优先级的选择器出现在高优先级的选择器之后
"block-no-empty": true, //不允许空块
"max-empty-lines": 1, // 相邻选择器之间需要空一行
"indentation": 2, // 缩进为2
"declaration-block-no-duplicate-properties": true, // 禁止在声明块内出现重复属性
"unit-no-unknown": true, //禁止未知单位
"no-duplicate-selectors": true, // 不允许重复的选择器
"font-family-no-missing-generic-family-keyword": null, // 禁止在字体族名称列表中缺少通用族
"declaration-block-single-line-max-declarations": null, // 限制一个单行声明块中声明的数量
"declaration-block-no-duplicate-properties": [ true, { // 不允许复制属性块中声明，不限制一些兼容的写法
ignore: ["consecutive-duplicates-with-different-values"],
} ],
"at-rule-no-unknown":[true,{
"ignoreAtRules":["mixin"]
}]
preitter可根据自己装的vscode进行配置，本地还可以安装上sonar-scanner插件在写代码的时候，进行自动扫描刚写过的代码，检查一些写的不规范或者写错的代码。
开发规范如果都加上 #### husky + commitlint + eslint + stylelint + prettier + sonnar-scanner,那么团队内写的代码这一块，就不需要太操心了。每次提交的代码都是很规范的，风格也都是统一的。
6.在对代码这一块放心了，需要对ui进行还原度进行自测，别的公司我可能不太了解，目前所在的公司对ui要求极高，经常被ui吊打，为了走出这个困境，借助谷歌这个插件 => Visual Inspector,来进行对自己画完的页面进行自我修改，这个插件的使用方法可以看插件介绍，在我写过的其它文章里也有介绍
7.一般写完这个之后，更加规范一点的我们需要加个单元测试，由于所在公司的业务比较繁忙，写单元测试也要费上很多时间，这一块就暂时省略了，但是为了保证业务这一块的质量，也是借助了另外一个谷歌的ui 自动化测试插件 => UI.Vision RPA 浏览器自动化工具(开源的 Selenium IDE, 现代的网页自动化工具 （支持行为录制和回放）。适用于网页自动化测试，表单填写以及网页内容抓取),来进行业务模块的自动化测试
8.在提测之前，再进行人工的code review，code review之前先对照着检查表先进行自我修改，自我修改之后，人工code review更多的是一个对代码以及上面规范执行的一个check。
下面是code review检查项
| 优先级 | 事项 | 内容 |
|---|---|---|
| 高 | 注释 | 每个函数必须有注释说明用途，以及参数的类型 |
| 高 | 注释 | 每个if判断必须有注释说明（包括v-if） |
| 高 | 注释 | data里面的数据有注释说明 |
| 高 | 注释 | 较复杂的逻辑（视情况而定） |
| 高 | 注释 | 正则加注释说明 |
| 高 | 命名 | 不要使用汉语拼音 |
| 高 | 命名 | 变量使用驼峰 |
| 中 | 命名 | 函数名以及变量名语义化（四个单词以上，过长使用简写加上注释） |
| 中 | 命名 | const和let做对应的事情，不要一直let，非必要情况下不用var |
| 中 | 命名 | 不使用关键字（比如：split） |
| 高 | 逻辑 | props传值 required type default 齐全以及注释说明 |
| 高 | 逻辑 | 监听完事件对应着移除，配套使用 |
| 高 | 逻辑 | 取dom操作时，一定要进行做非空判断 |
| 高 | 逻辑 | 对象取属性值或 json 转换时，一定要进行做非空判断 |
| 中 | 逻辑 | html中存在三个以上的逻辑判断写computed里 |
| 中 | 逻辑 | 同页面两次以上相同逻辑的复用，写到一个公共的函数调用 |
| 中 | 逻辑 | 公共方法函数代码，参数类型校验，健壮性是否良好 |
| 中 | 逻辑 | 尽量避免多层嵌套if（有使用的注释说明） |
| 中 | 逻辑 | 内部静态方法命名规范使用_开头 |
| 中 | 逻辑 | z-index非必要情况下，不要超过10,10个层级大部分页面已够用 |
| 中 | 逻辑 | 简单的if else逻辑用三元运算代替 |
| 中 | 逻辑 | 使用async await对应着用try catch进行捕获 |
| 中 | 逻辑 | html模板中不要使用this |
| 低 | 逻辑 | html 中较多的 if else 使用动态组件（视情况而定） |
| 低 | 逻辑 | 接口返回的数据尽量用解构赋值，看着比较清晰 |
| 高 | 样式 | 不加scoped的情况下，一定要用单个组件中最大的类名进行包裹，避免样式覆盖 |
| 中 | 样式 | html标签中有class类名的，就不要再写style行内样式（需要用变量动态处理的除外） |
| 中 | 样式 | style 尽量少的 !important，通配符（如果写，注释说明原因） |
| 低 | 样式 | 颜色六位相同的缩写成三位，0px的直接简写成0 |
| 低 | 样式 | style兼容性前缀非必要情况下不需要写，比如-webkit |
| 高 | 风格 | 单个方法不要超过50行或者一屏，不便于阅读，超过自行归类拆解 |
| 中 | 风格 | 删除掉无用代码或者不执行的代码 |
| 高 | 测试 | 经过sonar扫描， 接入 sentry 工具 |
| 高 | 注意 | 禁止使用外链CDN |
9.在上线前接入sentry，方便线上监控报错的收集，假如线上有问题出现，sentry能更好的帮你找到问题所在
10.以上就是我在前端leader期间，为团队所做的基础建设，从两个方面总结一下
代码方面：
husky + commitlint + eslint + stylelint + prettier + sonnar-scanner
质量保证方面：
code review + Visual Inspector + UI.Vision RPA + sentry
11.团队的基础建设做完，需要满足组员的成长，需要技术分享，这个事情不要老是leader自己去讲，只要有用的，完全是可以放给组员互相分享的，更能提高组员之间的参与感与团队的凝聚力。
相信自己的组员，有能力做好这个事情，每个人都是从不同行业因为有缘才能聚到一起的，没有说谁就一定技术强压谁一头，各自擅长的领域不同，不同前端（同一level下）之间都有其它人所需要学习的优点，来完善自我。
有一种学习法叫做费曼学习法，学习完一个知识，完全理解之后，给别人讲一遍学习效果是比较好的。
12.如果公司条件允许的话，可以做个技术规划能更好一些，作为一个前端leader，不能脱离业务，但也不要为业务所累。
当然，现在有很多的前端leader是纯管理或者是纯技术，没有对与错，所选择的道路不同，剑走边锋都会面临不同的烦恼，自己喜欢就好，个人认为两者相辅相成，综合发展会更好一些吧
总结
两年的前端leader时间，放弃了一些，收获了一些，从之前的关注个人，到现在关注整体的一个转变，多了一些责任感，有时能带给你一些在开发时体验不到的快乐，有时又不得不面对或者去做自己不喜欢做的事情，怎么说呢，喜忧各半，人总是要面对成长的。共勉！
欢迎各位小伙伴一起讨论，互相学习！
