عندما يتعلق الأمر بفحص الكود ، يميل الناس إلى التركيز على من يقوم بذلك. لكن المطور الذي كتب الكود يلعب دورًا مهمًا في العملية مثل المراجع. لا توجد توصيات تقريبًا لإعداد التعليمات البرمجية للفحص ، لذلك غالبًا ما يرتكب المؤلفون أخطاء بسبب الجهل.
تجمع هذه المقالة أفضل الممارسات للمشاركة في فحص الرمز كمؤلف. عند الانتهاء من القراءة ، ستبدأ في إرسال مثل هذه التغييرات التي لا تشوبها شائبة للمفتشين والتي سوف يحترقون بها من أجلك ، لا أقل
لكني لا أريد أن يتوهج مفتشو الأكواد بحب من أجلي
وسيظلون كذلك. تواضع نفسك. لم يشكو أحد في تاريخ البشرية حتى الآن وهو على فراش الموت من أنه كان محبوبًا جدًا خلال حياته.
لماذا تحسين فحص الكود؟
إن تعلم تقنيات التفتيش الفعالة سيجعل الحياة أسهل للمفتش والفريق والأهم أنت.
- عملية نقل المعرفة المعجلة. إذا قمت بإعداد مجموعة التغييرات الخاصة بك بشكل صحيح ، فسيتم جذب انتباه المفتش إلى المناطق التي تحتاج إلى النمو فيها ، بدلاً من العيوب الأسلوبية المملة. وعندما توضح أنك تقدر النقد البناء ، يبدأ المراجع في بذل المزيد من الجهد في التعليقات.
- مثال للآخرين. ستعمل الممارسات الجيدة لفحص الكود في التنفيذ على تعيين شريط لمن حولك. عادةً ما يتم اعتماد تقنيات جيدة ، مما يعني أنه سيكون من الأسهل بالنسبة لك عندما يرسل لك شخص من زملائك الرمز للمراجعة.
- الحد الأدنى من النزاعات. غالبًا ما يخلق فحص الكود توترًا في الفريق. إذا تعاملت مع الأمر بمسؤولية وبشكل متعمد ، فسوف تنشأ الخلافات بشكل أقل.
القاعدة الذهبية: قيمة وقت المراجع
يبدو هذا واضحًا ، لكنني غالبًا ما صادفت مؤلفين يعاملون المفتشين على أنهم متخصصون في مراقبة الجودة. لن يضرب هؤلاء الأشخاص إصبعًا للقبض على بعض الأخطاء على الأقل أو لإجراء مجموعة من التغييرات الملائمة للتحقق منها.
يأتي زملاؤك إلى العمل كل يوم بكمية محدودة من الاهتمام. إذا كرسوا بعضًا منه لك ، فلن يعود بإمكانهم إنفاق هذا المورد على مهامهم الخاصة. الاستفادة القصوى من وقتهم هي مسألة عدالة بسيطة.
تكون مراجعة الكود أكثر نجاحًا عندما يمكن للمشاركين الوثوق ببعضهم البعض. لن يدخر المفتش أي جهد إذا علم أنك ستأخذ ملاحظاته على محمل الجد. إذا كنت ترى الفاحص على أنه عقبة يجب التغلب عليها ، فستتلقى توصيات أقل قيمة منه.
تقنية
1. راجع الرمز بنفسك
أولاً قبل إرسال الرمز إلى زميل ، اقرأه. لا تقصر نفسك على اكتشاف الأخطاء - تخيل رؤية هذا الجزء لأول مرة. ما الذي يمكن أن يكون مربكا في ذلك؟
من واقع خبرتي ، قد يكون من المفيد أخذ قسط من الراحة بين كتابة الكود وتحريره. غالبًا ما يرسل الأشخاص جزءًا جديدًا من الكود في نهاية اليوم ، ولكن خلال هذه الفترة من المرجح أن يفوتوا شيئًا بسبب الإهمال. انتظر حتى الصباح ، ألق نظرة جديدة على مجموعة التغييرات ، ثم انقلها إلى زميل.
ما أحمق كتب ذلك؟
مزامنة وظائف Cron مع الدورة القمرية: أضفت منطقًا متزامنًا للحفاظ على انسجام
خط أنابيب ETL مع الطبيعة. قم بمحاكاة بيئة عمل المدقق قدر الإمكان. استخدم نفس الأداة المساعدة للمقارنة كما فعل. تم العثور على أخطاء غبية في هذه الأدوات بشكل أفضل من محرر الكود العادي.
لا تتوقع أن تكون مثاليًا. سترسل حتمًا الرمز بقطعة نسيت حذفها بعد إصلاح خطأ ، أو ملفًا ضالًا كنت تنوي إزالته. إنها ليست نهاية العالم ، لكنها لا تزال تستحق المتابعة. لاحظ الأنماط في أخطائك واكتشف الأنظمة التي يمكنك تنفيذها لمنعها. إذا كانت الأخطاء نفسها تتكرر كثيرًا ، فسيستنتج المفتش أنك لا تقدر وقته.
2. اكتب وصفًا واضحًا لمجموعة التغييرات
في وظيفتي الإرشادية الأخيرة ، عقدت اجتماعات من حين لآخر مع مبرمج أكثر خبرة. قبل الاجتماع الأول ، طلب مني الحصول على مستند تصميم البرنامج الذي جمعته. عندما سلمته الأوراق ، شرحت ما هو المشروع وكيف يرتبط بأهداف فريقي. عبس معلمي وقال بصراحة: "كل ما قلته للتو يجب أن يكون في الصفحة الأولى من الوثيقة".
وكان على حق. لقد كتبت المستند مع توقع المطورين من فريقي ، لكن لم أضع في الاعتبار أنه قد يقرأه أشخاص خارجيون. لم يكن الجمهور مقيدًا بحدود إدارتي - لا يزال هناك فرق شريكة وموجهون وأشخاص اتخذوا قرارات بشأن الترقيات... يجب أن تكون الوثيقة مكتوبة بحيث يكون كل شيء واضحًا لهم. بعد هذه المحادثة ، أحاول دائمًا تقديم عملي في السياق الضروري للفهم.
يجب أن يتضمن وصف مجموعة التغييرات أي معلومات أساسية قد يحتاجها القارئ. حتى إذا كنت تكتب وصفًا لاستهداف المراجع ، فضع في اعتبارك أنه قد يكون لديه معلومات سياقية أقل مما تعتقد. بالإضافة إلى ذلك ، من الممكن أن يضطر الزملاء الآخرون أيضًا إلى العمل مع هذا الرمز في المستقبل - عند عرض محفوظات التغييرات ، يجب أن يكونوا واضحين بشأن نواياك.
يوضح الوصف الجيد الغرض من مجموعة التغييرات ولماذا اخترت القيام بذلك بهذه الطريقة.
إذا كنت تريد التعمق في فن كتابة الأوصاف الرائعة ، فاقرأ " كيفية كتابة رسالة Git Commit " لكريس بيمز و " Git الالتزام المفضل لدي " بقلم ديفيد طومسون.
3. أتمتة الأشياء البسيطة
إذا كنت تعتمد على المفتش في أشياء صغيرة مثل الدعامة العائمة أو مشاكل في الاختبارات الآلية ، فأنت بذلك تضيع وقته.
تحقق مما إذا كان كل شيء على ما يرام مع بناء الجملة؟ أود اللجوء إلى المترجم ، لكن من المؤسف أن يضيع وقته.
يجب اعتبار الاختبارات الآلية جزءًا من الإجراء القياسي كجزء من الفريق. يبدأ الاستقصاء فقط عند اجتياز سلسلة الفحوصات الآلية بالكامل في بيئة تكامل مستمرة.
إذا كان فريقك متوهمًا بشكل مأساوي ويرفض الاندماج المستمر ، فقم بإعداد الخروج الآلي في المنزل. قم بتطبيق الخطافات والخطابات والمنسقات المسبقة في بيئة التطوير الخاصة بك لضمان اتباع جميع الاصطلاحات واستمرار السلوك المقصود من الالتزام.
4. تأكد من أن الكود نفسه يجيب على الأسئلة
ما الخطأ في هذه الصورة؟
لا أفهم الغرض من الوظيفة.
وهذا في حالة تمرير Frombobulator عند الاتصال في حالة عدم وجود تنفيذ frombobulate. ساعدني
المؤلف في معرفة الوظيفة ، ولكن ماذا عن القارئ التالي؟ التعمق في تاريخ التغييرات وإعادة قراءة جميع المناقشات؟ بل إن الأمر أسوأ عندما يأتي المؤلف إلى مكتبي ليشرح كل شيء شخصيًا. أولاً ، إنه يمنعني من التركيز ، وثانيًا ، لن تتمكن أي روح حية من الوصول إلى المعلومات الصوتية بعد الآن.
عندما يعبر المفتش عن ارتباكه بشأن نقطة في الكود ، فإن وظيفتك ليست توضيح الموقف لذلك الشخص. من الضروري توضيح الموقف للجميع دفعة واحدة.
- مرحبا؟
- عندما كتبت bill.py قبل ستة أعوام ، لماذا كان لديك t = 6؟
- سعيد أنك اتصلت! هذا بسبب ضريبة المبيعات 6٪.
- بالطبع!
- طريقة رائعة لتبرير قرار التنفيذ.
أفضل إجابة على أي سؤال هو إعادة هيكلة الكود الذي يزيله. ما الذي يمكن إعادة تسميته لتوضيح كيفية تغيير المنطق؟ تعتبر التعليقات حلاً مقبولاً ، لكنها تخسر بالتأكيد على خلفية التعليمات البرمجية التي توثق نفسها بشكل طبيعي.
5. أدخل التغييرات كسور
تعد الحدود المترامية الأطراف ممارسة سيئة ويمكن رؤيتها غالبًا عند فحص الكود. يتعهد المطور بإصلاح خطأ في المنطق ، ولكن على طول الطريق يواجه بعض العيوب في الواجهة. "حسنًا ، بما أنني أعمل مع هذه القطعة على أي حال ،" يفكر ، "سأصلحها في نفس الوقت." نتيجة لذلك ، يبدأ الارتباك. سيتعين على المراجع الآن معرفة التغييرات التي تعمل للمهمة "أ" وأي التغييرات تعمل للمهمة "ب".
تقوم أفضل التغييرات بعمل شيء واحد . كلما كان التغيير أكثر دقة وبساطة ، كان من الأسهل على المفتش مراعاة السياق. من خلال مشاركة التغييرات غير ذات الصلة ، يمكنك أيضًا الحصول على القدرة على مراجعة العديد من الأقران بالتوازي ، وبالتالي ستعود الشفرة إليك بشكل أسرع.
6.
تغييرات وظيفية وغير وظيفية منفصلة تتبع قاعدة أخرى من قيود القياس - يجب عدم خلط التغييرات الوظيفية وغير الوظيفية.
غالبًا ما يخالف المطورون ذوو الخبرة القليلة في فحص الكود هذه القاعدة. يقومون بإجراء نوع من التغيير التفصيلي ، ويقوم محرر التعليمات البرمجية على الفور بتغيير التنسيق في جميع أنحاء الملف. إما أن المطور لا يفهم ما حدث ، أو يقرر أنه أفضل ويرسل كودًا حيث يتم دفن تغيير وظيفي واحد تحت مئات الأسطر من غير وظيفية.
هل ستجد تغيير وظيفي؟
مثل هذا الالتباس مثل البصق في وجه المفتش. من السهل التحقق من تغييرات التنسيق فقط. تغييرات وظيفية أيضا. يمكن أن يكون هناك انهيار وظيفي واحد في محيط تغييرات التنسيق ضائعًا ومجنونًا.
بالإضافة إلى ذلك ، يحب المطورون دمج إعادة البناء في تغييرات كبيرة في الوقت المناسب. أوافق بشدة على إعادة هيكلة الكود من جانب الزملاء ، ولكن ليس عندما يطبقون سلوكًا جديدًا في نفس الوقت.
التغيير السلوكي المدفون في خضم إعادة البناء
إذا احتاج جزء من التعليمات البرمجية إلى إعادة بناء وتغييرات في السلوك ، فأنت بحاجة إلى تقسيم العملية إلى مجموعتين أو ثلاث مجموعات:
- إضافة اختبارات للسلوك الحالي (إذا لم تكن موجودة)
- أعد بناء الكود دون تغيير أي شيء في الاختبارات
بالحفاظ على الاختبارات سليمة في المرحلة الثانية ، يمكن للمراجع التأكد من أن إعادة البناء لا تنتهك السلوك. وفقًا لذلك ، في المرحلة الثالثة ، لن يضطر إلى معرفة ما هو إعادة البناء هنا ، وما الذي يعمل على تغيير السلوك - بعد كل شيء ، قمت بفصل أحدهما عن الآخر مسبقًا.
7. تفكيك مجموعات التغييرات الكبيرة جدًا
مجموعات التغييرات المتضخمة تشبه أبناء العمومة القبيحين للحدود المترامية الأطراف . تخيل موقفًا: توصل المطور إلى استنتاج مفاده أنه من أجل تنفيذ الوظيفة A ، عليه أولاً تصحيح دلالات المكتبات B و C. إذا كانت هناك تغييرات قليلة ، فبغض النظر عن أي شيء ، ولكن في كثير من الأحيان تنتشر هذه التعديلات ويكون الناتج عبارة عن قائمة ضخمة من التغييرات.
يزداد تعقيد سجل التغيير أضعافًا مضاعفة مع عدد الصفوف المتأثرة. إذا كانت التغييرات تؤثر على 400 سطر أو أكثر ، فأنا أبحث عن طريقة لتقسيمها قبل طلب الفحص.
ربما بدلاً من القيام بكل شيء في وقت واحد ، سيكون من الممكن أولاً العمل مع التبعيات ، وفي المجموعة التالية ، تنفيذ وظائف جديدة؟ هل من الواقعي الاحتفاظ بالشفرة عاقلة إذا نفذت نصف الوظائف الآن والنصف الآخر في المرحلة التالية؟
قد يكون التفكير في كيفية تفكيك الكود للحصول على قطعة عاملة وواضحة مملة. لكن هذا يسمح بتعليقات أفضل ويخلق تعقيدًا أقل للمراجع.
8. تقبل النقد بلطف
أضمن طريقة لإفساد الاختبار برمته هي التعامل مع النقد بعدائية. قد يكون من الصعب المقاومة ، لأن العديد من المطورين يفتخرون بما يفعلونه ويعتبرون عملهم امتدادًا لأنفسهم. وإذا أدلى المفتش بتعليقات غير لباقة أو ذهب إلى شخص ما ، فإن هذا يزيد الأمر تعقيدًا.
في النهاية ، أنت ، بصفتك المؤلف ، لك الحرية في تحديد كيفية الرد على التعليقات. تعامل مع كلمات المفتش على أنها مناقشة موضوعية للرمز لا علاقة له بتقييم شخصيتك. إذا أصبحت دفاعيًا ، فسيزداد الأمر سوءًا.
أحاول أخذ أي تعليقات كمحاولة للمساعدة والاستفادة. إذا وجد المراجع خطأ غبيًا في الكود ، فإنني منجذبة غريزيًا لبدء تقديم الأعذار. لكنني أتراجع وأثني على ملاحظته بدلاً من ذلك.
- في شهري يناير وفبراير 1900 ، لن تنجح.
- بالضبط ، لاحظ جيدا!
ومن الغريب أنها علامة جيدة على أن المفتش وجد عيوبًا غير واضحة في الكود. يشير هذا إلى أنك جيد في تحضير الملفات للمسح الضوئي. في حالة عدم وجود تنسيق غير دقيق ، وأسماء سيئة ، وأشياء أخرى واضحة ، يمكن للمراجع دراسة المنطق والتصميم بعمق وتقديم ملاحظات أكثر قيمة.
9. التحلي بالصبر إذا أخطأ المفتش
يحدث من وقت لآخر أن المفتش ببساطة مخطئ. يمكن أن يخطئ في قراءة الكود العادي تمامًا كما يمكنك زرع الأخطاء. يبدأ العديد من المطورين في مثل هذه الحالات في الدفاع عن أنفسهم بشدة. لقد شعروا بالإهانة لأن شخصًا ما ينتقد عملهم ، وحتى لا يقوم على أي شيء.
ومع ذلك ، على الرغم من أن المراجع مخطئ ، فلا يزال لديك الكثير لتفكر فيه. إذا أساء قراءة شيء ما ، ما هو احتمال أن يرتكب الآخرون الخطأ نفسه في المستقبل؟ ألن يضطر القراء إلى دراسة الشفرة ذهابًا وإيابًا ، فقط للتأكد من أن الخطأ الذي يرونه ليس هنا؟
- يوجد تجاوز سعة المخزن المؤقت هنا ، لأنه لم يتم إجراء التحقق مما إذا كانت هناك ذاكرة كافية بالاسم لاستيعاب جميع أحرف NewNameLen.
- هل هو في الكود الخاص بي؟ لا يمكن تصوره! يقوم المُنشئ باستدعاء PurchaseHats ، ويستدعي CheckWeather ، مما قد يؤدي إلى حدوث خطأ إذا لم يتطابق طول المخزن المؤقت. ستقرأ أولاً 200000 سطر من التعليمات البرمجية ثم تجرؤ على الاعتراف باحتمال أنني كنت مخطئًا في مكان ما.
فكر في كيفية إعادة البناء ، أو إضافة تعليقات بحيث يمكنك في لمحة سريعة أن تفهم أن كل شيء على ما يرام. إذا كان سوء الفهم ناتجًا عن استخدام ميزات غير معروفة للغة ، فأعد كتابة الكود باستخدام آليات لا تتطلب معرفة شاملة.
10. إعطاء رد فعل واضح
غالبًا ما أجد نفسي في هذا الموقف: أرسل تعليقات إلى شخص ما ، يقوم بتحديث الكود مع مراعاة بعض منها ، لكنه يظل صامتًا في نفس الوقت. هناك فترة من عدم اليقين. إما أنه فاته بقية التعليقات ، أو أنه لا يزال في طور التصحيح. إذا بدأت في التحقق مما تم إنجازه بالفعل ، من الناحية الافتراضية ، فقد يتضح أن هذا الجزء من الكود لا يزال قيد العمل وأنني أضيع وقتي. إذا انتظرنا ، يمكننا أن نصل إلى طريق مسدود - سنجلس وننتظر الخطوة التالية من بعضنا البعض.
ضع نظامًا معينًا من الإجراءات في الفريق بحيث يكون من الواضح دائمًا من لديه "عصا القيادة" في الوقت الحالي. لا ينبغي السماح للعملية بالتباطؤ فقط لأن لا أحد يفهم ما يحدث على الإطلاق. من السهل القيام بذلك - ما عليك سوى ترك التعليقات على مستوى مجموعة التغييرات ، والذي يتضح منه متى يتم نقل الحق في التصرف إلى مشارك آخر.
تصحيح الرؤوس> تحديث الكود وفقًا للتعليقات> كل شيء جاهز ، من فضلك انظر
أي تعليق يتطلب منك اتخاذ إجراء يجب الرد عليه من خلال تأكيد أنك قد اتخذت ذلك. توفر بعض أدوات فحص التعليمات البرمجية القدرة على وضع علامة على التعليقات التي تمت معالجتها. إذا لم يكن كذلك ، فاستخدم مجموعة من الرموز النصية البسيطة مثل تم. إذا كنت لا توافق على التعليق ، اشرح بأدب لماذا قررت الامتناع عن التصحيح.
تقترح بعض الأدوات مثل Reviewable و Gerritt وضع علامات على التعليقات المعالجة
. وازن ردود أفعالك مقابل جهود المراجع. إذا كان قد أوضح لحظة لتتعلم شيئًا جديدًا لنفسك ، فلا تقصر نفسك على علامة "تم". أجب بعناية لتظهر أنك تقدر عمله.
11. التماس المعلومات المفقودة بمهارة
أحيانًا تترك تعليقات المفتش مجالًا كبيرًا للتفسير. عندما يكتبون لك شيئًا بروح "أنا لا أفهم هذه الوظيفة" ، فإن السؤال الذي يطرح نفسه على الفور ، ما هو بالضبط غير واضح للشخص. طويل جدا؟ هل الاسم مؤسف؟ هل تحتاج إلى توثيق أفضل؟
تساءلت لفترة طويلة عن كيفية توضيح التعليقات الغامضة وفي الوقت نفسه عدم الدخول في المواجهة عن غير قصد. أول ما خطر ببالي هو أن أسأل: "ما الذي لا يمكن فهمه فيها؟" ، لكن هذا يبدو غاضبًا.
لقد أرسلت ذات مرة ردًا غامضًا عمدًا على هذا النوع من الزملاء ، ونزع سلاحي بإجابته:
"ما الذي يمكن تغييره لجعله أفضل؟"
تعجبني هذه العبارة لأنها تعبر عن الانفتاح على النقد وقلة العداء. الآن ، عندما أحصل على تعليقات غامضة ، أجيب مع بعض الاختلافات في الدافع الأساسي "ما الذي يجب تغييره لجعله أفضل؟"
أسلوب آخر مفيد هو محاولة تخمين ما قصده المراجع وأخذ زمام المبادرة في تصحيح الكود وفقًا لذلك. إذا تلقيت تعليقًا "غير مفهوم" ، فقم بإلقاء نظرة فاحصة على الكود. عادة ما يتم العثور على شيء يمكن تحسينه من حيث الوضوح. تتيح التعديلات للمفتش معرفة أنك مستعد لإجراء تغييرات ، حتى لو كانت لديه فكرة مختلفة عن النتيجة النهائية.
12. إعطاء الأولوية للمراجع
في لعبة التنس ، إذا لم يكن واضحًا تمامًا ما إذا كانت الكرة قد خرجت من الحدود عند إرسال الخصم ، فمن المعتاد تفسير الموقف لصالحه. يجب أيضًا اتباع هذه القاعدة عند فحص الكود الخاص بك.
بعض قرارات التصميم هي مسألة ذوق. إذا اعتقد المراجع أنه من الأفضل تقسيم وظيفة العشرة أسطر إلى وظيفتين من خمسة أسطر ، فإن الحقيقة الموضوعية ليست ملكك ولا ملكه. الخيار الأفضل يعتمد على التفضيل.
إذا قدم المفتش عرضًا وكانت الحجج الداعمة لموقفه متساوية تقريبًا بالنسبة لك ، فقبل وجهة نظره. بعد كل شيء ، من بينكما ، هو الشخص الذي يستفيد من نظرة جديدة على الكود.
13. تقليل وقت نقل الكود
قبل بضعة أشهر ، أجرى مستخدم تغييرًا بسيطًا على مشروع مفتوح المصدر أحافظ عليه. لقد ألغيت اشتراكي مع التعليقات بعد بضع ساعات ، لكنه اختفى بالفعل مع النهايات. عدت بعد أيام قليلة ووجدت أنه لا يوجد رد حتى الآن.
بعد ستة أسابيع ، ظهر المطور الغامض في المشروع مع التنقيحات. على الرغم من أنني أقدر عمله ، إلا أن الفاصل الطويل بين مرحلتي التحقق أدى إلى حقيقة أنني بذلت ضعف الجهد في التفتيش. اضطررت إلى إعادة قراءة ليس فقط الكود ، ولكن أيضًا تعليقاتي الخاصة لتذكر ما تمت مناقشته بشكل عام. إذا ظهر الشخص في غضون يومين ، فلن تكون هناك حاجة لعمل إضافي.
التكاليف الفكرية لفحص الكود مع أوقات الإرسال القصيرة (اليسرى) والطويلة (اليمنى)
على المحور X - الوقت ؛ المحور الصادي - ذاكرة المفتش ؛ التظليل الأزرق - استعادة السياق ؛ التعبئة الزرقاء - فحص الكود ؛ ملء رمادي - انتظار تظليل أحمر - تكاليف إضافية
ستة أسابيع هي ، بالطبع ، حالة استثنائية ، لكنني غالبًا ما أرى فترات توقف طويلة وغير مبررة في فريقي. يرسل شخص ما مجموعة من التغييرات للمراجعة ، ويحصل على ملاحظات ، ويؤجل عمليات التحرير لمدة أسبوع لأن مهمة أخرى تشتت انتباهه.
بالإضافة إلى حقيقة أنه يتعين عليك فيما بعد قضاء بعض الوقت في استعادة السياق ، فإن أجزاء التعليمات البرمجية شبه النهائية تخلق تعقيدًا. إنهم يجعلون من الصعب تتبع ما تم استنزافه بالفعل وما لم يتم استنزافه بعد. كلما تم إنتاج قوائم التغيير التي تمت معالجتها جزئيًا ، زادت احتمالية تعارضات الدمج ، ولا يحب أحد العبث بها.
بمجرد إرسال الرمز الخاص بك للفحص ، فإن أولويتك القصوى هي المتابعة. إذا تعطلت العملية بسبب خطأك ، فأنت تسرق الوقت من المفتش وتعقد حياة الفريق بأكمله.
أخيرا
أثناء تحضيرك لسجل التغيير التالي للإرسال ، ضع في اعتبارك العوامل التي يمكنك معالجتها واستخدم هذه الفرص لجعل المراجعة مثمرة. أثناء مشاركتك في مراجعة الكود ، تحقق من الأشياء التي تؤدي بانتظام إلى إبطاء العملية وإهدار الموارد.
تذكر القاعدة الذهبية: قيم وقت المراجع. إذا منحته الفرصة للتركيز على الأجزاء الشيقة حقًا من الكود ، فستكون تعليقاته مفيدة. إذا أجبرته على إضاعة الوقت في أشياء صغيرة أو كشف الارتباك ، فسيكون ذلك أسوأ بالنسبة لكليكما.
أخيرًا ، فكر جيدًا في إجاباتك. يمكن أن يؤدي سوء التفاهم بشأن الأشياء التافهة أو الكلمات الطائشة إلى إخراج الأشياء عن مسارها بسرعة تنذر بالخطر. تتصاعد المشاعر عندما يتعلق الأمر بانتقاد عمل شخص آخر ، لذا تجنب بحذر أي شيء قد يدفع الفاحص إلى الاعتقاد أنك تهاجمه أو تعامله دون احترام مناسب.
تهانينا! إذا كنت قد قرأت هذا الحد ، فقد تعتبر نفسك بالفعل خبيرًا في فحص الكود. من المرجح أن يكون المفتشون لديك مشتعلون بالفعل ، لذا يجب أن تعاملهم معاملة إنسانية.