再启程，研发应用开发平台

今天不做纯技术的分享，而是说下个人的打算，也就是标题表明的：再启程，从头开始，研发一套应用开发平台，完全开源。

可以说，做开发平台，是我的梦想。近20年的职业生涯，先在软件公司从事软件系统的实施、系统的设计和产品的研发，后进入大型企业做信息化工作，做架构与设计，多年的技术积累与经验沉淀，对技术的执著，对业务的理解，有能力做一套优秀的开发平台出来了。

一直有一颗做开发平台的心，并且一直在尝试。

毕业之后，经历了新手村打怪升级攒经验，具备了一定的开发经验和设计能力后，就开始摸索开发平台的实现，或者说开发框架更合适一些。一方面，阅读大量技术文章，分析开源的平台源码，不断提升自己；另一方面，也不断动手去尝试，搭建一个又一个的框架出来。自己最初的技术栈是.NET，这是微软的技术帝国，技术选型几乎不用考虑别家的，直接选微软全家桶就好了，稳定、可靠，文档完善，学习资料丰富。虽然仍存在一些小角落，微软没做到位，但找一找第三方功能组件，也容易补足。
后来，自己的技术栈转向的JAVA，面向的是一片开源的汪洋大海，这时候再进行开发平台的研发，面临的是技术选型的难题。java领域的技术选型，实际要比.NET难得多。.NET基本可以无脑选微软官方全家桶，JAVA则面临多种多样的选择。多未必意味着好，需要耗费相当大精力去了解和选择。

幸好，JAVA领域有了Spring这棵参天大树，把主干给相对确立下来，主流的SSM框架，后来的SpringBoot，以及SpinrgCloud，成为了必选项。基于这棵主干，再去丰富完善枝叶，工作量和难度大幅降低。

另外一个比较大的变化，就是前端技术的演进，从JQuery到新的前端框架VUE和REACT（以前常称三大前端框架，还有AngularJS，不过近几年AngularJS确实没落了，特别是在国内，选用的越来越少）。对于开发人员而言，我的感受是，前端越来越像后端，比如MVC理念、模块化……个人认为，是将后端成熟的套路，迁移到了前端。开发模式也随着技术的变迁发生变化。JQuey及更早期的年代，开发人员既干前端UI开发，又干后端逻辑代码开发。后来，前后端分离模式出现，前端和后端的开发也进行了一定程度的分离，往往是各一波人，各做各的，然后集成测试。发展到现在，前后端模式越来越相似，开发人员同时做前后端开发又变成了可能。当然，这里特指的是企业类应用，对前端UI要求不高，更侧重于后端业务逻辑的实现。如果是互联网应用，前端UI直接面向用户，比如设计优雅的布局、友好的操作，特别是一个像素都得打磨的情况，还是需要专业的前端人员来做。

这么多年下来，其实我手头有一套开发平台了，基本算是一人独立完成，只不过，因为一些三两句话说不清道不明的原因，不适合拿出来开源。技术上，后端使用是主流SSM+MyBatisPlus,主流技术，前端使用的vue2.0和Element UI，虽然旧了点，但影响也不大。现在呢，想从头开始，基于自己的经验，研发一套全新的开发平台出来，后端基本不变，进行优化和完善，前端更换为vue3.0和Element Plus。

其实之前纠结过，是不是可以基于现有的开源的开发平台，而不是另起炉灶。
关于这个选择，先说说开源开发平台的现状。
目前市面上有不少的开源的开发平台，部分平台经过多年的积累和迭代，逐渐成熟，进入了商业化运营，从最初的完全开源，逐步演进成了细分版本，将免费版与商业版进行了分离，免费版开源，商业版需要付费授权。

表面看上去，免费版相比商业版，只是功能要少一些，实际上并不是这么简单。免费版很可能是一个较早的历史版本，bug不一定多，但其他方面，比如代码规范性、代码注释、性能等存在或多或少的问题。此外，还可能存在的问题在于中间件或功能组件，采用的仅适用于小项目选型。

