Copy/Paste 是一个非常有效的开发方式，但是它们一点儿也不适合维护——为了改一个拼写错误，要去修改代码中的七八个文件，打人的心都有了。

如果万一我们是要替换这七八个文件的相应代码，那么就会更加地痛苦。在后端里，我们只需要修改相应的 Java、Go、JavaScript、Python 等语言相关文件的代码。而在前端我们需要修改 HTML/JavaScript/CSS 文件，而哪怕使用的 React 这样的框架里，我们也要修改一个文件的多个地方。

于是乎，作为一个专业的程序员，我们都在不断地寻找方式来复用代码（PS：复制/粘贴从本质上也是一种复用）。

经验总结的复用

经验总结型复用，指的是结合组织和项目的经验，提取出其中的共同部分，以便于在其它项目中继续使用。事实上，所有类型的复用都是经验型复用。因此，这里的经验总结型复用，专指于用在组织内部的复用。从我的认识来看，有以下四类：

• 脚手架

• 组件库

• 模式库

• 模板和模板应用

脚手架

脚手架是一种快速创建新应用的方式。在脚手架里，我们会总结出过往经验中的模式、代码，将这些模式和代码融入我们其中。其中特色就是结合常用的各种框架，并将它们结合到一起，如后端的：Spring Boot + Spring Eureka + Feign + Zuul 等，如前端的 React + Redux + React Router 等（PS：Angular 就没这么复杂）。

市面上的主流框架，本身是提供了相应的脚手架功能。基于此，脚手架可以分为两类：

• 框架官方脚手架。诸如 Spring 官方的 Spring Initializr 便是一个快速的生成脚手架的方式。

• 自制脚手架。在框架官方脚手架的基础上，加上部署、模式库等相关的部分。

两者都有各自的优缺点。框架官方的脚手架缺少一些团队、组织特定的因素。而自制的脚手架则需要团队长期维护。不过，出于种种原因（诸如 KPI），我们都会维护自己的脚手架，你说呢？

组件库（客户端）

组件库，对于每个 Web 项目来说，都是必不可少的元素。它适用于客户端开发的 UI 复用。组件库本身分为三个层级：基础 UI 组件、复合组件、业务组件 。

• 基础 UI 组件。最小化的组件，它们不依赖于其它组件。

• 复合组件。由多个基础组件组成的组件，它们依赖于现有的组件。

• 业务组件。带有业务功能的大量重复使用的组件。

一般而言，我们会使用第三方的基础 UI 组件库。在那的基础之上，封装自己的业务组件库。又或者是，再对基础 UI 组件库进行二次封装，以降低对第三方组件库的依赖，让其变成可替换的组件库。

模式库

模式库其本质仍然是一个代码集，它将我们常用的代码提取出一个公共的类库中。按分类上来说，组件库也是模式库的一种。为了方便于服务端与客户端开发区别，我将组件库独立出来。

模式库，是出于共用的目的而提取出来的。在不同的项目中，它的表现形式略有差异：

• Git Submodule。即将公用的函数放到一个 Git Submodule 中，让多个项目可以同时使用。

• 依赖包。即将依赖打包成库，使用时只需要引入依赖即可。

两种方式也是各有优缺点。前者维护容易出错，后者更新不方便。

模板和模板应用

组件库和模板，实质上是设计系统的一部分。设计系统是一组相互关联的设计模式与共同实践的，以连贯组织来达成数字产品的目的。它包含了以下的五部分：

• 原子，即是事物的基本组成部分。它是最小的单元，不能再往下细分，也就是基本的 HTML 标签，诸如表单标签，输入，按钮。

• 分子，即由原子聚合而成的粒子。在 UI 设计中，分子是由几个基本的 HTML 标签组成的简单组织。

• 有机体，是由分子或原子或其它有机体组成的相对复杂的 UI 组分 。它用于创建一些独立、可复用的内容，诸如 header。

• 模板，顾名思义就是整合前面的元素，构建整体的布局。诸如一个博客包含了 header、footer 及博客本身的内部。

• 页面，将实际内容（图片、文章等）套件在特定模板，页面是模板的具体实例。

而模板应用，则是在模板的基础上，进一步地整合而成，用于帮助开发人员快速的构建某一类型的应用。对应于其它类型的应用而言，则要判断是否会出现相似的应用。

工具

上述的四种方式，是比较常见的方式。而随着，我们项目数量的变多，开发人员数量的膨胀，它们开始变得麻烦。我们便需要编写一些工具，以节省大量的人力成本。

CLI

这里的 CLI 是指自制的 CLI，它与我们编写的一系列自动化代码工具相互配合，形成自己的解决方案。

• 下载脚手架

• 配置、安装依赖

• 集成组件库

• 配置自动化部署脚本

其交互诸如于：

choices: [ "React", "Angular", "Vue"]	
[?] What Framework do you want to do?	> React	Angular	Vue

我们便可以将把配置、组件安装等一系列的工作自动化。

Schematics

Schematics 来自于 Angular 团队，其本质上也是 CLI 的一种，只是它相对于 CLI 来说，编程起来更加的简单。它将我们在编程 CLI 过程中的一些通用模式，整合出来融入了代码中。换句话来说，它相当于是前端工具中的 Angular、React——只需要编写业务逻辑，而不需要关注于基础架构。

它是现代 Web 的工作流程工具； 它可以将修改应用于您的项目，例如创建新组件或更新代码以修复依赖项中的重大变更（PS：有点类似于后端数据库脚本的味道）。还可以向现有项目添加新的配置选项或框架。

编程器插件

编程器插件，是一个非常有意思的思路。我们可以编写一个编辑器插件，在插件中加入我们常见的代码、模式和模板等。如在 VS Code 中，我们只需要创建对应的：

• snippets，即代码段。定义好一个预填充的代码段，而后只需要输入关键词即可，诸如 ullist 可以直接生成对应的列表代码。它可以用在各个语言中，只需要我们 registerCompletionItemProvider。

• Typings，用于提供智能感知。写好 API 相关 Interface 及其文档，就可以在开发人员输入的时候，自动提醒他/她们相关的可用参数及参数的用法，并自动完成一小部分的代码（预定义的感知部分）。对于我们来说，唯一需要做的是写好 API 文档即可。

就此可以用于代码生成和智能感知。对于一个框架来说，我们只需要定制好框架相应的组件、模式代码，就可以复用它们。

PS：我最近在玩这个。

设计系统与代码生成

当我们有了一个成体系的设计系统，就可以使用诸如 Storybook 这样的框架来优化组件的使用。它可以让我们在查看组件文档的同时，配置上相应的组件参数，最后我们只需要复制结果代码，到我们的工程中使用即可。

其与一般的组件库使用相比，更加的轻便，易于使用。

下一步，我们就是等 AI 来生成代码了。对于拥有设计系统的项目而言，我们可以直接通过类似于 Sketch2Code 的工具，直接将我们的设计转换为代码。但是，实质上这是一种更复杂的模式。对于拥有设计系统的项目来说，我们可以将设计转换为元数据。

结论

降低程序员的代码量，就是效率的提升。