到底如何创建一组项目

为什么要写这篇文章？因为最近加班一个多月在开发的时候发现的问题，刚好9月4号请了一天假，休息之余促使我写了这一篇

现在许多公司已经有了一套成熟的架构，为了今后的持续发展和扩张的业务，程序员的招聘也变得越来越平凡。一家公司如此多的程序员到底如何协作，如何创建一组项目。

传统项目是一个程序员必备的项目，他有完整的结构，从依赖到功能再到业务本身。一套Spring贯穿全部。但是他有缺点，那就是不够灵活。所以才有了现在的微服务。传统项优点之一就是他的依赖管理是完全由本身项目约定好的。

所以在您的项目从复杂的传统项目开始演化的阶段第一步就是应该管理好您所有的依赖。

很显然，许多公司没有对这里太多关注，导致程序员在开发阶段还好好的，到了整合测试阶段频繁爆出问题。在修复bug的时候，又得对部分已经完成的业务代码做出妥协。毫无疑问这个对组内的程序员是不友好的。往往为了一个简单业务，去修复而带来的程序修改需要耗费大量的脑力劳动。

我经常说，如果您看过spring-boot 2.1.x的项目，你就会发现他们是如何管理依赖的。spring本身是一个组项目，他的每次版本更替的依赖关系有且只有dependencies管理，其他项目直接或者间接继承了这个dependencies，所以在依赖管理，本质上是每一个子项目进行管理，实际上还是交给了dependencies。

所以我的项目如果是按照dependencies的概念来进行管理，我新增的依赖或者修改版本不会对我其他的业务造成过多的冲击。

这个里面也只有一个版本约束的文件（spring-boot 2.3.x不做评论 ，因为他是使用Gradle,我没有接触过），而且只能约束版本号，也就是说所有的依赖要写在<dependencyManagement>里。其他的项目继承才可以写在<dependencies>中，至于多个项目需要相同依赖的情况，就应该有一个base项目。比如spring-boot-starter-web和spring-boot-starter-test需要被您所有的基础服务依赖，那就可以创建一个base项目，base项目继承dep，然后你所有的基础服务项目全部继承base项目。而非自己直接使用idea去使用Spring Initializr创建。

…您的开发组织可能会陷入了一个痛苦的境地，敏捷开发和交付的任何一次尝试都将原地徘徊。一个主要问题是应用程序实在非常复杂。对于任何一个开发人员来说显得过于庞大，这是可以理解的。最终，正确修复 bug 和实现新功能变得非常困难而耗时。此外， 这种趋势就像是往下的螺旋。如果基本代码都令人难以理解，那么改变也不会变得正确，您最终得到的将是一个巨大且不可思议的大泥球。

所以开始微服务架构的第一步就是要将您本身的项目的依赖以及未来扩展预设完成，不然团队内的再多程序员得到也是一堆泥球，随着时间的推移，泥球也会越滚越大直到，第三次重构项目组（项目组并非项目）。

好了，随便写写，希望大家在CRUD之外能够收获更多，借用大佬的一句话：不经一番寒彻骨，怎得梅花扑鼻香。