后端如何线性的提升自己的开发能力，或者学习到一些最佳实践

最近刷到一个排 bug 的博主，发现有些坑自己也是踩过的，想提升一下，避免踩一些前人踩过的坑，有什么比较系统的项目或者课程吗，目标是能到一个五年经验的水平
譬如下面的一些问题，是我遇到的，但是不知道怎么设计是比较合理且符合规范的

项目分一期二期，均是 springBoot 单体项目，共用同一个数据库。一期中需要用到二期的功能，二期也需要调用一期的功能。
不考虑微服务，设计之初应该如何架构（重复的业务放公共模块？）
现在的情况是两个项目都有重复的 Dao 层查数据库，明显错误的设计。
现有的情况下又该如何改进。

基础业务（用户信息），字段较多，分主表、详情表。
问题 1：详情表的信息是包在对象里面作为主表 VO 的一个属性返，还是把字段拷一份到主表的 VO 中。
问题 2：在不同业务需要展示的字段不同（比如个人资料界面需要返回所有字段，订单界面只需要返回姓名字段，可能有十多种情况）。
应该按业务分不同接口，还是所有业务调同一个接口返回所有数据（即使大部分用不上）。
如果分不同的接口，所有接口用同一个 VO 还是不同的 VO 。

上面的问题已经通过 AI 解决了，但是还可能有其他问题是自己没遇到的（设计模式、不同项目架构、数据库的拆分、什么字段该冗余这些），所以想找找覆盖面比较广项目或者课程学习一下
找了几个课程看了基本也都是直接告诉你怎么做，没有背后的思考，为什么要这么设计

其实很多编码和设计方面的坑，前人总结了许多，都写成书了。 我推荐其中的集大成者，就是《重构》，这本书本应该是每个开发人员必读的，它就是总结了千千万万的坑，并且分门别类，让读者具备管中窥豹、以小见大的能力，并且更重要的是，作者还教读者怎么填坑、怎么在软件生命周期内持续的控制技术债务规模。 其次是《设计模式》，这本书应该都看过就不详述了，它的思路你可以反过来看：你不按照这个模式设计，会带来哪些问题，这不就是坑么。 最后就是 AI ，AI 帮助极大，因为你可以不断地深入提问，并让 AI 评估你的思路。就我对 Google 的 Gemini Code 使用体验，它绝对可以看作是一个经验极其丰富，思维极其老到的程序员，我可以说只要有一定的表达能力，跟着 AI 学，软件培训机构通通都得关门。

一个人开发怎么来都可以，所谓规范更多的是用来解决多人开发的问题的。从多人协作的角度来看，两项目耦合同一个数据库就是不好的设计，因为这意味着 A 系统的开发者修改公用表的逻辑的时候需要去评估 B 系统是如何使用这张表的。解决这种耦合方法就是去划分领域，如果 AB 都是一个领域的，那么没必要划分成两个项目。如果 AB 领域不同，那么公用表是属于哪个领域的呢？是否要引入第三个领域 C 去做这一块逻辑？一般而言哪个系统写这张表就归谁，其他系统通过接口访问即可。不太理解你为什么要选择一种既不是单体又不是微服务的架构。你应该考虑的不是将 dao 变成公用的然后“复制”成两份给两个项目使用，而是该考虑这两个系统是否有独立部署运维的需求，如果有，考虑微服务，如果没有，合并成一个真的单体。 架构方面的书可以看《凤凰架构》，批判性的了解一下 DDD 。设计模式随便找些网站都能看到，但是关键是知道什么是设计模式。为什么这么多人用设计模式用的这么生硬，越写反而代码越难看？因为他们不理解设计模式只是在特定场景下的由一系列重构组合而成的解决方案。从这方面而言《重构》是一本好书，你可以注意到书中介绍的重构方法是极其的简单，并且部分方法之间是互相冲突的。这揭露出抽象化和反抽象化都可以是一种好的重构，重构没有银弹。之后你再去看那些设计模式，你就可以去推导，他们是由哪些重构组成的，其中各个重构的效果是什么，当前你需要哪些效果，如何去掉那些你不需要的重构。这样在解决问题的时候就不需要去硬套设计模式而引入一系列你还不需要重构导致代码笨重，产生过度(早)优化的问题。如何去应用 DDD 也如此思路。