إضفاء عقلية صحية لمراجعة الكود إلى فريقك

"مراجعة الكود" هي لحظة في عملية التطوير حيث تعمل أنت (كمطور) وزملاؤك معًا وتبحث عن الأخطاء داخل جزء حديث من التعليمات البرمجية قبل إصدارها. في مثل هذه اللحظة ، يمكنك أن تكون إما مؤلف الكود أو أحد المراجعين.

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

في هذه المقالة ، سأشارك كيف يمكن تغيير هذه النتيجة عن طريق تغيير طريقة تفكيرك أثناء مراجعة الكود:

• كفريق
• كمؤلف
• كمراجع

العمل كفريق

عزز ثقافة التعاون

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

يجب أن يتبنى موقف وسلوك الفريق قيمة التعاون غير القضائي ، بهدف مشترك هو التعلم والمشاركة - بغض النظر عن تجربة شخص آخر.

قم بتضمين مراجعات الكود في تقديراتك

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

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

وفر الوقت مع الإرشادات والأتمتة

طريقة فعالة لضمان مساهمات متسقة هي دمج نموذج طلب السحب في المشروع. سيساعد هذا المؤلف في تقديم علاقات عامة صحية مع وصف كامل. يجب أن يشرح وصف العلاقات العامة ما هو الغرض من التغيير والسبب وراء ذلك وكيفية إعادة إنتاجه. لقطات الشاشة والروابط المرجعية (مشكلة Git ، ملف التصميم ، وما إلى ذلك) هي اللمسات الأخيرة لتقديم شرح ذاتي.

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

ابق طالبًا

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

"هاو دفاعي. يجد المحترف أن التعلم (وحتى الظهور أحيانًا) ممتع ؛ إنهم يحبون أن يتم تحديهم وتواضعهم ، والانخراط في التعليم كعملية مستمرة لا نهاية لها. (...) "

- ريان هوليداي ، الأنا هي العدو

ابق متواضعا لأنه في المرة الثانية التي تتوقف فيها عن أن تكون طالبًا ، تصبح معرفتك هشة.

فن اختيار المراجعين

في رأيي ، يعد اختيار المراجعين أحد أهم القرارات لمراجعة التعليمات البرمجية الفعالة والصحية كفريق.

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

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

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

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

تحلى بالتعاطف

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

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

تعرف على كيفية حل وسط

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

كن مرنًا ولكن عمليًا وتعرف على كيفية الموازنة بين الكفاءة (التسليم) والفعالية (الجودة). إنه حل وسط يتم إجراؤه كفريق. في هذه اللحظات ، أود التفكير في مراجعة الكود كتكرار وليس حلاً نهائيًا. هناك دائمًا مجال للتحسين في الجولة القادمة.

مراجعات الكود الشخصي

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

تعلم من نتائج مراجعة الكود

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

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

كمؤلف

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

إنشاء اتصال مبكر

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

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

اتبع الإرشادات

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

كن أول مراجع لك

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

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

كن صبورا

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

كن مستمعا

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

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

كمراجع

خطط قبل وقتك

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

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

كن داعما

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

تحقق من الفرع وتشغيله

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

اسأل قبل الافتراض

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

تناسب معظم الأسئلة هذين النوعين من الفئات:

1. أسئلة "كيف"
   عندما لا تفهم كيفية عمل شيء ما أو ما يفعله ، قم بالتقييم مع المؤلف إذا كان الرمز واضحًا بدرجة كافية. لا تخلط بين التعليمات البرمجية البسيطة والجهل. هناك فرق بين التعليمات البرمجية التي يصعب قراءتها والتعليمات البرمجية التي لا تعرفها. كن منفتحًا للتعلم واستخدام ميزة لغة جديدة ، حتى إذا كنت لا تعرفها بعمق حتى الآن. ومع ذلك ، استخدمه فقط إذا كان يبسط مصدر البرنامج.
