مراجعة الكود في Go: ما يجب فحصه وكيفية تقديم الملاحظات

مراجعة الكود في Go: ما الذي يجب التحقق منه وكيفية تقديم الملاحظات

مراجعة الكود (Code review) ليست مجرد إجراء شكلي، بل هي واحدة من أكثر الأدوات فعالية لتحسين جودة الكود، وتبادل المعرفة في الفريق، ومنع الأخطاء. في مجتمع Go (Golang)، تحظى مراجعة الكود بأهمية خاصة، لأن اللغة تشجع على البساطة، وسهولة القراءة، والاستخدام الاصطلاحي. في هذه المقالة، سنناقش ما يجب الانتباه إليه عند مراجعة كود Go وكيفية تقديم الملاحظات بحيث تكون مفيدة وليست مسيئة.

1. المبادئ العامة لمراجعة الكود في Go

قبل الانتقال إلى التفاصيل التقنية، من المهم تذكر ثقافة المراجعة. هدفك هو تحسين الكود ومساعدة زميلك، وليس إثبات صحة رأيك. إليك بعض القواعد الذهبية:

• كن بناءً. بدلاً من "هذا سيء"، اكتب "قد يكون هناك تسريب لـ goroutine هنا، دعنا نضيف سياقًا".
• اسأل، ولا تؤكد. "لماذا اخترت sync.Mutex بدلاً من القناة؟" هو سؤال جيد. "أنت غبي، كان يجب استخدام القناة" هو سؤال سيء.
• لا تؤخر المراجعة. حاول الرد خلال 24 ساعة (أو حسب الاتفاق في الفريق).
• ركز على المنطق والهندسة المعمارية. من الأفضل ترك التعديلات الأسلوبية (المسافات، الحواف) لأداة gofmt.

2. ما الذي يجب التحقق منه أولاً: قائمة مرجعية لـ Go

إليك قائمة منظمة لما يجب الانتباه إليه عند مراجعة كود Go. سنقسمها إلى كتل منطقية.

2.1. معالجة الأخطاء

لا توجد استثناءات في Go، الأخطاء هي قيم. هذه واحدة من المصطلحات الأساسية للغة.

• تحقق من جميع الأخطاء المرتجعة. تجاهل الخطأ باستخدام _ مسموح به فقط في حالات نادرة جدًا (على سبيل المثال، عند الكتابة إلى io.Discard).
• لا تستخدم panic للأخطاء العادية. panic مخصص للحالات غير القابلة للاسترداد (مثل خطأ تهيئة الخادم).
• لف الأخطاء. استخدم fmt.Errorf("حدث خطأ ما: %w", err) لإضافة سياق. هذا يسمح باستخدام errors.Is() و errors.As().

// سيء: فقدان السياقif err != nil {    return err}

// جيد: لف الخطأif err != nil {    return fmt.Errorf("تعذر فتح الملف %s: %w", filename, err)}

2.2. الـ Goroutines والتزامن

تشتهر Go بالتزامن الخفيف، لكنه أيضًا مصدر للعديد من الأخطاء.

• تسريبات الـ Goroutines. تأكد من أن كل goroutine يتم تشغيلها ستنتهي في وقت ما. استخدم السياق (context.Context) للإلغاء.
• الاستخدام الصحيح للقنوات. من ينشئ القناة هو من يغلقها. إغلاق القناة هو مسؤولية المرسل.
• سباق البيانات (Data race). تجنب الكتابة المتزامنة إلى متغير واحد دون مزامنة. استخدم الـ Mutexes (sync.Mutex) أو الـ Atomics (sync/atomic).

// مثال مع السياق لإلغاء goroutinefunc process(ctx context.Context, dataCh chan int) {    for {        select {        case <-ctx.Done():            log.Println("إنهاء العمل")            return        case val, ok := <-dataCh:            if !ok {                return // القناة مغلقة            }            fmt.Println(val)        }    }}

2.3. المصطلحات وأسلوب Go

Go هي لغة حيث يتم تقدير قابلية قراءة الكود قبل كل شيء.

• أسماء المتغيرات. أسماء قصيرة لنطاقات الرؤية القصيرة. i للحلقة، r للـ reader. للمتغيرات العامة - أسماء أطول.
• تجنب "الأرقام السحرية". استخدم الثوابت.