代码质量是个很广的话题，本篇先从三个方面做分享（后期会逐渐补充），分别是:
1. 代码重构 ；
2. ES6（7、8、9、10）；
3. React相关优化 。
一、代码重构
关于重构可能是大家比较不愿意去做的一个事情，因为重构意味着我们要重新梳理代码逻辑，功能需求，以及有可能延误工期。但我是感觉我们是需要有一种渐进式重构意识存在的，如果当前的代码已经远远落后于现有技术，或者可读性已经无法容忍，那么还等什么，最好的解决方案就是重构，重构可以大幅度的提升代码的可读性，提高代码的简洁性，也更方便后期维护。
1. 重构前的资源协调
我们想要重构，首先要考虑的就是让业务方意识到重构的必要性、咨询各部门资源的剩余量、说服各部门参与配合前端重构。
导致重构的原因: 需求的频繁变动，紧急需求倒排工时，没有长期规划方向同步开发，团队代码风格不统一，技术的更新迭代等。
重构的必要性: 强调重构带来的技术收益和业务收益，提供切实可行的重构计划方案（包括人力资源，排期，改动范围等），让业务方、产品、后端、测试看到开发中的痛点和技术上的瓶颈，如不重构可能带来的后果（更新迭代的局限性,开发进度的缓慢，排查问题困难）
重构的好处： bug数量减少、维护成本降低、排查问题变快、开发速度提升等
2. 重构的步骤
根据重构涉及的范围可分为以下4种场景：
A. 改头换面重构（ vue -> react ）；
我第二家公司刚入职就参与了一场大重构，把原来老项目
vue换成react。 我们首先是把框架搭建起来，然后把需要重构的各个页面的优先级做一个排序，设计、前端、后端、测试全部参与进来，接口大部分还是可以重用，但前端需要重新写，当时。这里的重点是要保证旧的项目是可运行的，新的功能尽量在新项目里修改，排列好优先级，逐步迁移，一口吃不成个胖子。
B. 代码格式规范性重构（ js -> ts ）；
这个重构的重点是：先挑选一个目标或者一个改动方向，有把握地进行，保证每次修改都可以跑通，毕竟静态校验不是修改本身功能逻辑，出错的机率较小，我们少量多次进行修改即可。
C. 公共组件重构；
关于公共组件的重构，要遵循优雅降级和渐进增强的原则，如果当前公共组件被依赖的较少，那一次性即可完成全部更新，但如果是使用频率较高的组件重构可能影响的范围较广，那就需要在兼容老的写法的同时做渐进式更新重构，后续再修改时逐步将旧的方法放弃。
D. 具体功能重构。
本来以为文字可以表达清楚，可当自己写下后发现还是画图表达更加清晰：
先检查是否有被其他组件引用，是否有依赖项，如有，保证此次重构不会对其产生影响，如都无，梳理当前业务，和测试及产品同步修改范围（一般情况下不涉及后端改动的，通知后端知晓，以防有问题需要咨询后端同学）->前端开发->协同测试完成回归->通知产品验收->通知业务方改动，建立企业微信问题发聩群，保证有问题随时反馈
3. 代码修改规则
具体到代码的修改，推荐遵循以下几种规则：
- 单一职责原则
（SRP：Single responsibility principle）
又称单一功能原则，面向对象五个基本原则（SOLID）之一。它规定一个类应该只有一个发生变化的原因。
姓名 ：单一职责原则
英文名 ：Single Responsibility Principle
座右铭 ：There should never be more than one reason for a class to change. 应当有且仅有一个原因引起类的变更。。。意思就是不管干啥，我都只干一件事，你叫我去买菜，我就只买菜，叫我顺便去倒垃圾就不干了，就这么拽
脾气 ：一个字“拽”，两个字“特拽“
伴侣 ：老子职责单一，哪来的伴侣？
个人介绍 ：在这个人兼多责的社会里，我显得那么的特立独行，殊不知，现在社会上发生的很多事情都是因为没有处理好职责导致的，比如，经常有些父母带着小孩，一边玩手机，导致小孩弄丢、发生事故等等
其实意思也就是一个方法，一个页面组件最好只有一个功能或者职责，尽量少耦合多个功能放在同一个方法里面，这样对于后期查找问题，复用逻辑来说都是很好的习惯。
- 命名规范
命名规范是老生常谈了，我们常常吐槽别人起名的同时也需要关注一下自己的命名规则，命名好像你衣橱的衣服，一目了然更要整齐划一。命名规则参考
- 风格统一
代码风格统一，我们每个人开发都有自己的风格，但很多时候同一个人写出的代码会有多种风格，这导致自己写的代码自己后期维护也不好找问题。如果公司团队有规范，我们尽量遵守，或者你认为公司的规范不对，可以提出来，然后团队开发尽量向其靠拢，这样我们后期维护也不至于有太多的怨言，哈哈哈哈....
- 重复代码--
Repeat Code
关于重复代码这个我建议如果多于
1处以上的要提成页面级的功能组件，如果超过3处以上的提到公共组件。我们尽量减少重复代码的书写，一方面浪费时间，另一方面维护起来也困难，当然功能组件和公共组件也可以是差异化的，根据传参不同，返回不同内容。
最后的最后：
最后说说我的想法吧：当代码有了坏味道，我们要做的第一件事就是标记起来，安排时间及时改善。打个比方，你发现每天路过的那个墙面有人挖了个洞，过两天发现洞越来越大，可能是因为从这里过可以抄近路，可是当走的人多了，洞口越来越大，这面墙也越来越危险，随时可能有塌方的可能。我们在看到这个洞的时候是不是可以想一想：既然这个捷径是给大家带来了方便，那是否可以通知物业或者居委会把这面墙拿掉？如果是规范问题，无法拿掉，或者研究如何把墙面修补好？ 而不是看着它一天天越来越危险。 要知道，雪崩时没有一片雪花是无辜的 。
二、ES6
这里说的
ES6是一个广义的概念，包括并不限于ES6、ES7、ES8、ES9、ES10等的一个统筹概念。我今天就给大家分享一下，那些我平常工作中关于常用的ES6的使用习惯，如有误，望指正。
1. 变量定义：
首先就是变量的定义，现在代码里已经没有再出现过
var，取而代之的就是let和const，最多的就是常量const，原因就在他们的区别之处了