مونوريبو مع Go: تنظيم الكود للمشاريع القابلة للتوسع

مستودع واحد مع Go: تنظيم فعال للكود

في تطوير البرمجيات الحديثة، يعد اختيار استراتيجية إدارة الكود أحد العوامل الرئيسية التي تؤثر على إنتاجية الفريق وقابلية توسع المشروع. المستودع الواحد (monorepo) هو نهج يتم فيه تخزين كود جميع الخدمات والمكتبات والأدوات في مستودع واحد. وبالاقتران مع لغة Go، التي صُممت أصلاً للمشاريع الكبيرة، يصبح المستودع الواحد أداة قوية.

في هذه المقالة، سنشرح كيفية تنظيم مستودع واحد على Go بشكل صحيح: من هيكل الدليل الأساسي إلى إدارة التبعيات باستخدام Go Workspace. ستتعلم كيفية تجنب الأخطاء الشائعة وبناء بنية تنمو مع مشروعك.

لماذا المستودع الواحد و Go هما الثنائي المثالي؟

تشتهر Go (Golang) ببساطتها وكفاءتها. ومع ذلك، عند العمل مع الخدمات المصغرة أو المكتبات الكبيرة، يبرز السؤال: كيف ننظم الكود بحيث يظل مناسباً للصيانة وإعادة الهيكلة؟

مزايا المستودع الواحد لـ Go:

• إصدار موحد للتبعيات: تستخدم جميع الخدمات نفس إصدارات المكتبات، مما يمنع التعارضات.
• إعادة هيكلة مبسطة: ينعكس تغيير API في مكتبة واحدة فوراً على جميع المستهلكين.
• تكامل الالتزامات: يمكن دمج التغييرات في أجزاء مختلفة من المشروع في التزام واحد، مما يبسط التراجع.
• التوحيد القياسي: قواعد موحدة للفحص linting والاختبار و CI/CD للمشروع بأكمله.

وفي الوقت نفسه، توفر Go أدوات مدمجة — الوحدات (go mod) ومساحة العمل (go work)، وهي مثالية للعمل مع المستودع الواحد.

الهيكل الأساسي للمستودع الواحد على Go

الهيكل الصحيح للدليل هو أساس المستودع الواحد الناجح. دعنا نلقي نظرة على التنظيم الموصى به باستخدام مثال مشروع يحتوي على عدة خدمات مصغرة ومكتبة مشتركة.

myproject/├── apps/│   ├── api-gateway/│   │   ├── cmd/│   │   │   └── main.go│   │   ├── internal/│   │   ├── go.mod│   │   └── go.sum│   ├── user-service/│   │   ├── cmd/│   │   └── internal/│   └── order-service/│       ├── cmd/│       └── internal/├── libs/│   ├── common/│   │   ├── logger/│   │   ├── config/│   │   ├── go.mod│   │   └── go.sum│   └── db/│       ├── models/│       ├── migrations/│       ├── go.mod│       └── go.sum├── scripts/│   ├── build.sh│   └── deploy.sh├── go.work├── Makefile├── .golangci.yml└── README.md

توضيحات الهيكل:

• apps/ — يحتوي على التطبيقات القابلة للتنفيذ (الخدمات المصغرة، أدوات CLI). كل خدمة هي وحدة Go منفصلة مع ملف go.mod الخاص بها.
• libs/ — مكتبات للأغراض العامة، يُعاد استخدامها بين الخدمات.
• scripts/ — نصوص مساعدة للبناء والاختبار والنشر.
• go.work — ملف مساحة العمل، الذي يربط جميع الوحدات في مساحة تطوير واحدة.

هام: لا تضع الكود مباشرة في جذر المستودع. استخدم الدلائل الفرعية للتجميع حسب الغرض الوظيفي.

إدارة التبعيات باستخدام Go Workspace

منذ الإصدار Go 1.18، تمت إضافة دعم مساحة العمل (workspace). هذه ميزة رئيسية للمستودع الواحد، تسمح بتطوير وحدات متعددة في وقت واحد دون الحاجة إلى نشرها في سجل عن بعد.

إنشاء مساحة العمل:

# تهيئة مساحة العمل في جذر المشروعgo work init ./apps/api-gateway ./apps/user-service ./libs/common

# إضافة وحدة جديدةgo work use ./apps/order-service

# عرض مساحة العمل الحاليةgo work edit -json

محتويات ملف go.work

المدونات

إعادة هيكلة الكود القديم بلغة Rust: دليل خطوة بخطوة

Rust في المشاريع الحقيقية: 5 حالات لشركات انتقلت إليه

توصيات الكتب

التزامن في Rust: من الأساسيات إلى الأنظمة عالية التحميل

C++ للرياضيات المالية

اكتشاف لغة C++ الحديثة

Jetpack Compose by Tutorials: إنشاء تطبيقات Android أصلية باستخدام Kotlin

اقرأ أيضًا

كيفية مشاركة المتغيرات بين الملفات في C++: دليل حول extern OAuth 2.0 وتفويض JWT في Rust: دليل خطوة بخطوة للمبتدئين العمل مع نظام الملفات في Rust: أمثلة عملية ونصائح مبادئ SOLID في Rust: النظرية والتطبيق للمطورين تسجيل الدخول في تطبيقات Java: أفضل الممارسات عمليًا