36

【代码范式集】减少代码量的 7~8 种方式

 3 years ago
source link: http://www.phodal.com/blog/code-reuse/?amp%3Butm_medium=referral
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

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 的工具,直接将我们的设计转换为代码。但是,实质上这是一种更复杂的模式。对于拥有设计系统的项目来说,我们可以将设计转换为元数据。

结论

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


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK