前端代码质量优化交流

若不碎我，必逆境生花

目录

• 项目角度
• 格式角度
• 代码角度
• Git  角度
• 编辑器角度

前言

相信你们都有过这种状况，接盘。没错，你不知道在你面前放着的代码通过几我的的手，里面有几种风格。我见过一个项目，七、8我的接手过，轮到我接手的时候先吐了半个小时。在中大型项目中，这是一种常态，我一般称此类项目为shi山。那么咱们怎么才能把项目code质量这一块，掌控的死死的呢？代码的健壮性如何加强？

个人上一篇文章《前端性能优化交流》讲了一下在项目开发流程中，进行项目性能的优化。这一篇则是基于优化的前提下，对于代码质量、健壮性的一个把控。

1、项目角度

搭建框架，定制技术

一、 统一框架 - 统一技术手段

若是你作的是中大型项目或者是团队开发模式，这一点必定是基础原则，在评审需求文档步骤，了解到项目中大概的业务核心及技术难点，而后项目中前端同窗们统一调研技术手段。

然而这点为何拿出来讲呢，我见过蛮多没按照这个标准的。

例1：由于找不到开源js

react 项目引用 jquery （貌似是为了引用一个jq拖拽插件）

这种很少说了，根本不该该存在这种状况，应该多探讨，多摸索解决方式，拓宽本身对于各类业务的解决手段。

在此推荐你们推荐一个找技术库的网站，也能够在排行榜上了解到最新、最受欢迎的技术库。

www.awesomes.cn/

例2：UI组件不知足项目需求

项目中运用两种UI框架，antd、antd-mobile

当UI组件不知足项目需求的时候，确定也不可能引入两种UI框架，对于项目来讲负担变太大。

我推荐每一个项目在开始的时候本身抽分UI组件库，创建一个公司的私有npm库，而后你们所作的项目中的组件，都能沉淀下来，创建本身的npm库，其中不光能够有UI组件、还能够有业务组件、脚手架等。

2、格式角度

一、eslint（lint: 包扎伤口的纱布）

js代码规范重要的一步。由于javascript是弱语言，很灵活，规则范围很大。因此常常就造成一种“怎么写都不会出错”的问题，每一个人的代码风格不一。例如：Tab和空格混用、使用弃用方法、等。

若是你配置过eslint，我这边整理了一些配置属性，你能够搭配一些项目中须要的规范：

若是你没有配置过eslint配置文件，传送门： eslint简单介绍

我这里把我项目中的eslint配置文件共享出来。放到你的项目中直接使用。

二、stylelint

stylelint 跟eslint 同样，只不过是对于css的一系列规范。

传送门：stylelint简单介绍

传送门中的文章讲解比较详细，我就很少余阐述了。

3、代码角度

• 变量命名
  
  很基础的一点，也是不少人最惆怅的一点，为变量起名字太难了。
  
  老生常谈的格式方面：
  
  骆驼式命名法（Camel-Case）又称驼峰式命名法，是电脑程式编写时的一套命名规则（惯例）。正如它的名称CamelCase所表示的那样，是指混合使用大小写字母来构成变量和函数的名字。程序员们为了本身的代码能更容易的在同行之间交流，因此多采起统一的可读性比较好的命名方式。
  
  驼峰命名法 我应该不用多说了，这个是最最最基本的命名规范。
  以后，问题来了
  
  不少业务词语我不知道英文怎么拼怎么办？
  
  统一走相同的翻译平台。讲道理，谷歌翻译跟百度翻译，翻译一个单词不必定同样。
  
  以后，问题又来了。
  
  变量名拼接过长，按什么顺序拼？
  
  这个问题我也是前一段时间看过一种思路，按照英语课本上的来。统一走英文语法，动词、名词、形容词。英文造句语法圈起来重点考。
  
  好比说有个方法叫“坐火车去拉萨的途中作一些事情”，我认为正确的：onTheWayToLhasaByTrainDoSomeThing()，常见的写法：ByTrainToLhasaOnTheWayDoSomeThing() -- 途中坐火车去拉萨作一些事情。语法仍是要注意一下的，不然上面这就变成两个方法了

一、组件细化

一、组件不超过250行

常常看到某个项目中组件一打开，1000+行，维护性、可继承性都不好，打开以后一脸懵逼。大多数状况下（非业务须要）超过250行的组件均可以拆分红更小的组件来维护。当你把全部组件都拆完了，你会拆出不少纯组件-不掺杂业务的组件，这是就能够进行公共组件抽象提取，你会发现有不少能够提取的公共组件。

二、全局样式污染问题优化

当组件抽象够多，拆分够细后，注意一下样式污染问题，我接触的项目直接走style hash时候居多，但这里推荐classnames插件，拼接业务惟一标识到className前面，这样比直接用hash更好调试，而且每一个组件就算格式同样 className 起名字同样也不会混淆。

使用方式：
npm i classnames --save
设置公共方法

组件中使用的时候

三、渲染次数优化

这个问题我在《跟你们聊一下前端性能怎么优化》那篇文章中提到过，在目录 四-2。

问题的解决方法在于合理触发render。

二、 数据抽象-逻辑解耦

这两个词语有些官方了，大概的意思为‘拆’。拆完再合并。

上面说了组件抽象的时候咱们规定250行左右。方法定制在100行。相信你们也总会见到不少庞大的方法，这种方法仔细分析的话必定是掺杂了业务在里面，并无把单独逻辑与业务分开来维护，使得这种方法即便写了备注，一动则牵引全身，修复完一个问题，出来10个问题，这就很恐怖了。

