软件可复用性演进之路

最新推荐文章于 2026-04-27 20:23:00 发布

原创最新推荐文章于 2026-04-27 20:23:00 发布 · 227 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#数据库 #大数据 #编程语言 #人工智能 #java

点击↑上方↑蓝色“编了个程”关注我~

这是Yasin的第 68 篇原创文章

Y说

今天去逛了西湖。七八月的天气很热，太阳有点大。我没有太阳伞，带了把雨伞，也能遮住一点阳光，算是给自己一点心理上的安慰，虽然手脚已经被晒得黢黑。

西湖的莲花开了，在阳光下骄傲地绽放着，这份美虽然短暂，但极致。有时候想想，很多人可能还活得不如一朵花。

走过断桥，两边都是湖水，中间翠绿的柳叶垂在干干净净的白堤上，宽阔的视野能够让人心情也变得好起来。路上行人不多，这个点来的大多数都是外地来的游客。想想他们可能不远千里来这里游玩，而自己坐个地铁就能欣赏到如此美景，竟然觉得有点满足~

背景

最近在负责迁移一个应用，从传统的代码开发模式迁移到公司内部的一个低码平台上。最近业界对无代码平台、低代码平台也有比较大的关注度。其实无论是传统的开发模式也好，无码平台、低码平台，以及各种IaaS, Saas, FaaS也好，都是在解决类似的问题：如何提升开发效率？

放在企业发展的层面来讲，就是如何降低开发成本？毕竟对于软件公司来说，人力成本是一个很大的支出，如果有什么方式能够降低开发成本，那省下来的就是真金白银的钱。

下面从软件的可复用性这个角度，来聊聊业界在软件在可复用性这条路上，都经历了什么。

复制大法

在很久很久以前，程序员是一种很稀少的职业。那个时候的网络也不像现在这么发达，也没有什么成熟的代码托管工具。一个程序的所有代码都需要自己设计、实现、编译、部署。

突然有一天，一个程序员发现，他在多个程序中需要写一些同样的，类似的代码。比如处理计算机的输入输出、给一个数组排序、取一个字符串的子串等等。这个时候他就会把自己之前写的代码复制一份，放到新的程序里，而不是从头一个个代码去敲。这大大节省了他的开发成本。

后来网络变得越来越方便，大家都把自己觉得写得不错的代码发布到网上，并说：我实现了一个xxx功能，大家可以复用这段代码。它可能在某个博客里，也可能在某个代码仓库里，甚至可能只是一个截图。

于是程序员们充分发挥了开源精神和拿来主义，使用复制/粘贴的功能到处借鉴代码，大大降低了开发一个程序的成本。这个优良的习惯一直延续至今，到现在仍然有大把的程序员面向搜索引擎编程，离开了搜索引擎就亮眼抓瞎。

三方库

复制代码会存在一个问题。第一个问题是如果程序太大，分成了多个文件，那copy也会变得比较麻烦；第二个问题是如果别人的代码有bug，或者有升级的新功能，可能感知不到，或者升级是比较困难的。

所以后面就发展出来了三方库和中央仓库。假如我开发了一些有用的程序，那我就把它们打包成一个三方库，并且注册推送到一个中央仓库。其他人如果要使用这部分代码，那就去中央仓库搜索，并下载到自己本地就行了，后续如果有版本更新了，他也在中央仓库能搜索到。这期间就衍生出了一系列的包管理工具，比如Java的maven、gradle，nodejs的npm，golang的gomod等等。

比如开源组织apache基于Java语言写了一个很有用的工具类，我们就可以直接使用这个库：

<dependency>
  <groupId>org.apache.commons</groupId>
  <artifactId>commons-lang3</artifactId>
  <version>3.12.0</version>
</dependency>

// 在代码中使用apache提供的StringUtils类
if (StringUtils.isBlank(token)) {
  return null;
}

有了这些好用的包管理工具，程序员只需要定义自己需要用什么三方库，需要什么版本。包管理工具就会自动下载、更新对应的代码到指定的目录。当然，使用三方库也会带来一些问题，比如多版本依赖、循环依赖等等，这些问题包管理工具都能够检测到或者使用一些妥善的方法去解决。这里就不展开了，感兴趣的同学可以去搜索一下maven和gradle等工具是怎么解决这些问题的。

云时代

目前大多数程序员仍然会使用copy和三方库。但这个开发过程仍然不够高效，比如自己要去搭建服务器、数据库、自己要去流量的负载均衡、网关安全等等。

随着近几年云时代的到来，云技术越来越成熟，渐渐有一些"*aaS（x as a Service）"的名词出现在大家的视野。比如云计算服务的三种模式：

IaaS：基础设施即服务，典型的就是aws、阿里云的产品，包括虚拟机、虚拟网络、存储等；
PaaS：平台即服务，提供一些平台，让用户可以把自己的程序方便地部署上去。比如web应用服务，数据库服务等属于PaaS；
SaaS：软件即服务，提供完整的应用程序，用户可以直接使用，不需要程序员开发。比如网盘、Jira、GitLab等。

