前言
在 20 世纪 60 年代,计算机技术开始超过软件编程的速度。计算机变得更快、更便宜,但是软件开发仍然缓慢,难以维护,并且容易出错。这种差距,以及如何应对,被称为“软件危机”。1968 年,在北约软件工程会议上,Douglas McIlroy 提出了基于组件的开发作为解决这一困境的可能方法。基于组件的开发提供了一种通过使代码可重用来加快编程潜力的方法,从而使其更高效且更易于扩展。这降低了工作量,提高了软件开发的速度,使软件能够更好地利用现代计算机的力量。
现在,50 年后,我们正经历着类似的挑战,但这次是在设计方面。设计正在努力扩展它所支持的应用程序,因为设计仍然是针对单个问题的定制解决方案。你是否曾经执行过用户界面审计,发现你使用了几十种相似的蓝色色调,或者相同按钮的排列?将其乘以应用程序中的每个 UI,您就会开始意识到设计变得多么不一致、不完整和难以维护。
设计系统通过使设计可重复使用,使团队能够更快地制造更好的产品成为可能。这是设计系统的核心和主要价值。设计系统是可重用组件的集合,遵循明确的标准,可以将其组装在一起以构建任意数量的应用程序。
GrowingIO 产品研发团队也开始通过搭建自己的设计系统—— GrowingIO Design System,来提供交互体验一致的产品和提升研发效率。组件库做为设计系统的重要组成部分,前端团队通过系列文章来介绍如何一步步搭建组件库。本篇文章主要介绍组件库 GrowingIO Design 使用的开发工具,正所谓:工欲善其事,必先利其器。
TL;DR
本文按照工具的作用把工具分为:代码规范和代码管理两类,这两类主要用到的工具有:
1. 代码规范工具
a. Prettier:用于代码格式化
b. stylelint:对样式文件( CSS 和 Less )进行规范检查
c. ESLint:对ECMAScript/JavaScript 代码进行规范检查
2. 代码管理工具
a. Commitzen:帮助编写规范的 commit message
b. commitlint:对 commit message 格式进行检查
c. lint-stage:只对 git 缓存的代码文件进行规范检查,提高速度
d. husky:整合所有的检查工具
husky 如何把检查工具都整合的,如下图所示:
其中:
- pre-commit 阶段:执行 lint-staged ,会对暂存的文件执行 prettier 、stylelint 和 eslint 三个命令。
- commit-msg 阶段:执行 commitlint,检查 commit message 是否符合规范。
接下来,对这两类用到的工具进行详细介绍。
代码规范工具
代码规范相当于团队乃至公司的整个技术团队协作的契约,同时这些规范是经过许多项目实践出来的宝贵经验,可以在开发中少走很多的弯路。代码规范性靠人工在 Code Review 时候检查太费时费力,所以主要用工具来保障。这里主要使用的是 Prettier 、stylelint 和 ESLint 三个工具。