timewilltell

timewilltell 查看完整档案

武汉编辑华中科技大学  |  控制工程 编辑网易考拉  |  前端实习 编辑 wfy.netlify.com/ 编辑
编辑

本人方向为前端,从八月份准备到九月份面试到十月份拿到满意的offer,前前后后大概两个月,期间面试了很多互联网公司,在面试中发现基础占了80%,项目和其他占了20%,现在面试结束了,想系统的把前端常见的面试问题整理一下,主要分为计算机网络与HTTP,HTML5,CSS3,算法,其他面试遇到的问题这几个类别,方便自己以后查阅复习也可以给别人参考,还没有写完,目前正在补充中,地址:https://github.com/wangfengyu...

个人动态

timewilltell 收藏了文章 · 2019-09-20

用 husky 和 lint-staged 构建超溜的代码检查工作流

具备基本工程素养的同学都会注重编码规范,而代码风格检查(Code Linting,简称 Lint)是保障代码规范一致性的重要手段,你的工作流中有 Lint 环节么?有的话你用的爽么?你在团队中推广过 Lint,但是大家都不买账?究竟是为啥?

Lint 是什么?

探讨怎么做之前,我们很有必要给 Lint 来个清晰、准确的定义,wikipedia 的定义如下:

In computer programming, lint is a Unix utility that flags some suspicious and non-portable constructs (likely to be bugs) in C language source code; generically, lint or a linter is any tool that flags suspicious usage in software written in any computer language. The term lint-like behavior is sometimes applied to the process of flagging suspicious language usage. Lint-like tools generally perform static analysis of source code.

简单来说,Lint 就是对代码做静态分析,并试图找出潜在问题的工具,实战中我们也用 Lint 来指使用工具的过程。

为什么要 Lint?

使用 Lint 会有什么好处呢?在我看来至少具有如下 3 点:

  • 更少的 Bug,剑桥大学的研究发现,全世界每年因为软 Bug 造成的经济损失约 3120 亿美金;

  • 更高的开发效率,工程师平均会花掉 50% 的工作时间定位和解决各种 Bug,其中不乏那些显而易见的低级错误,而 Lint 很容易发现低级的、显而易见的错误;

  • 更高的可读性,代码可读性的首要因子是“表面文章”,表面上看起来乱糟糟的代码通常更难读懂;

可以毫不客气的说,如果你不做 Lint,就是在浪费自己的时间,浪费公司的资源。既然做 Lint 的预期效果很好?该怎么做呢?

提交后 Lint:反馈链条太长?

说到怎么做,多数人会自然而然的想到各种 Lint 工具,目前社区中针对各种语言都开发了 Lint 工具,前端能用到的就有大把:ESLintStandardSCSSLintJSONLintHTMLHint 等。GitHub 官方出品的 Lint 工具列表 也是个非常不错的参考。

很多同学选择在持续集成阶段(后文用 CI 代称)做 Lint,比如使用远程的 Git Hooks 来触发。但是从实际的经历来看,这种做法的反馈链条通常如下:

代码提交 --> 发现问题(远程) --> 修复问题 --> 重新提交 --> 通过检查(远程)

整个过程可能会浪费掉你不少时间,毕竟 CI 过程通常不仅是在做 Lint,如果你是那种不知道自己时间每天都去哪儿了的工程师,可以反思下自己或者团队的工作流是否是这样。并且,请相信我,你不是少数人。

你有没有这样的经历:吭哧吭哧写了几天代码,各种验收都通过了,最后被 CI 拒绝,竟是因为你的代码中少加了一个逗号,这时候心情简直崩溃到无法形容:

从 GitHub 上各种修复 Lint 的提交数量不难发现工程师在修复 Lint 问题上浪费的时间,比如搜索 "fix lint",多达 45W 次提交:

再比如搜索 “fix indent”,多达 226W 次提交,是不是很触目惊心?

只在 CI 流程做 Lint 的缺点也是显而易见的:

  • Lint 在整个开发工作流中的反馈链条太长,浪费时间、注意力和资源,最致命的;

  • CI 流程搭建成本比较高,即使有各种 CI 服务,步骤也还是比较繁琐;

