هل نحتاج إلى كل ما توفره Go منذ البداية؟

تتميز Go بقواعد واضحة و بناء سريع و أدوات مباشرة للتزامن. لكننا لا نحتاج إلى كل ما توفره منذ أول سطر.

نستفيد من الميزة حين تظهر الحاجة إليها. لهذا سنميز في هذا الدرس بين ما يفيد مشروعنا منذ البداية و ما سنؤجله حتى نحتاج إليه.

ما الذي يفيدنا منذ البداية؟

خلال هذه الدورة سنبني أداة اسمها jobrunner. سنضيف إليها خطوة صغيرة في كل مرة ثم نبني البرنامج و نجرب النتيجة.

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

لا يعني ذلك أن كل برنامج Go سريع مهما كانت طريقة كتابته. عندما نهتم بسرعة البرنامج أثناء التشغيل، نقيس أولا ثم نبحث عن سبب البطء. أما الآن فالأهم أن نبدأ من أساس واضح يمكننا تطويره.

لماذا نؤجل التزامن؟

ستنفذ النسخة الأولى من jobrunner المهام واحدة بعد الأخرى. لا توجد في هذه المرحلة أعمال مستقلة تحتاج إلى التقدم معا. لذلك لا تمنحنا إضافة goroutines فائدة واضحة، بل تجعل مسار التنفيذ أصعب من دون أن تحل مشكلة موجودة.

سنؤجلها حتى تظهر الحاجة إليها في مشروع لاحق. عندها سنستخدم goroutines لتنظيم أعمال متزامنة و channels للتواصل بينها عندما يناسب ذلك تصميم البرنامج.

متى تظهر الحاجة؟

تخيل أن مهمة تنتظر استجابة من خدمة عبر الشبكة، بينما توجد مهمة مستقلة جاهزة للعمل. يستطيع البرنامج تنفيذ المهمة الجاهزة أثناء انتظار استجابة المهمة الأولى.

كما رأينا في الدرس السابق، لا يعني التزامن (Concurrency) أن الأعمال تنفذ في اللحظة نفسها. فالتنفيذ المتوازي (Parallelism) مفهوم مختلف.

و حتى عندما نحتاج إلى التزامن، لا تضمن goroutines و channels سلامة البرنامج من تلقاء نفسها. يبقى علينا تحديد طريقة انتقال البيانات و معرفة من يملك حق تعديلها.

الخلاصة

لا نستخدم ميزة لمجرد أن Go توفرها. سنستفيد الآن من وضوح اللغة و سرعة دورة البناء و التجربة. و سنضيف التزامن عندما تظهر أعمال مستقلة تستفيد منه.

في الدرس التالي سنرى لماذا تقلل Go عدد الخيارات في اللغة. و سنرى كيف يساعد ذلك على وضوح الكود.