question: 当前项目代码是否有比大仓模式更优雅的方式？

[aaron-codes]

提出一个探讨类问题：这个一个非常优秀的生产工具，但从项目代码的角度采用大仓集成方式进行管理，目前个人自主学习过程中使用大仓构建代码有以下几点感受：

• 配置文件较多，且类型繁杂
• 仓库代码层级过深
• 代码过多，阅读有些吃力

所以个人有个不成熟的小建议，是否从关注点分离的视角将业务代码和 devops 流程分离拆解三部分：
apitable-front
apitable-backend
apitable-cli

也 👏 大家延伸探讨～

[lleytonyu]

jeecg最开始也是在一个GIT项目中，后面还是把前后端分离了。

[cloud0072]

apitable/packages 下是一整个js库包 包含了 前端 后端 国际化 小组件 的代码 一时半会儿应该是拆不开的，不然就要大改了

[zacker330]

从技术角度上，Monorepo的好处是不用讨论的了(https://monorepo.tools/ )。坏处就是很多人没有接触过Monorepo，进而导致不了解的人无法上手，或者入门成本高一点点（依赖于个人）。

但是，如何让Monorepo的项目结构清晰明了，则是另一回事。不论Monorepo还是Polyrepo都会有工程目录结构定义不清晰问题。

我没理解错 @aaron-codes 的意思的话，TA应该指的是当前APITable的根级别的目录结构不够清晰，需要改进。但是 @aaron-codes 的解决方案是将目前的monorepo工程改成polyrepo工程。

个人觉得：这个解决方案改动太大了。我想只修改当前monorepo下的目录结构是不是更好一些？建议按业务来划分工程目录结构如下：

• room-server
  • Dockerfile
  • deploy
• api-server
• web-front
• gateway
• docs

按业务来划分工程目录结构的好处是：

1. 更符合直觉，当你要找某个代码时，你先会想到的是它是关于什么业务的代码
2. 不同的业务有不同的技术栈，有不同的部署方式，它们都是为业务服务的，所以这些技术相关且和该业务相关的内容，应该以子目录的形式放在业务目录下。

同时，我认为DevOps的代码也是代码，放在Monorepo中是没有问题的。因为DevOps的代码也是需要通过构建进行自动化测试的。比如当前的gateway目录下的nginx的配置就没有单元测试。

[mr-kelly]

提出一个探讨类问题：这个一个非常优秀的生产工具，但从项目代码的角度采用大仓集成方式进行管理，目前个人自主学习过程中使用大仓构建代码有以下几点感受：

• 配置文件较多，且类型繁杂
• 仓库代码层级过深
• 代码过多，阅读有些吃力

所以个人有个不成熟的小建议，是否从关注点分离的视角将业务代码和 devops 流程分离拆解三部分： apitable-front apitable-backend apitable-cli

也 👏 大家延伸探讨～

感谢您的提问。

我这里围绕“应该大仓库还是拆分小仓库”，回答这个问题。

这取决于团队对目标或KPI的设定。

例如，如果团队要实现以下目标KPI：

1. 初级新人能够基于拆分小代码库，快速修改和定制功能； (指标: 时间)
2. 为不同的代码库，并设置权限以确保代码保密；(指标: 控制力)

那么，拆分工程，是不错的选择。

但是，如果从团队管理角度，制定以下KPI指标：

1. 初级新人从接触到能够成功运行整个程序所需的时间；(指标:时间)
2. 减少因对整体架构不了解而产生的片面、狭隘、低质量的代码数量；(指标:低质量代码)

那么，整合成大仓库，是更好的选择。

事实上，我们最初就是将工程分拆为多个git仓库，然后才进行整合。

并且，APITable开源库只是我们多个仓库中的一个开源仓库，还有其他额外的仓库。

大仓库的在日常操作中，工程师可以进入子文件monorepo开始工作，与分拆小工程没有区别。

根据我们目前的实际经验，从分拆工程到大仓库的区别主要体现在以下方面：

1. 对于不了解整体架构的人来说，可能会因为掌控力下降而感到恐惧；
2. 对于技术能力、编程语言单一的工程师，由于出现了跨语言的工程文件，会让其初期不会搭建开发环境；
3. 没有办法进行精细的权限管控；

明显，基于我们的目标和KPI指标，上面这些区别更多还是排挤掉初级新手、减少低质量代码，同时为高级工程师创造更友好的环境，这正好是我们的目标。

您是否有任何建议或行动方案？

另外，我们一直在持续招聘思考问题的工程师，我们支持全球化招聘并提供远程工作机会。如果您有兴趣，请填写以下招聘表单：https://apitable.com/share/shrDNBDeVlLvB1eFDMWhl

---

Thank you for your question.

It depends on the team's goals or KPIs.

For example, if the team aims to achieve the following KPIs:

• Junior developers can quickly modify and customize functionality based on a smaller codebase (Metric: Time)
• Different codebases are set up with permissions to ensure code confidentiality (Metric: Control)

Then, splitting the project into smaller repositories would be a good choice.

However, if we can define the following KPIs:

• Time taken for junior developers to go from exposure to successfully running the entire program (Metric: Time)
• Reduction in the number of biased, narrow-minded, and low-quality code caused by a lack of understanding of the overall architecture (Metric: Low-quality code)

Then, unified repo would be a better choice.

In fact, we initially started with multiple Git repositories and then consolidated them. APITable open-source library is just one of the repositories, and there are other additional repositories.

In daily operations, engineers can work in the subdirectories of the monorepo, which is no different from working with smaller split repositories.

Based on our current practical experience, the differences between splitting the project and having a monorepo mainly manifest in the following aspects:

• People who are unfamiliar with the overall architecture may feel fearful due to a decreased sense of control.
• Engineers with limited technical skills or experience in a specific programming language may face initial challenges setting up the development environment due to the presence of cross-language project files.
• Fine-grained permission control is not possible.

Clearly, based on our goals and KPIs, these differences align with our objectives.

Do you have any suggestions or action plans?