我们该怎么改进?

提交前 Lint:错误信息不相关?

为了缩短 Lint 的反馈链条,把 Lint 挪到本地是最有效的办法。常见做法是使用 husky 或者 pre-commit 在本地提交之前做 Lint。

使用 husky 的具体做法如下:

首先,安装依赖:

npm install -D husky
yarn add --dev husky

然后修改 package.json,增加配置:

{
  "scripts": {
    "precommit": "eslint src/**/*.js"
  }
}

最后尝试 Git 提交,你就会很快收到反馈:

git commit -m "Keep calm and commit"

但是在遗留代码仓库上工作的同学很快会遇到新的问题,开启 Lint 初期,你可能会面临成千上万的 Lint Error 需要修复。部分同学对下面这个图可能并不陌生:只改了文件 A,但是文件 B、C、D 中也有大量错误。

把整个仓库都格式化不失为一种选择,但是实际上需要很大的勇气。多数人在项目中运用新工具都希望是渐进式的,而不是推到重来式的,因为相比而言,业务系统稳定是更重要的事情。简单的把 Lint 挪到本地,反馈链条是缩短了,但是面对每次改动,工具还是给出了太多不相关的信息,这无疑与小步快跑的互联网节奏是相违背的。

该怎么破?

只 Lint 改动的:66666

如果把 Lint 挪到本地,并且每次提交只检查本次提交所修改的文件,上面的痛点就都解决了。Feedly 的工程师 Andrey Okonetchnikov 开发的 lint-staged 就是基于这个想法,其中 staged 是 Git 里面的概念,指待提交区,使用 git commit -a,或者先 git add 然后 git commit 的时候,你的修改代码都会经过待提交区。

lint-staged 用法如下:

首先,安装依赖:

npm install -D lint-staged
yarn add --dev lint-staged

然后,修改 package.json 配置:

{
  "scripts": {
    "precommit": "lint-staged"
  },
  "lint-staged": {
    "src/**/*.js": "eslint"
  }
}

最后,尝试提交的效果:

实际上,lint-staged 给了你提交前代码操作的更大自由度,比如使用下面的配置,自动修复错误:

{
  "scripts": {
    "precommit": "lint-staged"
  },
  "lint-staged": {
    "src/**/*.js": ["eslint --fix", "git add"]
  }
}

或者使用下面的配置,自动格式化代码(谨慎使用):

{
  "scripts": {
    "precommit": "lint-staged"
  },
  "lint-staged": {
    "src/**/*.js": ["prettier --write", "git add"]
  }
}

此外,lint-staged 和 prettier 已经集成到 create-react-app 中了。你是不是也应该好好打磨下自己的 Lint 工作流了?

总结

有人说前端攻城狮是世界上最奇怪的动物,提交代码时用 prettier 把代码排版的很美观,但部署上线时又使用 uglify 把代码压缩的连亲妈都不认了,事实是,如果我们写出来的代码本来就很丑陋,就根本不需要用 uglify。希望读到这里的你能把 Lint 工作流打磨到极致,把更多时间专注在解决真正的问题上,成为真正高效的工程师。

One More Thing

本文作者王仕军,商业转载请联系作者获得授权,非商业转载请注明出处。如果你觉得本文对你有帮助,请点赞!如果对文中的内容有任何疑问,欢迎留言讨论。想知道我接下来会写些什么?欢迎订阅我的掘金专栏知乎专栏:《前端周刊:让你在前端领域跟上时代的脚步》。

查看原文

timewilltell 赞了文章 · 2019-09-20

用 husky 和 lint-staged 构建超溜的代码检查工作流

具备基本工程素养的同学都会注重编码规范,而代码风格检查(Code Linting,简称 Lint)是保障代码规范一致性的重要手段,你的工作流中有 Lint 环节么?有的话你用的爽么?你在团队中推广过 Lint,但是大家都不买账?究竟是为啥?

Lint 是什么?

探讨怎么做之前,我们很有必要给 Lint 来个清晰、准确的定义,wikipedia 的定义如下:

