กลยุทธ์ monorepo เทียบกับ polyrepo คืออะไร?

Question

Accepted Answer

**Monorepo** (repository เดียวสำหรับหลายโปรเจกต์/service) และ **polyrepo** (repository แยกต่อโปรเจกต์) เป็นสองกลยุทธ์สำหรับการจัดระเบียบโค้ดข้ามหลายโปรเจกต์ แต่ละแบบมี trade-off ที่สำคัญซึ่งส่งผลต่อการทำงานร่วมกัน, เครื่องมือ และการ scale — การเข้าใจมันช่วยในการตัดสินใจเชิงสถาปัตยกรรมที่สำคัญ

## Monorepo — repo เดียวสำหรับทุกอย่าง

```text
Many projects/services/libraries in a SINGLE repository:
  ✓ SHARED code/libraries easy to use and refactor (one place, atomic changes)
  ✓ ATOMIC commits across projects (change an API and all its consumers together)
  ✓ Unified tooling, versioning, CI; consistent standards; easy cross-project visibility
  ✓ Simplified dependency management (one version of shared code)
  ✗ Repo can get HUGE (needs scaling tooling — sparse checkout, build caching)
  ✗ Needs sophisticated build/CI tooling (Nx, Turborepo, Bazel) to be efficient
  ✗ Broad access; CI must be smart (only build what changed)
→ Used by Google, Meta, etc. (with heavy tooling investment).
```

## Polyrepo — repo ต่อโปรเจกต์

```text
Each project/service/library in its OWN repository:
  ✓ Clear OWNERSHIP and boundaries; independent versioning/releases/CI
  ✓ Smaller, focused repos; granular access control; independent teams
  ✗ SHARED code is harder (publish/consume packages; version coordination)
  ✗ Cross-cutting changes span MANY repos (coordinate multiple PRs — painful)
  ✗ Potential inconsistency across repos (tooling, standards drift)
→ Common default; fits independent services/teams.
```

## การเลือก

```text
MONOREPO → tightly-coupled projects, heavy code sharing, want atomic cross-project
  changes and unified tooling, willing to invest in scaling tooling
POLYREPO → independent projects/teams, clear boundaries, independent release cycles,
  simpler per-repo needs
→ No universal answer; depends on the org, coupling, scale, and tooling investment.
```

## ทำไมจึงสำคัญ

การเข้าใจกลยุทธ์ monorepo เทียบกับ polyrepo เป็นความรู้ระดับ senior ที่มีคุณค่าต่อ**การตัดสินใจเชิงสถาปัตยกรรมที่ดีเกี่ยวกับการจัดระเบียบโค้ด** ซึ่งเป็นทางเลือกสำคัญที่มีผลกระทบกว้าง จึงมีประโยชน์ต่อตำแหน่ง senior/architect

สองแนวทาง — **monorepo** (หลายโปรเจกต์ใน repository เดียว) และ **polyrepo** (repository แยกต่อโปรเจกต์) — แทนปรัชญาการจัดระเบียบที่แตกต่างกันโดยพื้นฐานพร้อม trade-off ที่แท้จริง ข้อดีของ **monorepo** (โค้ดร่วมและการ refactor ที่ง่าย, **commit แบบ atomic ข้ามโปรเจกต์** — เปลี่ยน API และผู้ใช้ทั้งหมดพร้อมกัน, เครื่องมือและมาตรฐานที่เป็นหนึ่งเดียว, การจัดการ dependency ที่ง่ายขึ้น) ทำให้มันทรงพลังสำหรับโปรเจกต์ที่ coupling กันแน่นและมีการแบ่งปันโค้ดมาก แต่ต้องลงทุนมากใน**เครื่องมือ scaling** (Nx, Turborepo, Bazel, sparse checkout, CI ที่ฉลาด) เพื่อจัดการ repository ขนาดใหญ่อย่างมีประสิทธิภาพ ข้อดีของ **polyrepo** (ความเป็นเจ้าของและขอบเขตที่ชัดเจน, การกำหนดเวอร์ชันและรอบ release อิสระ, repo ที่เล็กและมุ่งเน้น, การเข้าถึงแบบละเอียด) เหมาะกับโปรเจกต์และทีมที่อิสระ แต่ทำให้**โค้ดร่วมยากขึ้น** (การเผยแพร่/ใช้ package, การประสานเวอร์ชัน) และ**การเปลี่ยนแปลงข้ามส่วนเจ็บปวด** (การประสาน PR ข้ามหลาย repo)

การเข้าใจ trade-off เหล่านี้และวิธี**เลือก** (monorepo สำหรับโปรเจกต์ที่ coupling แน่นและแบ่งปันโค้ดที่ยินดีลงทุนในเครื่องมือ; polyrepo สำหรับโปรเจกต์และทีมที่อิสระและมีขอบเขตชัดเจน) สะท้อนวิจารณญาณเชิงสถาปัตยกรรมที่คาดหวังในระดับ senior — การตระหนักว่าไม่มีคำตอบสากลและทางเลือกที่ถูกต้องขึ้นอยู่กับ coupling, scale, โครงสร้างทีม และการลงทุนในเครื่องมือ

เนื่องจากการจัดระเบียบโค้ดข้ามหลายโปรเจกต์เป็นการตัดสินใจเชิงสถาปัตยกรรมที่สำคัญซึ่งส่งผลต่อการทำงานร่วมกัน, เครื่องมือ, การ scale และความเป็นอิสระของทีม และเนื่องจากการเข้าใจ trade-off ของ monorepo/polyrepo ช่วยในทางเลือกที่มีผลตามมานี้ การเข้าใจกลยุทธ์ monorepo เทียบกับ polyrepo จึงเป็นความรู้ระดับ senior ที่มีคุณค่าต่อการตัดสินใจเชิงสถาปัตยกรรม เป็นหัวข้อที่ถูกถกเถียงบ่อยซึ่งการเข้าใจ trade-off (แทนที่จะชอบฝ่ายใดฝ่ายหนึ่งอย่างยึดติด) สะท้อนวิจารณญาณที่เป็นผู้ใหญ่ซึ่งคาดหวังสำหรับตำแหน่ง senior ที่กำหนดวิธีที่องค์กรจัดโครงสร้างโค้ดของตน