因此咱们规定方法不准超过100行，若是你的方法超过100行，就说明能够拆分红两个或几个更小的逻辑的组合。

这种称之为逻辑解耦，咱们拆完以后会发现不少的逻辑实际上是同样的，这时候就能够进行数据抽象，提取公共方法，沉淀成公共方法库，编写好备注，使用文档。咱们就能够很好的进行之后的维护，继承，修改等等工做。好久之前这种方法库我都是放u盘里随身携带...

这里重点：jsinspect，上述中的组件抽象及逻辑抽象均可经过此插件来整理，设定好排查路径，则会直接生成一个文件列表，告诉你哪里和哪里是类似的能够抽象，很是好用。

替换一下src路径便可，执行npm run check:json 就会在根目录下生成jsinspect.json文件，里面整理的很详细。

三、 try catch

很重要的细节，咱们常说输在了细节是吧。你们仔细看

若是接口返回statusCode异常，能够在你的ajax层拦截掉，若是statusCode 200ok，可是接口返回数据异常，那就gg了。为何呢？若是你须要一个array，后台忽然返回了个object，极大多数都会触发js错误，界面直接崩掉以后展现js错误信息。

这种状况在项目中是不容许存在的，哪怕服务器爆炸了前端页面也应该面不改色的弹出一句提示“服务器爆炸了，请明天记得看报纸”。对吧，而后咱们默默的让用户退出系统就行了。那么，这里咱们的try catch放在哪里呢?

若是全部的promise都配一个try cath的话，除了麻烦， 讲道理，是没有问题的，
promise(() => {}).then(res => { try { res... } catch { ... } })
然而，这里总会有个小转折，咱们能够把这个抓取js错误的方法放在入口处，没错，就是路由。单页面应用的项目都是把路由插入到单页面节点中，在插入的方法外层try catch，一劳永逸。

四、 全部节点需有惟一识别key

这一点来讲也是蛮重要的，如今不管react，vue，angular，都是组件化开发模式，在这种模式下，底层原理都是构造虚拟树的diff算法，用来判断哪些组件重绘，哪些不用重绘。

一般的DOM元素的key是自动生成的。然而，在何时会有问题呢？举个例子

我须要渲染一万条数据，后台没返回惟一识别id，用角标代替

这样，咱们的数据的key为“0、一、二、...”，表面上看没什么问题。若是咱们进行删除操做，删除第一条数据，那么重绘的时候key就会从新排列，曾经的第二条就变成了第一条，key变为了0，以此类推，diff算法用key断定是否是相同DOM节点，而后比较内容，剩下的9999条数据的内容跟上次记录的树全变了，由于对比的时候是拿 上次第一条数据的内容去比较如今第二条数据的内容，由于第二条数据的key变成了0，不知道我阐述明白没有。因此会重绘9999个DOM节点。

那么：若是key是惟一的

对比key以后对比内容，就不会重绘9999个DOM，只是单独删除掉了第一个dom元素而已。新增功能于此相同。因此你们要注意一下惟一值key的问题。

五、 prettier

此插件用来格式化代码，使代码哪怕在开发的时候格式混乱，是吧，编译一下，就会变成统一格式。很是适合团队开发使用。

这个时候有些同窗可能会有个疑问，个人开发工具，好比vscode，能够下载开发工具插件，如图。

开发工具中也能够装一些插件辅助你开发，可是这个，只能辅助你本身，若是你的同事没有装，或者装了跟你配置的不同，那么就很是不理想了，因此说，仍是在项目中配置eslint，prettier等规范为上策。

4、Git角度

一、precommit

经过git precommit钩子，每一个人在上传代码的时候作一层拦截，保证上传到gitlab上的代码质量。

这里话很少说，你们看完package.json配置就懂了

一、husky：对 git 进行 hook，能够在 git 操做以前作一些操做； 二、lint-staged：对当前 git 提交的代码进行一些操做。

直接按照我这样配置好就能够了，每次上传代码的时候都会走一遍上述所说的eslint、stylelint、prettier等规范。固然也能够自定义一些操做。

二、merge request

锁定master分支，其他代码想合并到master 的时候，须要提交merge request，而后须要进行代码评审，至少两我的，经过评审才能够将代码合并到master分支。咱们的大型项目都是这种模式，十分严谨。你们还能够相互学习写法，探讨思路，此功能gitlab自带，配置一下就好，有须要的能够去了解一波。

5、编辑器角度

这一点来讲，项目中能够统一开发工具的配置，文件名为.editorconfig的根目录配置。

咱们经过.editorcofig文件能够统一开发工具的配置环境，就算你的同事用的sublime，你用的vscode 也不会影响代码风格，规则等问题。

我这边也直接给出一个配置文件。

END

上周很忙，手里同时三个项目，真是在抽时间写文章，写文章真的没那么简单，对于一些东西的串联的时候才发现本身不足的地方不少，多谢各位包容，若是有错误欢迎你们指出。这周的任务虽然仍是很紧，我仍是会完成个人承诺。不辜负个人28个关注人。我去改bug了，下次见。

我这边3月底以前会写4篇文章，分别为

《前端性能优化交流》 《前端代码质量优化交流》(本篇) 《前端code监控交流》 《前端安全问题交流》 沉淀一下去年在开发流程方面的一些知识。 谢谢各位。