我不喜欢单体存储库。它们将多个项目放在一起，通常由不同团队以不同语言编写。不幸的是，Google、Facebook和Yandex偏好它们。主要是因为，根据他们的说法，monorepos减少了集成开销。它确实如此，但代价是质量。在较小的存储库中，我们可以开发出更好的代码。
当存储库较小时，您可以出于多种原因实现更高的质量：
你可以写更深入的测试。集成（或深度）测试不可避免地很慢。在较小的代码库中，良好的集成测试覆盖率并不意味着构建速度慢。但在较大的代码库中，它确实会慢。一个慢的构建是团队试图避免的，因此可能会危及测试覆盖率。
你可以更加严谨地审查。在一个较大的代码库中，可能会更难记住设计的所有方面。影响不同看似不相关的代码部分的拉取请求可能会很具挑战性。即使你是架构师。
你可以写一个 README。也许你已经注意到了：大型开源项目的 README 文件通常很简短。它们无法让它们变得更长，否则就会变得如同一本书。它们只能将读者引导至文档网站。无法在一个文件中解释整个范围会导致范围扩张。贡献者难以理解项目的边界。这会导致代码重复等问题。
你可以频繁发布。在一个较大的代码库中，频繁的重新整合可能会很昂贵，无论是时间还是金钱。在一个较小的代码库中，几秒钟的构建不是程序员的梦想，而是现实。持续集成不仅廉价，持续交付也是如此。每次小改动后，你都可以发布一个新的版本，带有自己的版本。在一个单一代码库中，我们往往会等待一部分改动积累起来。
您可以有效地使用AI代理。现代LLMs的上下文窗口是有限的并不是秘密。即使是一百万行的代码也无法完全容纳在它们中最大的一个中。即使是一万行，更不用说一百万行，也超出了LLM的理解范围。通过保持存储库的规模较小，我们对我们的小朋友AI代理做了一大笔好事。
你可以更快地融入团队。较大的代码库通常更古老、更混乱，充满遗留代码。要开始对这样的存储库做出有意义的贡献需要更长时间。单一仓库吸引那些关心工作安全胜过代码质量的长期办公室贡献者。
您可以期待责任。在较大的代码库中，代码所有权的概念很难维护。程序员几乎无法对其他人编写和修改的代码感到负责。另一方面，较小的存储库会情感上让人们与代码产生联系。
你可以选择开源。 无论你的老板多么喜欢开源，你也不能把整个企业的 monorepo 放在 GitHub 上。但是，如果你提取其中的一小部分，就可以了。公开、可见并受到许多人批评的代码据说质量更高。
总之，你应该寻找一个机会将一段代码提取为一个独立的包。然后，坚持让它成为开源的。然后，在社区中推广它。然后，辞去你的办公室工作，加入Zerocracy。
Translated by ChatGPT gpt-3.5-turbo/42 on 2025-11-16 at 03:38
