في الموضوع السابق تحدّثنا عن الأهداف التي يجب مراعاتها عند إجراء مراجعة للكود. أما في هذا الموضوع، فسوف نتحدّث عن بعض الاقتراحات حول كيفيّة تحويل مراجعة الكود وجَعْلها تجربة إيجابيّة وتعاونيّة من خلال بعض الأمور التي يجب أن لا تفْعَلها.

لا تفْعَل

يقول إريك ديتريش في مقاله What To Avoid When Doing Code Reviews:

إنّ فهْم ما يجب تجنّبه في مراجعة الكود يمكن أن يعني الفرْق بين مراجعتك للكود باعتبارها جزءًا مهمًا من مُخرَجات فريقك أو أن تكون مراجعتك للكود عبارة عن عقوبة قاسية وغير عاديّة.

قد تبدو هذه القائمة الطويلة من السلوكيات السيئة سلبية بعض الشيء. لكن بصراحة، من المفترض أن تكون نظرتنا للموضوع بشكل إيجابي. هناك العديد من الطرق لجعل مراجعة الكود مزعجة عن طريق القيام بأشياء خاطئة. لذلك في اعتقادي أن معرفة ما لا يجب فعله هو مكان جيّد للبدء. مراجعة الكود القتاليّة وغير اللطيفة وغير المتوقعة يمكن أن تجعل المبرمجين غير سعداء.

• لا تقم فقط بمراجعة الكود بشكل مباشر ومحدود

لا تكن صريحًا وبسيطًا وتُشير فقط إلى الأشياء الخاطئة في الكود وتقول ما تريد تغييره ولا شيء أكثر من ذلك. يقضي المبرمجون الكثير من الوقت ويفخرون بالكود الخاص بهم ومراجعة الكود هي فرصة لهم لعرْض ذلك. مع هذا النوع من مراجعة الكود المباشر والمحدود، فإن أفضل نتيجة يمكن أن يأمل المبرمج في الحصول عليها هي عدم وجود ملاحظات.

• لا تعتقد أن انتقاد الكود وليس المبرمج كافي

ربما تكون انتقاد الكود وليس المبرمج هي النصيحة الأكثر شهرة حول كيفية إجراء مراجعة للكود. إنها نصيحة جيّدة (إذا كنت تنتقد زملائك في الفريق كأشخاص بدلاً من التحدّث عن الكود فلديك مشكلة). ولكن هذا لا يكفي وعليك أن تجد طريقة أكثر إيجابية لتقديم اقتراحات حول الكود.

• انتبه لنبرة صوتك
  • لا تستخدم النبرة الشخصية عند الانتقاد: عبارات مثل لماذا قمْتَ بـ …؟ إلخ تُشعِر المبرمج وكأنّه هجوم. بدلاً من قوْل الطريقة التي كتبت بها هذه الوظيفة (function) تجعل من الصعب قراءتها، أضف المزيد من التعليقات على الكود (وهو أمر شخصي تمامًا ويشير إلى أن الشخص قد فعل شيئًا خاطئًا)، قُلْ هل تعتقد أن إضافة المزيد من تعليقات الكود (comments) ستؤدي إلى جعل هذه الوظيفة (function) أسهل في القراءة؟ (وهو ما يجعل المبرمج يركّز على ما يمكنه فعله لتحسين الكود).
  • لا تستخدم لغة متطلّبة أو صعبة: تجنّب العبارات التي يأتي معناها أنت مخطئ. لا تخبر الناس بأنهم مخطئون أو أن ما قالوه غير صحيح لأنه قد يجعلهم يشعرون بالهجوم. إذا شعروا بالهجوم، فيمكن للناس أن يصبحوا دفاعيّين ولا يمكنهم الانخراط بشكل إبداعي والتوقّف عن التعلّم. تجنب عبارات مثل هذا خطأ تمامًا.
  • لا تستخدم المبالغة عند توجيه الانتقادات: لا تريد أن يشعر المبرمج بالإهانة لأنه يشعر أن انتقاداتك للكود غير مبرّرة أو مُبالغ فيها.
  • لا تستخدم لغة مُهينة: تجنّب الإهانات العرضية من خلال عدم استخدام كلمات مثل غبي في مراجعة الكود على الرغم من أنك لا تقصدها على أنّها إهانات. هذا النوع من اللغة يحمل سياقات وارتباطات ويمكن أن يحدّد الإطار الذهني للشخص الذي يستقبلها.
  • لا تستخدم لغة غير صبورة أو عدوانية سلبية: احرص دائمًا على التحلّي بالصبر والود وتجنّب العبارات غير السارّة التي تُظهر التهيّج وتجعل الناس يشعرون وكأنهم لا يقومون بعمل جيد بما فيه الكفاية.
  • لا تراكم التعليقات: يمكن أن يجعل شخصًا ما يشعر بالهجوم إذا أعطاه أحد الزملاء تعليقًا نقديًا ثم قام زميل أو أكثر بإعطائه نفس التعليق والزيادة عليه. العديد من النقد قد يكون مربكًا للشخص.

• لا تكن مبرمجًا في المقعد الخلفي

هذا يعني التوقف وعدم طلب العديد من تغييرات الكود التي قد تميل إلى طلبها. التعليقات التي تطلب الكثير من التغييرات وتُشعِر وكأنها إعادة كتابة للكود يمكن أن تكون مُحبِطة. لذا فكّر في اقتراحاتك بعناية واختر الأفضل منها.

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

• لا تقل أشياء لمجرّد سماع صوتك

قبْل إبداء الملاحظات، فكّرْ في ما تهدف إلى تحقيقه من خلال القيام بذلك وفكّرْ فيما إذا كانت كل ملاحظة ضروريّة أم لا. تذكّرْ أنك تحاول تقديم المساعدة البنّاءة وليس محاولة توضيح نقطة. عند كتابة مراجعة للكود، أعود وأراجع تعليقاتي قبل نشرها وأسأل نفسي ما إذا كان كل تعليق مفيدًا أم ضروريًا حقًا وينتهي بي الأمر بحذف العديد من تعليقاتي قبل نشر المراجعة.

• لا تعتقد أنه يجب عليك العثور على مشكلة في كل مراجعة للكود

إذا كان الكود جيدًا ويمكن دمجه مع باقي الأكواد دون أي تغييرات فلا بأس بذلك!

في الموضوع القادم إن شاء الله نكْمل الحديث عن بعض الاقتراحات حول كيفيّة تحويل مراجعة الكود وجعْلها تجربة إيجابية وتعاونيّة وما يمكنك فِعْلُه.

بالتوفيق للجميع…

* المصدر: https://www.seanh.cc/2016/10/04/code-review

** الصورة من موقع: https://portswigger.net