In computer programming, lint is a Unix utility that flags some suspicious and non-portable constructs (likely to be bugs) in C language source code; generically, lint or a linter is any tool that flags suspicious usage in software written in any computer language. The term lint-like behavior is sometimes applied to the process of flagging suspicious language usage. Lint-like tools generally perform static analysis of source code.

简单来说,Lint 就是对代码做静态分析,并试图找出潜在问题的工具,实战中我们也用 Lint 来指使用工具的过程。

为什么要 Lint?

使用 Lint 会有什么好处呢?在我看来至少具有如下 3 点:

  • 更少的 Bug,剑桥大学的研究发现,全世界每年因为软 Bug 造成的经济损失约 3120 亿美金;

  • 更高的开发效率,工程师平均会花掉 50% 的工作时间定位和解决各种 Bug,其中不乏那些显而易见的低级错误,而 Lint 很容易发现低级的、显而易见的错误;

  • 更高的可读性,代码可读性的首要因子是“表面文章”,表面上看起来乱糟糟的代码通常更难读懂;

可以毫不客气的说,如果你不做 Lint,就是在浪费自己的时间,浪费公司的资源。既然做 Lint 的预期效果很好?该怎么做呢?

提交后 Lint:反馈链条太长?

说到怎么做,多数人会自然而然的想到各种 Lint 工具,目前社区中针对各种语言都开发了 Lint 工具,前端能用到的就有大把:ESLintStandardSCSSLintJSONLintHTMLHint 等。GitHub 官方出品的 Lint 工具列表 也是个非常不错的参考。

很多同学选择在持续集成阶段(后文用 CI 代称)做 Lint,比如使用远程的 Git Hooks 来触发。但是从实际的经历来看,这种做法的反馈链条通常如下:

代码提交 --> 发现问题(远程) --> 修复问题 --> 重新提交 --> 通过检查(远程)

整个过程可能会浪费掉你不少时间,毕竟 CI 过程通常不仅是在做 Lint,如果你是那种不知道自己时间每天都去哪儿了的工程师,可以反思下自己或者团队的工作流是否是这样。并且,请相信我,你不是少数人。

你有没有这样的经历:吭哧吭哧写了几天代码,各种验收都通过了,最后被 CI 拒绝,竟是因为你的代码中少加了一个逗号,这时候心情简直崩溃到无法形容:

从 GitHub 上各种修复 Lint 的提交数量不难发现工程师在修复 Lint 问题上浪费的时间,比如搜索 "fix lint",多达 45W 次提交:

再比如搜索 “fix indent”,多达 226W 次提交,是不是很触目惊心?

只在 CI 流程做 Lint 的缺点也是显而易见的:

  • Lint 在整个开发工作流中的反馈链条太长,浪费时间、注意力和资源,最致命的;

  • CI 流程搭建成本比较高,即使有各种 CI 服务,步骤也还是比较繁琐;

我们该怎么改进?

提交前 Lint:错误信息不相关?

为了缩短 Lint 的反馈链条,把 Lint 挪到本地是最有效的办法。常见做法是使用 husky 或者 pre-commit 在本地提交之前做 Lint。

使用 husky 的具体做法如下:

首先,安装依赖:

npm install -D husky
yarn add --dev husky

然后修改 package.json,增加配置:

{
  "scripts": {
    "precommit": "eslint src/**/*.js"
  }
}

最后尝试 Git 提交,你就会很快收到反馈:

git commit -m "Keep calm and commit"

但是在遗留代码仓库上工作的同学很快会遇到新的问题,开启 Lint 初期,你可能会面临成千上万的 Lint Error 需要修复。部分同学对下面这个图可能并不陌生:只改了文件 A,但是文件 B、C、D 中也有大量错误。

把整个仓库都格式化不失为一种选择,但是实际上需要很大的勇气。多数人在项目中运用新工具都希望是渐进式的,而不是推到重来式的,因为相比而言,业务系统稳定是更重要的事情。简单的把 Lint 挪到本地,反馈链条是缩短了,但是面对每次改动,工具还是给出了太多不相关的信息,这无疑与小步快跑的互联网节奏是相违背的。

该怎么破?

只 Lint 改动的:66666

