目录
- 前言
- code review
- 封装
- 抽象
- 组件化
- performance optimization
- END
前言
在一个团队中，代码质量问题真是一直备受操心的问题，总想通过种种规则来规范code的问题。但是事与愿违，一切的根源还是来自于每个人的自我要求。我一直说一句话，语言很灵活，想怎么写都可以。但是从团队中或一个负责人的角度出发，需要谨慎。
code review
先说说code review的问题吧。这个事情是最难执行下去的，坚持执行了几个月。虽然还不理想，但是项目仓库代码整体质量还是有所提升。
我先解读一下流程
-
项目提交测试环境之前进行code review (组内相互)。
-
业务分支mr review分支进行code reivew。
-
所有问题discussion沟通，wiki落地。
先认清楚一个问题，团队水平参差不齐，我们暂且抱着不淘汰任何人的想法。
如果这时你发现团队中每次都会review出来很多一样的问题，那么你就需要重视了。这个就是团队的知识体系盲点。
及时做好调研，准备一些方式，比如分享进行“补课”。
code review的终极目标是对于业务核心代码进行多人换位思考，以这种方式来提升code整体健壮性。如果你的团队知识盲点还有很多，那么就会起到一个相反的效果，每次review的时候都会有很多基础的问题暴露，这样就只会浪费了时间，拖慢了我们的开发流程。
review代码的规则：
其实每个团队对于语法逻辑的规范都是通过eslint，会挑选一些配置到架构中。我用过的最好的就是airbnb，airbnb还有另一个名字，javascript guid style，了解的人可能知道像C语言这种都有自己的guid style规范，而前端大多数人选择airbnb是有理由的，虽然很严格，但是有助于团队及个人提升代码整体质量。
review的模式：
我推荐至少两个人进行review，思维的碰撞和认可才能更好的产出。
封装
开发中，对于方法、组件的封装也是非常重要的。我一直认为对于开发来说就是在开发一个一个的汽车零件，最终运用这些零件来拼凑成各种成品车，哪怕是一辆布加迪威龙。
我们先来科普一下官方概念。
封装就是提高单一功能或模块的独立性和复用。任何为这个目标所做的努力都是在对代码封装。
我们再来科普一下民间概念
我们组装了一台电脑，主板、显卡、电源、硬盘都放在机箱里面，机箱只开放了几个usb接口和一个插头出来。机箱就是对里面的东西进行封装。
封装的好处：
封装了之后，代码量会变少，代码复用率变高。代码看上去很干练。
封装的坏处：
代码耦合度变高，定制化变差。
万事都是一把双刃剑，kan不到自己就是好剑。
业务中的实例：
一个统一拼接url公共参数的方法。因为封装了getWithToken方法，所以我们让业务调用的地方更加纯粹。
抽象
抽象的概念就是一个字，拆。
函数化编程核心理念之一，每个函数独立运行维护自身逻辑。
就拿上述getWithToken函数举例，函数内部包含了两个方法
- 拼接url参数
- 发送axios默认get请求
首先，耦合度太高，只能固定拼接token参数在后面，也只能发送axios默认的get方法。
然而，如果再开放api出去动态配置url参数拼接或者axios方法之类的就过度封装了。使得这个函数变得“不专一”。
这个时候我们可以抽象这两个方法出去，再在getWithToken中进行整合。
抽离参数拼接动态方法。
这样我们就有了一个拼接url参数的公共方法，顺便可以维护到自己的公共组件库，我也是文章写到这现写的方法，所以在业务开发中，抽离这种公共是非常节省时间的，你攥写这个方法五分钟，以后会节省自己或者团队无数个五分钟。维护和推动自己的方法库也是非常重要的。这都是题外话了，我们继续。
先改写一下上面的getWithToken函数
继续抽象axios模块，如果先不考虑封装axios的文件上传，那么至少需要抽象出来的公共方法为method，我们先尝试一下。
这样的话，我们就拓展了一个axios的公共方法。下面改写一下getWithToken方法。
这样的话我们就完成了_axios、combUrlQuery函数的抽象，getWidthToken函数的封装。
组件化
基于react组件化开发一直也是我所推动的事情，无可厚非。然而组件与函数类似，写法也很灵活，如果没有设计好组件结构，状态规划。那么维护性、扩展性大大下降。
首先，确认下组件化开发的核心想法。
react.docschina.org/docs/thinki…
react官方文档上面明确指出组件化开发的想法，并且为react的核心理念。
怎么判断组件拆分范围，文档出也给出了答案。
根据单一功能原则来判定组件的范围
我们根据这个原则进行组件划分，分成容器组件、公共组件、业务组件，纯组件等等。
我们的目标：
更多的纯组件、更多的公共组件。
在进行组件化拆分并且开发完毕之后，你会发现一些问题，这边提前暴露出来。比如：
上图就是组件之间相互调用及状态传递的示意图，组件之间相互调用，相互传递状态，非常的混乱，如果项目稍微复杂一点的话，就会变的难以维护。
这时，对于状态管理就需要进行一系列的规则进行梳理。这里我记下，单独写一片状态管理使用的文章。
组件的封装与函数的封装同理。
performance optimization
1、渲染
老生常谈，PureComponent，shouldComponentUpdate，进行render拦截，项目组常见的底层组件render次数多的吓人，PC上效果可能不太明显，移动端上效果就会很明显。我们可以打开performance tools来查看页面渲染时长。
我认为这是一个开发组件必备的思考要素，非常值得重视。
2、算法
算法现在已然成为必备的基础能力之一，还是建议有事儿没事儿去leetcode刷刷题。
自己封装好的函数去跑一跑，看看在数据量变大的时候会不会有性能瓶颈。
做大数据项目的时候性能优化主要从算法入手来提升项目代码的健壮性。附上一个链接吧。
END
我们在开发中总会遇到很多问题，暴露出来问题是好事，主动站出来直面问题并解决问题才是程序员应该做的事情。
这篇文章是 《前端代码质量优化交流》后续篇
希望对大家有帮助。
