做日本民宿的网站十大接单平台

前言：本文是笔者在初创公司，一年多来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时期（无代码时期）

2.0时期（无代码时期）

  敬请期待～～