الكود ليس نقطة النهاية

يعتبر الكثير من المهندسين أن "كتابة كود يعمل" هي لحظة إنجاز العمل.

لكن هندسة البرمجيات الناضجة حقًا تتجاوز ذلك بكثير.

كل تعليق تكتبه، وكل رسالة commit، وكل تقرير bug، وكل سؤال تطرحه، سيستمر في "التحدث" في المستقبل. سيراها المستخدمون، والمشرفون على الصيانة، وستراها أنت لاحقًا، وسيراها المهندس الذي سيتولى هذا الكود بعد سنوات.

من هذا المنظور، تطوير البرمجيات ليس مجرد "كتابة كود"، بل هو تواصل مستمر عبر الزمن وعبر الأدوار المختلفة.

وقيمة المهندس المتميز غالبًا ما تتجلى في جودة هذا التواصل.

الكود يُكتب لتنفيذه من قبل الآلة، والتوثيق الهندسي يُكتب ليفهمه البشر

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

الشخص الذي سيقرأ كودك في المستقبل قد يكون:

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

هم لا يملكون السياق الذي كان في ذهنك أثناء كتابة الكود، بل لا يرون سوى "الآثار" التي تركتها.

هذه الآثار تشمل:

تعليقات الكود
رسالة commit
وصف PR
تقرير issue و bug
الأسئلة والأجوبة في سلاسل النقاش

جودة هذه المحتويات تحدد بشكل مباشر تكلفة فهم الآخرين لعملك، وتحدد أيضًا ما إذا كان التعاون سيكون سلسًا.

بمعنى آخر،جوهر التعاون الهندسي هو تقليل التكلفة التي يتكبدها الآخرون لإعادة بناء السياق.

التعليق الجيد لا يكرر الكود، بل يشرح "لماذا"

عند كتابة التعليقات، يحب الكثير من المبتدئين إعادة ترجمة الكود. على سبيل المثال:

i += 1  # i 加 1

هذا النوع من التعليقات لا قيمة له تقريبًا، لأن الكود نفسه يوضح بالفعل "ما تم فعله".

التعليق ذو القيمة الحقيقية يجب أن يجيب على هذه الأسئلة:

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

أي أن الكود مسؤول عن التعبير عن what، والتعليق يجب أن يكمل أكثر why و why not.

أحد معايير الحكم التجريبي هو:

إذا حذفت التعليق، وكان قارئ الكود لا يزال يعرف "ماذا يفعل"، لكنه لا يعرف "لماذا يجب فعله بهذه الطريقة"، فهذا التعليق قيّم.

جوهر رسالة Commit ليس وصف ما تم تغييره، بل شرح سبب التغيير

سجلات التعديل في الكثير من الفرق تبدو هكذا:

fix bug
update code
small changes
refactor
wip

هذه المعلومات قد تكون "كافية" لنظام التحكم بالإصدارات، لكنها لا تساعد المتعاونين تقريبًا.

رسالة commit الجيدة يجب أن تحاول الإجابة على سؤال رئيسي:

ما هي المشكلة التي أجبرتك على إجراء هذا التعديل؟

لأن عرض الاختلافات في الكود (diff) يمكنه أن يظهر "أين تم التغيير"، لكنه لا يستطيع أن يخبر الآخرين تلقائيًا:

ما هو السبب المحفز وراء التغيير
ما هي الظاهرة التي يصلحها هذا التعديل
هل هذا التغيير لأجل التوافق، أم الأداء، أم الاستقرار، أم قابلية الصيانة
لماذا هذا الحل أنسب من الحلول الأخرى

على سبيل المثال، مقارنة بـ:

fix login bug

الصياغة الأكثر إفادة هي:

prevent login failure when session cookie expires during OAuth callback

الأولى تخبر الآخرين فقط "تم إصلاح مشكلة تسجيل الدخول"، بينما الثانية تقدم السيناريو المحدد وحدود المشكلة.

سجلات التعديل الممتازة ليست فقط لتسهيل المراجعة الحالية، بل هي تحضير لعمليات تقصي الأخطاء والتتبع ونقل المعرفة في المستقبل.

عندما يحتاج الفريق لتحديد "من أي تعديل نشأت" مشكلة ما، يمكن لسجل commit الواضح أن يوفر وقتًا كبيرًا في كثير من الأحيان.

كتابة تقرير Bug بشكل جيد تساعد في حل المشكلة بشكل أسرع

عند الإبلاغ عن bug، التفكير الافتراضي لدى الكثيرين هو: "لقد اكتشفت المشكلة، على المطور أن يبحث."

