前言:本文是笔者在初创公司,一年多来Java后端服务底座搭建过程的总结,如有不当之处,还请各位大大指正。
开发模式的演变
草创时期
该阶段是笔者跟随leader从大厂跳槽到初创公司的前两个月,这两个月公司内部只有我们两个后端(严格来说是四个,还有两个实习生),我们几个人当时开发后端服务的时候还是处于野蛮生长阶段,就是直接通过idea的spring项目快速生成器来构建一个项目的,如下图:
当时我们(主要是我还有两个实习生)并没有意识到这样做会有什么问题,都觉的理所当然,所有的教程辅导资料都是这么教的,不这样建还能怎么建,难道手写?不可能,绝对不可能!!!
其实当时leader已经在暗搓搓的发力了。在我们还在纠结Java 持久层框架是否使用mybatis-plus,代码生成器使用哪个插件的时候,leader已经把他设想中的所有工具内嵌入公司的基础底层框架中了。这里就就不得不提到另外一个项目搭建工具了——archetype,它是maven自带的一个maven工程创建工具,可以通过自定义模板来生成对应的应用架构。我们当时还不理解这个东西是怎么用的,原理是什么,只是在某一天leader和我们说:“今后公司的所有工程项目的创建都是用这个框架来实现。” 然后我们就进入了服务端开发的1.0 时期。
1.0时期(基座时期)
这个阶段定下了公司后续所有项目结构的基本风格,为后续版本的迭代开发提供了坚实的理论依据(其实就是方便后来的一些小白读懂代码,也有一点方便我们改代码的意思在里面)。
上面这句话并不是BOSS的原话,不过意思差不多,后面这一年多的开发过程我们的确深有感触。当你接触其他人写的新项目的时候,你会发现项目结构是如此的相似,持久层、业务层、控制层的关系是如此的明显,以至于你会有一种一切尽在掌控中的感觉,这为你接手新项目并进行相应的迭代更新打造了一个良好的开头。不得不说这一步棋的确是点睛之笔,秒到绝巅(拍彩虹屁,略略略~~)
当然光有项目骨架是毫无用处的,它只能帮你搭建一个抽象的架构,具体的业务逻辑有哪些、代码需要如何去写这又是我们要思考的问题了?
后端服务的业务逻辑归根结底无外乎就是对数据的crud,那么其实只需要有业务表结构,我们是否就可以一键生成对应的crud代码,从而无需开发一些简单的业务逻辑?答案是显而易见的——可以。
大约是进入公司的第三个月底到第四个月初,leader基于freemarker模版组件写了一个属于公司内部的代码生成器插件,其实本质上和通用工具中的代码生成器没有太多的区别,唯一一点的区别就是它是高度适配公司的基础架构,可以做到只配置数据库地址,就可以生成符合我们代码风格的从持久层到控制层的所有代码。(我们当时问为什么不用现成的工具,还要自己开发,leader说自己开发的知道源码,后期出现什么问题也好调整,用别人的出了问题都不知道怎么解决,姑且也就信了吧)这个插件出来以后,我们便进入了后端服务开发1.1时期。
1.1时期(低代码时期)
在这个阶段其实已经完成核心架构基座的开发逻辑,我们直至今天也仍旧处于这个时期内。在这个阶段我们面临的问题基本就是业务向的问题了,这个阶段的核心逻辑就是:尽可能的抽象出通用工具,减少非必要的人为错误,提高开发效率。
从第四个月进入低代码时期后,我们造了很多轮子,像是grpc远程服务调用组件、websocket服务端组件、前后端消息通信协议组件(SSE)等等,这些极大的提高了我们的工作效率。但是随着轮子越来越多,后端服务的开发/学习成本也越来越高,在可预期的范围内它将会成为一个限制开发效率的瓶颈,那么是否有方案可以解决它呢?答案暂时不确定,我们设想过将这些轮子抽象出来管理,通过配置化的流程将现有功能互相组合从而达到新功能的目的,但碍于种种原因我们并未真正付诸于行动。当然市面上可能已经出现了一些成熟的解决方案,我们还在持续关注中,期待能够早日进入2.0时期(无代码时期)文章来源:https://www.toymoban.com/news/detail-833211.html
2.0时期(无代码时期)
敬请期待~~文章来源地址https://www.toymoban.com/news/detail-833211.html
到了这里,关于Java后端底座从无到有的搭建(随笔)的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!