2. أسئلة "لماذا"
   عندما لا تفهم "السبب" ، لا تخف من اقتراح التعليق على الكود ، خاصةً إذا كانت حالة حافة أو إصلاح خطأ. يجب أن يكون الرمز واضحًا بذاته عندما يتعلق الأمر بشرح ما يفعله. التعليقات مكملة لشرح السبب وراء اتباع نهج معين. يعد شرح السياق ذا قيمة عالية عندما يتعلق الأمر بقابلية الصيانة وسيوفر على شخص ما حذف كتلة من التعليمات البرمجية التي يعتقد أنها غير مجدية. (أنا شخصياً أحب التعليق على الكود حتى أشعر بالأمان بشأن نسيانه لاحقًا.)

النقد البناء

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

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

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

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

غير واضح: "يجب أن يكون هذا الرمز…."

الرأي: "أعتقد أن هذا الرمز يجب أن يكون ..."

الحقيقة: "باتباع [إرشاداتنا] ، يجب أن يكون هذا الرمز…".

• اشرح السبب.
  ما هو واضح بالنسبة لك ، قد لا يكون للآخرين. لا يتعلق الأمر أبدًا بشرح الدافع وراء ملاحظاتك كثيرًا ، لذلك لا يفهم المؤلف فقط كيفية تغيير شيء ما ولكن أيضًا ما هي الفائدة منه.

الرأي: "أعتقد أن هذا الرمز يمكن أن يكون ..."

أوضح: "أعتقد أن هذا الرمز يمكن أن يكون (...) لأن هذا سيحسن قابلية القراءة ويبسط اختبارات الوحدة."

• قدم أمثلة.
  عند مشاركة ميزة رمز أو نمط لا يعرفه المؤلف ، استكمل اقتراحك بمرجع كدليل. عندما يكون ذلك ممكنًا ، تجاوز مستندات MDN وشارك مقتطفًا أو مثالًا عمليًا تم تكييفه مع سيناريو الكود الحالي. عندما تكون كتابة مثال معقدًا للغاية ، فكن داعمًا واعرض المساعدة شخصيًا أو عبر مكالمة فيديو.

بالإضافة إلى قول شيء مثل "استخدام الفلتر سيساعدنا في [التحفيز]" ، قل أيضًا ، "في هذه الحالة ، يمكن أن يكون شيئًا مثل: [مقتطف الشفرة]. يمكنك التحقق من [مثال على Finder.js]. أي شك ، لا تتردد في الاتصال بي على Slack ".

• كن عقلانيا.
  إذا تم ارتكاب نفس الخطأ عدة مرات ، ففضل ترك تعليق واحد حوله وتذكر أن يراجع المؤلف في الأماكن الأخرى أيضًا. تؤدي إضافة التعليقات الزائدة عن الحاجة إلى حدوث تشويش فقط وقد يكون لها تأثير عكسي.

حافظ على التركيز

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

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

ضع توقعات

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

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

تعلم كيف ترفض مراجعة الكود

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

عندما تقبل مراجعة رمز شخص آخر ، فإن هذا الشخص يثق في قدراتك - إنه التزام. إذا لم يكن لديك الوقت الكافي لتكون مراجعًا ، فقط قل لا لزميلك (زملائك). انا حقا أعنى ذلك؛ لا تدع زملائك ينتظرون مراجعة الكود التي لن تتم أبدًا. تذكر التواصل والحفاظ على التوقعات واضحة . كن صادقًا مع فريقك - بل والأفضل - مع نفسك. مهما كان اختيارك ، افعل ذلك بشكل صحي وافعله بالشكل الصحيح.

خاتمة

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

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

مزيد من القراءة على SmashingMag:

• العمل معًا: كيف يمكن للمصممين والمطورين التواصل لإنشاء مشاريع أفضل
• تعاون أفضل من خلال إشراك المصممين في عملية مراجعة التعليمات البرمجية
• ما البودكاست الذي يجب على مصممي الويب والمطورين الاستماع إليه؟
• كيفية صياغة السيرة الذاتية المثالية لمطور الويب