若不碎我,必逆境生花
目录
- 项目角度
- 格式角度
- 代码角度
- Git 角度
- 编辑器角度
前言
相信大家都有过这种情况,接盘。没错,你不知道在你面前放着的代码经过几个人的手,里面有几种风格。我见过一个项目,7、8个人接手过,轮到我接手的时候先吐了半个小时。在中大型项目中,这是一种常态,我通常称此类项目为shi山。那么我们怎么才能把项目code质量这一块,掌控的死死的呢?代码的健壮性如何增强?
我的上一篇文章《前端性能优化交流》讲了一下在项目开发流程中,进行项目性能的优化。这一篇则是基于优化的前提下,对于代码质量、健壮性的一个把控。
一、项目角度
搭建框架,定制技术
1、 统一框架 - 统一技术手段
如果你做的是中大型项目或者是团队开发模式,这一点一定是基础原则,在评审需求文档步骤,了解到项目中大概的业务核心及技术难点,然后项目中前端同学们统一调研技术手段。
然而这点为什么拿出来说呢,我见过蛮多没按照这个标准的。
例1:因为找不到开源js
react 项目引用 jquery (貌似是为了引用一个jq拖拽插件)
这种不多说了,根本不应该存在这种情况,应该多探讨,多摸索解决方式,拓宽自己对于各种业务的解决手段。
在此推荐大家推荐一个找技术库的网站,也可以在排行榜上了解到最新、最受欢迎的技术库。
例2:UI组件不满足项目需求
项目中运用两种UI框架,antd、antd-mobile
当UI组件不满足项目需求的时候,肯定也不可能引入两种UI框架,对于项目来说负担变太大。
我推荐每个项目在开始的时候自己抽分UI组件库,建立一个公司的私有npm库,然后大家所做的项目中的组件,都能沉淀下来,建立自己的npm库,其中不光可以有UI组件、还可以有业务组件、脚手架等。
二、格式角度
1、eslint(lint: 包扎伤口的纱布)
js代码规范重要的一步。因为javascript是弱语言,很灵活,规则范围很大。所以经常就形成一种“怎么写都不会出错”的问题,每个人的代码风格不一。例如:Tab和空格混用、使用弃用方法、等。
如果你配置过eslint,我这边整理了一些配置属性,你可以搭配一些项目中需要的规范:
我这里把我项目中的eslint配置文件共享出来。放到你的项目中直接使用。
2、stylelint
stylelint 跟eslint 一样,只不过是对于css的一系列规范。
传送门:stylelint简单介绍
传送门中的文章讲解比较详细,我就不多余阐述了。
三、代码角度
- 变量命名
很基础的一点,也是很多人最惆怅的一点,为变量起名字太难了。
老生常谈的格式方面:
骆驼式命名法(Camel-Case)又称驼峰式命名法,是电脑程式编写时的一套命名规则(惯例)。正如它的名称CamelCase所表示的那样,是指混合使用大小写字母来构成变量和函数的名字。程序员们为了自己的代码能更容易的在同行之间交流,所以多采取统一的可读性比较好的命名方式。
驼峰命名法 我应该不用多说了,这个是最最最基本的命名规范。
之后,问题来了
很多业务词语我不知道英文怎么拼怎么办?
统一走相同的翻译平台。讲道理,谷歌翻译跟百度翻译,翻译一个单词不一定一样。
之后,问题又来了。
变量名拼接过长,按什么顺序拼?
这个问题我也是前一段时间看过一种思路,按照英语课本上的来。统一走英文语法,动词、名词、形容词。英文造句语法圈起来重点考。
比如说有个方法叫“坐火车去拉萨的途中做一些事情”,我认为正确的:onTheWayToLhasaByTrainDoSomeThing(),常见的写法:ByTrainToLhasaOnTheWayDoSomeThing() -- 途中坐火车去拉萨做一些事情。语法还是要注意一下的,否则上面这就变成两个方法了
1、组件细化
1、组件不超过250行
经常看到某个项目中组件一打开,1000+行,维护性、可继承性都很差,打开之后一脸懵逼。大多数情况下(非业务需要)超过250行的组件都可以拆分成更小的组件来维护。当你把所有组件都拆完了,你会拆出很多纯组件-不掺杂业务的组件,这是就可以进行公共组件抽象提取,你会发现有很多可以提取的公共组件。
2、全局样式污染问题优化
当组件抽象够多,拆分够细后,注意一下样式污染问题,我接触的项目直接走style hash时候居多,但这里推荐classnames插件,拼接业务唯一标识到className前面,这样比直接用hash更好调试,并且每个组件就算格式一样 className 起名字一样也不会混淆。
使用方式:
npm i classnames --save
设置公共方法
3、渲染次数优化
这个问题我在《跟大家聊一下前端性能怎么优化》那篇文章中提到过,在目录 四-2。
问题的解决方法在于合理触发render。
2、 数据抽象-逻辑解耦
这两个词语有些官方了,大概的意思为‘拆’。拆完再合并。
上面说了组件抽象的时候我们规定250行左右。方法定制在100行。相信大家也总会见到很多庞大的方法,这种方法仔细分析的话一定是掺杂了业务在里面,并没有把单独逻辑与业务分开来维护,使得这种方法即使写了备注,一动则牵引全身,修复完一个问题,出来10个问题,这就很恐怖了。
所以我们规定方法不许超过100行,如果你的方法超过100行,就说明可以拆分成两个或几个更小的逻辑的组合。
这种称之为逻辑解耦,我们拆完之后会发现很多的逻辑其实是一样的,这时候就可以进行数据抽象,提取公共方法,沉淀成公共方法库,编写好备注,使用文档。我们就可以很好的进行以后的维护,继承,修改等等工作。很久以前这种方法库我都是放u盘里随身携带...
这里重点:jsinspect,上述中的组件抽象及逻辑抽象都可通过此插件来整理,设定好排查路径,则会直接生成一个文件列表,告诉你哪里和哪里是相似的可以抽象,非常好用。
3、 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,一劳永逸。
4、 所有节点需有唯一识别key
这一点来说也是蛮重要的,现在无论react,vue,angular,都是组件化开发模式,在这种模式下,底层原理都是构造虚拟树的diff算法,用来判断哪些组件重绘,哪些不用重绘。
通常的DOM元素的key是自动生成的。然而,在什么时候会有问题呢?举个例子
我需要渲染一万条数据,后台没返回唯一识别id,用角标代替
那么:如果key是唯一的
5、 prettier
此插件用来格式化代码,使代码哪怕在开发的时候格式混乱,是吧,编译一下,就会变成统一格式。非常适合团队开发使用。
这个时候有些同学可能会有个疑问,我的开发工具,比如vscode,可以下载开发工具插件,如图。
开发工具中也可以装一些插件辅助你开发,但是这个,只能辅助你自己,如果你的同事没有装,或者装了跟你配置的不一样,那么就非常不理想了,所以说,还是在项目中配置eslint,prettier等规范为上策。
四、Git角度
1、precommit
通过git precommit钩子,每个人在上传代码的时候做一层拦截,保证上传到gitlab上的代码质量。
这里话不多说,大家看完package.json配置就懂了
直接按照我这样配置好就可以了,每次上传代码的时候都会走一遍上述所说的eslint、stylelint、prettier等规范。当然也可以自定义一些操作。
2、merge request
锁定master分支,其余代码想合并到master 的时候,需要提交merge request,然后需要进行代码评审,至少两个人,通过评审才可以将代码合并到master分支。我们的大型项目都是这种模式,十分严谨。大家还可以项目学习写法,探讨思路,此功能gitlab自带,配置一下就好,有需要的可以去了解一波。
五、编辑器角度
这一点来说,项目中可以统一开发工具的配置,文件名为.editorconfig的根目录配置。
我们通过.editorcofig文件可以统一开发工具的配置环境,就算你的同事用的subline,你用的vscode 也不会影响代码风格,规则等问题。
我这边也直接给出一个配置文件。
END
上周很忙,手里同时三个项目,真是在抽时间写文章,写文章真的没那么简单,对于一些东西的串联的时候才发现自己不足的地方很多,多谢各位包容,如果有错误欢迎大家指出。这周的任务虽然还是很紧,我还是会完成我的承诺。不辜负我的28个关注人。我去改bug了,下次见。
我这边3月底之前会写4篇文章,分别为
《前端性能优化交流》
《前端代码质量优化交流》(本篇)
《前端code监控交流》
《前端安全问题交流》
沉淀一下去年在开发流程方面的一些知识。 谢谢各位。