后续又衍生了一些其它的xaaS，比如：FaaS（函数即服务），CaaS（容器即服务），DaaS（数据即服务）。这里不展开，但核心都是解决同一个问题：提升开发效率，降低研发成本。

这些“xx即服务”中，都是为了让开发人员能够更专注于业务和程序代码本身，简化其它操作，尤其是对于程序的编译、部署、运行环境等方面的问题。但对于程序员编写代码这个过程而言，并没有太大的帮助。

SaaS针对某些特定的领域提供通用的解决方案，但它很难做到高度定制化。比如很多CRM系统、ERP系统，其实就是SaaS。这方面做得比较好的一家公司是Salesforce，是美国的一家CRM平台，基于多租户、元数据的架构可以实现很灵活的定制化。但它也只是主要解决了CRM领域的问题。

中台

最近几年“中台”这个词也慢慢在业界火了起来。中台用一句话解释就是“可复用的企业能力”，拿电商业务来说，我们会有营销中台，交易中台等等。

中台的出现，是为了解决大型企业多个业务线，有一部分能力是通用的问题。拿交易来说，搭建一条交易链路的成本是非常高的，很多业务线在交易这个环节会有大量相似的逻辑，但也可能会有一些业务线自己特殊的逻辑。

中台的使命，就是把通用的逻辑内聚起来，提供统一的底层能力，同时留出扩展点，供各种业务场景去扩展自己的逻辑。

典型的中台框架就是阿里的星环（也叫TMF）。也有人说中台就是噱头，中台并没有达成当初理想的目标。不可否认，确实使用星环会让代码可读性变差，框架也比较重，学习成本比较高，更大的问题是很难对业务进行准确的抽象，需要对业务有很深入的理解，也需要有一些前瞻性和架构视野。但还是要分场景去看，不可否认的是星环确实在一些业务线显著降低了研发成本，支撑了阿里快速发展各种各样的创新业务。

无码与低码

中台解决了“业务代码复用”的问题，但主要适用于大型企业，搭建成本和使用门槛也比较高。对于一些中小企业或者不重要的业务系统来说，有什么办法能够在编码层面降低成本呢？

一个比较常见的解决思路是生成代码。其实可视化界面搭建，生成代码这种方式很早就存在于市场了。还记得16、17年我学编程那会儿，还有所谓的网页“三剑客”：Dreamweaver，Fireworks和Flash，可以通过可视化编辑的方式快速搭建网页，不过后来慢慢就不流行了。一些编程语言的工具库也是应用了类似的原理来降低开发成本，比如Java中的Lombok框架可以减少get/set等模板代码的生成，mybatis-plus, spring-data-jpa可以自动生成sql，减少开发人员编写sql的工作量。

可视化搭建、生成代码的思想仍然延续了下来。现在很多设计软件上可以直接生成前端使用的样式代码，也有一些比如问卷星、金数据这样的无码平台。无码和生成代码类似，只不过生成代码是需要自己修改部署的，还是需要懂技术的人参与。而无码平台是直接提供了一个saas平台，让不同技术的人也能搭建自己想要的软件或功能。

「无码平台并不能解决所有的问题」，无码平台在搭建问卷、搭建企业官网、搭建电商小程序等垂类的行业有不错的应用，但不够个性化。在用户需要搭建一个稍微复杂一点的功能或者有逻辑的功能时，就会显得有些力不从心。

那解决的办法是什么呢？就是开放一部分低代码的能力。让用户可以自定义前端组件、自定义后端逻辑。这需要平台具有一套强大的底层引擎来支持。飞书的aPaaS也正是朝着这个方向在实现，并且已经具备了比较完善的功能。

对于前端来说，低码其实就是一个前端组件。只是这个组件可以使用一些平台的SDK，比如使用无码定义的元数据、获取无码数据、调用无码的配置、自动生成的接口等。

对于后端来说，需要具有一定的灵活性和开放性。比如支持获取外部数据源，支持开放open api，支持流程引擎、规则引擎、调用FaaS函数等。

如果一个平台已经具备了无码和低码的能力，那它离一个完善的低成本搭建软件的saas平台还差什么呢？——答案是生态。就像建站平台一样，国内外已经有很多比较成熟的建站平台（比如WIX等），他们除了本身的组件足够丰富，支持高度定制化以外，另一个比较重要的就是在模板市场上有非常多的模板，可以一键应用模板来进行修改，达到快速建站的目的。

试想一下，假如需要一些项目管理、绩效管理、库存管理等等系统。或许这个saas平台已经有很多其它用户搭建过类似的系统了，他们上面大部分功能都是你也需要的，但你也需要一些定制化，怎么办呢？如果平台能够提供模板市场（或者叫插件市场、组件市场、应用市场等），你可以一键套用别人的系统，并在此基础上进行修改，那这个平台才算能够降低软件开发成本。这个平台的上限取决于它的生态有多丰富。