如果把 Lint 挪到本地,并且每次提交只检查本次提交所修改的文件,上面的痛点就都解决了。Feedly 的工程师 Andrey Okonetchnikov 开发的 lint-staged 就是基于这个想法,其中 staged 是 Git 里面的概念,指待提交区,使用 git commit -a,或者先 git add 然后 git commit 的时候,你的修改代码都会经过待提交区。

lint-staged 用法如下:

首先,安装依赖:

npm install -D lint-staged
yarn add --dev lint-staged

然后,修改 package.json 配置:

{
  "scripts": {
    "precommit": "lint-staged"
  },
  "lint-staged": {
    "src/**/*.js": "eslint"
  }
}

最后,尝试提交的效果:

实际上,lint-staged 给了你提交前代码操作的更大自由度,比如使用下面的配置,自动修复错误:

{
  "scripts": {
    "precommit": "lint-staged"
  },
  "lint-staged": {
    "src/**/*.js": ["eslint --fix", "git add"]
  }
}

或者使用下面的配置,自动格式化代码(谨慎使用):

{
  "scripts": {
    "precommit": "lint-staged"
  },
  "lint-staged": {
    "src/**/*.js": ["prettier --write", "git add"]
  }
}

此外,lint-staged 和 prettier 已经集成到 create-react-app 中了。你是不是也应该好好打磨下自己的 Lint 工作流了?

总结

有人说前端攻城狮是世界上最奇怪的动物,提交代码时用 prettier 把代码排版的很美观,但部署上线时又使用 uglify 把代码压缩的连亲妈都不认了,事实是,如果我们写出来的代码本来就很丑陋,就根本不需要用 uglify。希望读到这里的你能把 Lint 工作流打磨到极致,把更多时间专注在解决真正的问题上,成为真正高效的工程师。

One More Thing

本文作者王仕军,商业转载请联系作者获得授权,非商业转载请注明出处。如果你觉得本文对你有帮助,请点赞!如果对文中的内容有任何疑问,欢迎留言讨论。想知道我接下来会写些什么?欢迎订阅我的掘金专栏知乎专栏:《前端周刊:让你在前端领域跟上时代的脚步》。

查看原文

赞 98 收藏 67 评论 8

timewilltell 收藏了文章 · 2019-08-15

针对Vue的后台权限功能实现思路(持续更新)

权限是一块设计挺繁琐的功能,尤其是设计到前端SPA应用,前后端的耦合性太强,先屡屡思路,再实现,如果您有好的建议,也可评论留言。

基本的表结构如下

用户表。user

字段说明
id用户ID
username用户名

示例

idusername
1赛冷思

原文在我博客


前端路由表。routes

字段说明
id路由自增ID
pid父级路由ID,默认根路由为0
path方便操作无线分类的关键字段,后面再说
web_pata前端路由路径,注意:为方便各种SPA,前后不带斜杠,交给前端自己处理即可
name路由名称
desc路由描述
sort排序,例如同一级路由,可按此字段排序,这个排序结果将会在前端菜单中提现
extra拓展信息,格式为JSON字符串,例如vue-router中的meta信息

有几项需要注意:

  1. 添加功能尽量让前端开发者填写,你懂得
  2. 修改时,前端一定要知道,你懂得
  3. 删除时,前端一定要知道,你懂得

切记,这些东西都是跟前端相关联。。。

示例

idpidpathweb_pathnamedescsortextra
100,manager内容管理管理内容的路由1{}
210,1,article文章管理文章管理1{}
320,1,2,list文章列表查看文章列表页面1{}
420,1,2,view文章详情查看文章详情页面1{}
520,1,2,edit添加/修改文章添加和修改文章公用页面1{"test":"article-edit"}
610,1,mind随笔管理随笔管理1{}
760,1,6,list随笔列表查看随笔列表页面1{}
860,1,6,view随笔详情查看随笔详情页面1{}
960,1,6,edit添加/修改随笔添加和修改随笔公用页面1{"test":"mind-edit"}

