前端工程化的个人思考(续)

栏目: 编程工具 · 发布时间: 5年前

内容简介:(题图:from  unsplash)有朋友问最近看的哪两本关于前端的书籍——《前端架构设计》+《前端工程化:体系设计与实践》,一本重道,一本重术,道与术结合更具指导意义。希望了解前端的朋友推荐看一下。

前端工程化的个人思考(续)

(题图:from  unsplash)

有朋友问最近看的哪两本关于前端的书籍——《前端架构设计》+《前端工程化:体系设计与实践》,一本重道,一本重术,道与术结合更具指导意义。希望了解前端的朋友推荐看一下。

接着上篇未完的话题,《前端工程化的个人思考》,前端工程化很庞大,涉及的点也比较多,笔者也只是想到那里就写到那里,要讨论的朋友可在文末留言讨论。

规范检查

既然走工程化路线,代码规范刚首当其冲,但每个人的编码习惯各异,只能靠团队规范来大方向上求同存异,Java的规范是出了名的,规范检查插件、组件也是种类繁多。前端自然也会有对应的组件来解决前端代码的规范问题,如 jslinteslintstylelint 等,结合svn/git或构建编译 工具 来确保代码的规范性,应该也有详细的规范文档来约定。我比较喜欢用的工具组合是SonarQube+Jenkins,利用Jenkins进行持续集成构建的同时,进行规范检查,将结果输出到 SonarQube 中在页面上展现出来,当然这属于一种后置的检查,在本机开发构建时,就可以集成到构建工作包或IDE插件中进行检查。

前端测试

不少项目针对后端有严格的单元测试通过率、测试代码覆盖率、代码注释率等,但对前端要求比较少,这也从侧面说明前端测试不好做,特别是前端的自动化测试工作。如果是前后端兼顾的开发,你基本是不会想到给前端代码写单元测试的,因为后端的逻辑性更强,测试方便。如果你是专职做前端开发的,你应该想想有没有给你的前端代码做单元测试?我们总是习惯于在JS代码中加入 alertconsole ,刷新页面看看到底结果如何,一处又一处,一遍又一遍,直到随处可见的 alert / console 淹没在正常代码处理中。

不好做不代表不能做,具体到不同的技术栈,想必也有对应的测试工具来辅助大家进行测试,如 Vue 体系、 React 体系等等,算是有比较成熟的生态。也有独立的优秀三方测试框架,如 MochaKarma 等,结合断言库如 char.js没有写断言验证的单元测试都是耍流氓 ),集成到CI工具中,完成一个持续性的流程。

工作流

工程化做的比较好的当属Java,而前端前些年似乎不存在这个概念。虽然一部分人也在努力这么做,直到NodeJS的出现,才有了质的飞越。不但提升了前端在软件工程中的地位,也为一大批工具的出现奠定了基础。独立构建、独立部署、任务处理(编译、压缩、混淆、合并、解决依赖、文件hash)等工具的出现,将一个完整的工作流程串联起来,再结合CI/CD工具,可谓发挥出极大的威力,解放人力,提升生产力。特别是Jenkins新版本中 Pipeline 功能的提出,使工作流程配置更加流畅。

附:《前端架构设计》思维脑图总结图

前端工程化的个人思考(续)

写到这里,算是这段思考的一个完结,文中提到的点都比较数粗糙,后续还是要深入进去,毕竟觉知此事要躬行。

前端工程化的个人思考(续)

扩展阅读:

前端工程化的个人思考(续)

长按2秒,识别二维码,关注我。


以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

编译原理

编译原理

Alfred V.Aho、Jeffrey D.Ullman、Ravi Sethi / 李建中 / 机械工业出版社 / 2003-8 / 55.00元

《编译原理》作者Alfred V.Aho、Ravi Sethi和Jeffrey D.Ullman是世界著名的计算机 科学家,他们在计算机科学理论、数据库等很多领域都做出了杰出贡献。《编译原理》 是编译领域无可替代的经典著作,被广大计算机专业人士誉为“龙书”。《编译原理》一 直被世界各地的著名高等院校和科研机构(如贝尔实验室、哥伦比亚大学、普 林斯顿大学和斯坦福大学等)广泛用作本科生和研究生编译原理......一起来看看 《编译原理》 这本书的介绍吧!

HTML 编码/解码
HTML 编码/解码

HTML 编码/解码

MD5 加密
MD5 加密

MD5 加密工具

HEX CMYK 转换工具
HEX CMYK 转换工具

HEX CMYK 互转工具