لكن من وجهة نظر المشرف على الصيانة، إمكانية معالجة bug بسرعة تعتمد غالبًا على ما إذا كان التقرير محددًا بما يكفي، وقابلًا للتحقق، وقابلًا لإعادة الإنتاج.

تقرير bug عالي الجودة يجب أن يجيب على الأسئلة التالية على الأقل:

1. ما هي المشكلة

لا تكتب فقط "لا يعمل"، "هناك مشكلة"، "حدث خطأ".

حاول وصف الظاهرة المحددة قدر الإمكان، على سبيل المثال:

الصفحة لا تستجيب بعد النقر على زر الحفظ
عند رفع ملفات أكبر من 50 ميجابايت، يعيد الـ API الرمز 500
نص شريط التنقل يختفي بعد التبديل إلى الوضع الداكن على الهاتف المحمول

2. ما هي خطوات إعادة إنتاج المشكلة

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

على سبيل المثال:

تسجيل الدخول باستخدام حساب مستخدم عادي
الدخول إلى صفحة الملف الشخصي
رفع صورة PNG أكبر من 50 ميجابايت
النقر على حفظ
الصفحة تشير إلى نجاح الرفع، لكن الصورة الرمزية لا تتحدث بعد التحديث

3. ما هي النتيجة المتوقعة والنتيجة الفعلية على التوالي

هذا جزء مفقود في الكثير من تقارير bug.

عند كتابتها بوضوح، يمكن للآخرين أن يحكموا بسرعة ما إذا كان هذا bug بالفعل، أم سوء فهم للمتطلبات، أم مشكلة بيئية.

4. ما هي البيئة التي ظهرت فيها المشكلة

على سبيل المثال:

إصدار المتصفح
نظام التشغيل
إصدار التطبيق
الفرع / رقم commit
بيئة الاختبار أم بيئة الإنتاج

5. هل هناك أي أدلة إضافية

مثل:

لقطة شاشة للخطأ
مقتطف من السجلات
معاملات الطلب ذات الصلة
هل يمكن إعادة إنتاجها بشكل ثابت
هل بدأت بالظهور بعد تغيير معين

تقرير bug الجيد، في جوهره، يقلل من وقت التخمين الذي يقضيه المشرف على الصيانة.

كلما كانت المعلومات التي تقدمها أوضح، كانت سرعة دخول المشكلة في مسار الإصلاح أسرع عادةً.

التواصل مع وضع المشرف على الصيانة في الاعتبار يجعلك تحصل على استجابة أسهل

سواء كنت تقدم issue، أو ترفع PR، أو تطلب مساعدة من أحدهم، فأنت في الجوهر تتواصل مع "أشخاص لديهم الكثير من الأشياء ليفعلوها".

هم عادة لا يبدأون بالتفكير من وجهة نظرك: "ما مدى أهمية هذه المشكلة بالنسبة لك"، بل سيحكمون بشكل غريزي أولاً:

كم من الوقت سأحتاج لأفهم هذا؟
هل هذه مشكلة حقيقية وواضحة؟
هل قام هذا الطلب بالأساسيات المطلوبة؟
إذا تدخلت الآن، هل يمكنني الدفع بالأمر نحو التقدم بفعالية؟

لذا، التواصل الجيد ليس مجرد "طرح المشكلة"، بل جعل الطرف الآخر يدخل في المشكلة بتكلفة منخفضة.

هذا يعني أنك بحاجة للقيام بهذه الأمور مسبقًا:

تقديم الخلفية، بدلاً من مجرد إلقاء الاستنتاج
تقديم الأدلة، بدلاً من مجرد إعطاء حكم
تقديم مسار إعادة الإنتاج، بدلاً من مجرد قول "هناك bug"
تقديم ما حاولت فعله بالفعل، بدلاً من تفويض عملية التقصي بالكامل للآخرين

عندما يشعر الآخرون أن "هذا الأمر يستحق المعالجة، ويمكنني الشروع فيه بسرعة"، سيرتفع معدل الاستجابة بشكل طبيعي كثيرًا.

القدرة على طرح الأسئلة غالبًا ما تكون أهم من الإجابة نفسها

إحدى المشكلات الشائعة في الفرق الهندسية هي:

ليس أنه لا أحد يرغب في مساعدتك، بل أن سؤالك يجعل من الصعب على الآخرين مساعدتك.

على سبيل المثال:

"لماذا هذا لا يعمل؟"
"يظهر لي خطأ، ماذا أفعل؟"
"هل يعرف أحد كيف يعدل هذا؟"
"هل هذه المكتبة فيها مشكلة؟"