相比上面将免费版与商业版分离的模式，还有一种模式好得多，即源码完全开放，录制了系统使用说明视频，对视频收费，或者限制系统设计文档的访问。开源确实需要投入大量时间精力，通过上面两种模式获取一点回报，算是不错的方式了。

目前市面上比较流行的主流开源框架是若依，这是一款优秀的个人作品。深入了解了下，若依实际实现了一个精简的内核，业务支撑部分和外围功能组件集成是欠缺的。如直接用来做业务系统开发，实际还是有大量介于技术与业务中间地带的功能需要实现的。精简内核不一定是若依的劣势，而很可能是优势。推测这可能是一种策略，若依出彩的地方在于生态已经做起来了，基于这个内核，有了大量的衍生项目，除了官方自己发布的多种形式，单体版、前后端分离版、微服务版外，还有第三方扩展的，比如集成了工作流，实现了移动端，兼容了MyBatisPlus等等。

在这里不得不提一下芋道源码，针对若依原版框架功能精简的情况，丰富了大量功能，包括工作流、会员、支付、移动端……。在这个基础上再做业务系统开发，将会轻松很多。

回到问题本身，是不是可以基于现有平台，比如芋道源码进行改造，这样是不是能大幅缩短开发周期，降低工作量呢？
实际上，我一度搭建了开发环境，想在其基础上改造。后来经过认真的评估，还是放弃了。
一方面，底层还是差异比较大。芋道源码等平台，基本就是先做数据库表的设计，然后基于库表反向生成各层格式化的代码。在我看来，这种模式比较僵化，代码生成后，还是需要进行较多的修改来进一步控制细节。我的设计中，是按照模块-》实体-》模型-》视图的方式，来实现各层代码的定制与生成的。并且底层设计中，会采用模板方法的设计模式思想，定义基类，将增删改查这种基础功能都实现掉，并预留扩展方法，如修改前、修改后，业务功能类只需要按需扩展，实现个性化业务逻辑就行了。同理，对于前端，使用mixin混入，同样是模板化思想，具体的业务功能要实现的功能会大幅减少。
另一方面，芋道考虑了微服务，将模块层和API层做了分离，并且完整实现了VO、DTO、BO、DO这些数据对象，以及相应的转换，个人认为整体框架有些过重了。毕竟，选择开源平台的，往往不会是大型企业应用，因此需要适度，兼顾开发效率与性能。我的平台，不考虑微服务架构，引入了VO层，来负责前端与控制器层的数据传递，然后使用entity实体对象来进行服务层、DAO层的数据传递。

整体评估下来，基于现有的若依或芋道改造，工作量不小，不如从头开始，保持代码的简洁性。从头开始，不是从零开始，大量的技术选型工作，平台设计工作，都已实现，需要的只是迁移和优化。一个人的力量，精力，时间投入虽然是有限的，但功能可以一点点增加，系统可以一点点完善，持续做下去，终会实现，周期长一点也没什么，1年，3年，5年，因为热爱，所以不觉得苦和累，反而乐在其中。

整体规划大致如下；
1.实现系统内核，打通前后端，系统能运转起来
2.实现代码生成器，这是后续开发的孵化器
3.基于代码生成器实现平台其他功能
4.集成功能组件，扩展技术能力
5.基于技术组件封装业务功能组件

整个平台完全开源，也希望感兴趣的加入进来，特别是前端开发，帮忙做做样式设计，把系统UI做的美观大方一些，这是擅长后端开发人员的薄弱点。

本博客上会同步开一个专栏，将平台研发过程中的设计思路、遇到的问题和方案的选择等一并分享出来，欢迎交流与讨论。

就说这么多，再启程，一往无前。

开发平台资料

平台名称：一二三开发平台
简介： 企业级通用开发平台
设计资料：csdn专栏
开源地址：Gitee
开源协议：MIT
欢迎收藏、点赞、评论。