注意:给用户选择路由时,如果选择的是最底层的路由,那么从它自身到最顶层父级,都应该被选择,例如选择文章列表,那么文章管理和内容管理都应该被选中。同样,如果选择的不是最底层的,那么所有的子级应该被选中,不再细说。

解释一下关键字段

  • pid 父级ID,根级ID为0,没啥说
  • path 默认为"0,",意思就把当前数据,从最顶层的父级pid到自身的pid,用英文","链接起来,最后要加个逗号

例如,文章管理自己的pid为1,它得父级内容管理的pid是0,所以文章管理的path就是"0,1,",一次类推就行

  • extra 前端路由的拓展信息

用户路由关联表。user_routes

字段说明
id自身自增ID
user_id用户ID
route_id路由ID
extra拓展信息,格式为JSON字符串,例如vue-router中的meta信息,此拓展在将会和routes表extra合并,可以通过这个字段细粒度控制路由中的小操作

示例

iduser_idroute_idextra
111{}
212{}
316{}
413{}
514{}
619{"add":true,"update":false}

通过示例可以看出,该用户拥有的路由其实就三个页面,分别是:文章列表,文章查看和添加/修改随笔,注意:添加/修改随笔extra里面设置了,add为true,update为false,意思是,只能添加,不能修改,前端可以在用户进入这个页面的时候,通过这个信息来决定到底能干啥,从而也就实现了细粒度控制每个页面的具体操作。

最终给前端返回的数据格式如下:

{
    id:1,
    username:'赛冷思',
    routes:[
        {
            id:1,
            web_path:'manager',
            name:'内容管理',
            extra:{},
            ...其他字段
            children:[
                {
                    id:2,
                    web_path:'article',
                    name:'文章管理',
                    extra:{},
                    children:[
                        {
                            id:3,
                            web_path:'list',
                            name:'文章列表',
                            extra:{},
                        },
                        {
                            id:4,
                            web_path:'view',
                            name:'文章详情',
                            extra:{},
                        }
                    ]
                },
                {
                    {
                        id:6,
                        web_path:'mind',
                        name:'随笔管理',
                        extra:{},
                        children:[
                            {
                                id:9,
                                web_path:'view',
                                name:'添加/修改随笔',
                                extra:{
                                    test:'mind-edit',
                                    add:true,
                                    update:false
                                }
                            }
                        ]
                    }
                }
            ]
        }
    ]
}

大致思路就是这样,回头在实现的过程中发现不完善的,将会持续更新。

最新更新在我的博客:https://sailengsi.com/article/15

查看原文

timewilltell 赞了文章 · 2019-08-15

针对Vue的后台权限功能实现思路(持续更新)

权限是一块设计挺繁琐的功能,尤其是设计到前端SPA应用,前后端的耦合性太强,先屡屡思路,再实现,如果您有好的建议,也可评论留言。

基本的表结构如下

用户表。user

字段说明
id用户ID
username用户名

示例

idusername
1赛冷思

原文在我博客


前端路由表。routes

字段说明
id路由自增ID
pid父级路由ID,默认根路由为0
path方便操作无线分类的关键字段,后面再说
web_pata前端路由路径,注意:为方便各种SPA,前后不带斜杠,交给前端自己处理即可
name路由名称
desc路由描述
sort排序,例如同一级路由,可按此字段排序,这个排序结果将会在前端菜单中提现
extra拓展信息,格式为JSON字符串,例如vue-router中的meta信息

有几项需要注意:

  1. 添加功能尽量让前端开发者填写,你懂得
  2. 修改时,前端一定要知道,你懂得
  3. 删除时,前端一定要知道,你懂得

切记,这些东西都是跟前端相关联。。。

示例

idpidpathweb_pathnamedescsortextra
100,manager内容管理管理内容的路由1{}
210,1,article文章管理文章管理1{}
320,1,2,list文章列表查看文章列表页面1{}
420,1,2,view文章详情查看文章详情页面1{}
520,1,2,edit添加/修改文章添加和修改文章公用页面1{"test":"article-edit"}
610,1,mind随笔管理随笔管理1{}
760,1,6,list随笔列表查看随笔列表页面1{}
860,1,6,view随笔详情查看随笔详情页面1{}
960,1,6,edit添加/修改随笔添加和修改随笔公用页面1{"test":"mind-edit"}

