我对开发流程及规范的一些见解
- 2020 年 3 月 9 日
- 筆記
前后台搭配的问题
作为前端,你应该经常会像后台要接口,没有后台提供的接口就没有数据,后面的一切都免谈,那么,接口从何而来:
- 是人肉问
- 是靠文档
我个人偏向于是靠文档,因为文档是会沉淀一些东西下来的,一个需求下来,肯定会沉淀不少的接口,作用是干嘛的,需要哪些参数,返回内容是什么,错误码有哪些,对应的错误消息时什么。后续有其他需求要用到上个需求的某个接口时,一目了然,省去了不少沟通成本。
反观,人肉问这种方式,时间久了,大家也不记得了,影响开发效率,而且后台同学每次解释一次,也很烦吧。而且,如果没有文档这种规范的化,A需求传的是参数x,B需求传的是参数y,新同学接手,或者你自己读代码,都不知道x,y的意义。
所以,对比一下两种方式的差距:
|
人肉问 |
文档 |
---|---|---|
效率 |
低下 |
高 |
规范 |
无 |
强 |
沉淀 |
无 |
有 |
新人接手 |
困难 |
容易 |
那么,有没有很好的文档管理平台呢?答案是有的 GitHub – YMFE/yapi: YApi 是一个可本地部署的、打通前后端及QA的、可视化的接口管理平台

看来这些前辈们应该是很早就经历过这样的痛苦,才有了这么一个工具,这个工具非常强大,不仅仅只有接口文档管理的功能,还有:
- mock数据
- 可视化
这是个工具,也可以说是一个服务,团队可以自己搭建一个这样的服务,那么,具体怎么玩,就请大家自己了解一下了,一旦文档规范了,想想效率是有多大的提升。
同样的道理,我觉得视觉管理也应该有一个规范;
这里我就直接案例这个工具了:蓝湖 - 高效的产品设计协作平台

讨论代码规范的问题
通常,我们不是一个人在完成一个项目,有合作嘛,有合作的地方就有江湖,有人喜欢缩进使用2个空格,而有人喜欢4个,有人if后面跟一个语句的时候不喜欢{},有人…
是的,这时候,应该考虑使用工具了规范化这个问题。
拿一个vue项目为例,通常,创建一个项目的化,加入eslint。

如果你做过web开发,还不了解eslint,建议你赶紧去学一下,先学先致富,早日摆脱痛苦。
因为引入eslint之后,代码不规范,编译就过不了了,这样就强制要求了大家写代码都按照规范来。
但是这样做,是不是会引起部分人极度不适呢?嗯,所以有些小伙伴在IDE中会关闭检查,我还是按照我的方式写,只是提交的时候,我们可以做一个commit hook,在提交之前给他lint一下,在才提交。
这个hook我就直接安利一个了:GitHub – okonet/lint-staged: ?? — Run linters on git staged files
简介非常有意思,别人shit污染了你的代码,当你git staged的时候触发自动修复,修复后才可以提交你的修复,如果没修复,不好意思,提交不了,你自己修复之后提交,你可以从这个描述中体会一些这个工具的作者曾经应该是经历过什么了。
最佳的
lint
规范流程就是推荐团队成员先在自己的编辑器中配置eslint
,在 webpack 中配置并开启eslint-loader
错误提示,这样平时写的时候编辑器就能帮你修正一些简单的格式错误,同时提醒你有哪些不符合lint
规范的的地方,并在命令行中提示你错误。这方面详细的内容见 ESLint。 > > 但这并不是强制的,有些团队成员或者说刚来的实习生没有在编辑器中配置或者无视命令行中提示的错误,这时候就需要配置pre-commit
这种强制性校验的东西,保证所有提交到远程仓库的内容都是符合团队规范的