المشكلة في هذا النوع من الأسئلة هي: كثافة المعلومات منخفضة جدًا، يحتاج الآخرون لاستجوابك أولاً قبل أن يبدأوا بالتفكير.

طريقة طرح أفضل للسؤال تحتوي عادة على هذه العناصر:

1. الهدف

ما الذي تريد تحقيقه؟

2. الظاهرة

ما الذي يحدث بالضبط الآن؟

3. المحاولات السابقة

ما الذي قمت بتقصيه بالفعل؟

4. نقطة التعثر

أين يكمن أكثر شيء غير متأكد منه حاليًا؟

على سبيل المثال، بدلاً من أن تسأل:

لماذا الـ API لا يعمل؟

من الأفضل أن تسأل:

أنا أتلقى الخطأ 403 باستمرار عند استدعاء /api/upload محليًا.
تأكدت من أن الـ token صالح، وأن الوصول إلى الـ APIs الأخرى يعمل بشكل طبيعي باستخدام نفس الحساب.
راجعت ترويسات الطلب، ووجدت أن هذا الـ API فقط هو من يتطلب X-Workspace-Id إضافي.
لست متأكدًا حاليًا ما إذا كانت مشكلة في إعداد الصلاحيات، أم أن البوابة تعترض الطلب.
هل يعرف أحد ما هو السياق الإضافي المطلوب إكماله عند تصحيح هذا الـ API محليًا؟

هذا النوع من الأسئلة يحصل على إجابات عالية الجودة بسهولة أكبر، لأن الآخرين لا يحتاجون لبدء التخمين مما واجهته من الصفر.

جوهر السؤال الجيد هو جعل الآخرين يدخلون مباشرة في التحليل، بدلاً من الدخول أولاً في جمع المعلومات.

أكثر القدرات التي يُقلل من شأنها في التعاون الهندسي: توفير تكلفة تبديل السياق على الآخرين

لماذا يستطيع بعض المهندسين دفع الأمور للأمام دائمًا، بينما آخرون يجتهدون أيضًا ولكن يتسببون في تعطيل التعاون؟

الفرق غالبًا لا يكمن في العمق التقني، بل في القدرة على توفير تكلفة الفهم على الآخرين.

كلما كان ما تكتبه أوضح، كان من الأسهل على الآخرين:

المراجعة بسرعة
تحديد المشكلة بسرعة
تحديد الأولوية بسرعة
اتخاذ قرار سريع بشأن اعتماد حلك
تولي الأعمال اللاحقة بسرعة

وعلى العكس، فإن شرح التعديل الغامض، ووصف bug المبهم، والأسئلة منخفضة الجودة، تحول كمًا كبيرًا من العمل إلى "تواصل ثانوي" و"تأكيد متكرر".

وهنا بالتحديد يتم التهام كفاءة الفريق بصمت.

المهندس المتميز ليس فقط من يكتب الكود، بل من يترك أثرًا واضحًا

بالنظر إلى الوراء، الكثير من التعاون عالي الجودة في هندسة البرمجيات لا يحدث لأن شخصًا ما "يجيد الكلام بشكل خاص"، بل لأن كل أثر هندسي يتركه يكون واضحًا بما فيه الكفاية:

التعليقات تشرح القرارات الرئيسية
رسالة commit توضح الدافع وراء التغيير
تقرير bug يساعد الآخرين على إعادة إنتاج المشكلة بسرعة
طريقة طرح السؤال تجعل النقاش يصل إلى اللب مباشرة
وصف PR يمكن المراجع من الدخول في السياق بسرعة

هذه الأمور لا تبدو "كأعمال تطوير أساسية"، لكنها تحدد ما إذا كان الفريق قادرًا على العمل بكفاءة عالية.

المهندس المتميز حقًا لا يكتب فقط كودًا، بل يكتب نية يمكن لمن يأتي بعده فهمها.

خاتمة

سيعمل الكود لفترة من الزمن، لكن آثار التواصل ستؤثر لوقت طويل.

تعليق تكتبه اليوم، أو شرح لتعديل، أو تقرير مشكلة، قد يوفر على زميل ما عدة ساعات بعد أشهر؛ وقد يوفر عليك أنت في المستقبل الكثير من الطرق المسدودة بعد سنوات.

لذا، لا تسأل نفسك فقط:

هل هذا الكود يمكنه أن يعمل؟

اسأل نفسك أيضًا:

عندما يرى الآخرون هذا التعديل، هل يمكنهم أن يفهموا بسرعة لماذا فعلت ذلك بهذه الطريقة؟

هنا، غالبًا، يبدأ النضج الهندسي الحقيقي بالظهور.