注意:给用户选择路由时,如果选择的是最底层的路由,那么从它自身到最顶层父级,都应该被选择,例如选择文章列表,那么文章管理和内容管理都应该被选中。同样,如果选择的不是最底层的,那么所有的子级应该被选中,不再细说。

解释一下关键字段

  • pid 父级ID,根级ID为0,没啥说
  • path 默认为"0,",意思就把当前数据,从最顶层的父级pid到自身的pid,用英文","链接起来,最后要加个逗号

例如,文章管理自己的pid为1,它得父级内容管理的pid是0,所以文章管理的path就是"0,1,",一次类推就行

  • extra 前端路由的拓展信息

用户路由关联表。user_routes

字段说明
id自身自增ID
user_id用户ID
route_id路由ID
extra拓展信息,格式为JSON字符串,例如vue-router中的meta信息,此拓展在将会和routes表extra合并,可以通过这个字段细粒度控制路由中的小操作

示例

iduser_idroute_idextra
111{}
212{}
316{}
413{}
514{}
619{"add":true,"update":false}

通过示例可以看出,该用户拥有的路由其实就三个页面,分别是:文章列表,文章查看和添加/修改随笔,注意:添加/修改随笔extra里面设置了,add为true,update为false,意思是,只能添加,不能修改,前端可以在用户进入这个页面的时候,通过这个信息来决定到底能干啥,从而也就实现了细粒度控制每个页面的具体操作。

最终给前端返回的数据格式如下:

{
    id:1,
    username:'赛冷思',
    routes:[
        {
            id:1,
            web_path:'manager',
            name:'内容管理',
            extra:{},
            ...其他字段
            children:[
                {
                    id:2,
                    web_path:'article',
                    name:'文章管理',
                    extra:{},
                    children:[
                        {
                            id:3,
                            web_path:'list',
                            name:'文章列表',
                            extra:{},
                        },
                        {
                            id:4,
                            web_path:'view',
                            name:'文章详情',
                            extra:{},
                        }
                    ]
                },
                {
                    {
                        id:6,
                        web_path:'mind',
                        name:'随笔管理',
                        extra:{},
                        children:[
                            {
                                id:9,
                                web_path:'view',
                                name:'添加/修改随笔',
                                extra:{
                                    test:'mind-edit',
                                    add:true,
                                    update:false
                                }
                            }
                        ]
                    }
                }
            ]
        }
    ]
}

大致思路就是这样,回头在实现的过程中发现不完善的,将会持续更新。

最新更新在我的博客:https://sailengsi.com/article/15

查看原文

赞 4 收藏 5 评论 0

timewilltell 关注了用户 · 2018-11-16

创宇前端 @knownsecfed

知道创宇前端团队(KnownsecFED)
微信公众号:创宇前端 | 最酷开发者的技术分享

关注 1223

timewilltell 关注了用户 · 2018-11-16

撒网要见鱼 @dailc

你才25岁,你可以成为任何你想成为的人。

关注 4969

timewilltell 关注了用户 · 2018-11-16

努力更好 @xieguoliang

加油

关注 1221

timewilltell 关注了用户 · 2018-11-16

senntyou @senntyou

达则兼济天下,穷则独善其身。

关注 4260

timewilltell 关注了用户 · 2018-11-16

程序员阿宇 @chengxuyuanayu

前端学习交流群:784783012 欢迎新手,进阶者
项目实战视频分享

关注 736

timewilltell 关注了用户 · 2018-11-16

Raymond @_raymond

靠谱接单

app/小程序/pc/移动端wap/h5/浏览器扩展(插件)/php/python/nodejs/elctron 皆可

联系我 : try-raymond@foxmail.com

关注 277

认证与成就

  • 获得 20 次点赞
  • 获得 2 枚徽章 获得 0 枚金徽章, 获得 0 枚银徽章, 获得 2 枚铜徽章

擅长技能
编辑

开源项目 & 著作
编辑

(゚∀゚ )
暂时没有

注册于 2018-07-20
个人主页被 431 人浏览