抱歉,你查看的文章不存在

代码复用到低代码(上):提升开发效率的 7~8 种方式

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

结论

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

原文发布于微信公众号 - phodal(phodal-weixin)

原文发表时间:2019-03-25

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

编辑于

phodal

144 篇文章57 人订阅

扫码关注云+社区