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

هناك مجموعة من الأدوات لمراجعة التعليمات البرمجية في السوق مع سيناريوهات الاستخدام الجاهزة والتوصيات والقواعد. GitHub ، Phabricator ، FishEye / Crucible ، GitLab ، Bitbucket ، Upsource - القائمة تطول وتطول. في Badoo ، عملنا معهم أيضًا في وقت واحد: في مقالتي السابقة ، أخبرت قصتنا حول مراجعات الكود وكيف توصلنا إلى اختراع " دراجتنا " - حلول Codeisok .

هناك الكثير من المعلومات ، يمكنك google مجموعة من المقالات حول مراجعات الشفرة مع أمثلة حقيقية ، وممارسات ، ومناهج تتحدث عن مدى جودة ، ومدى السوء ، وكيفية القيام به ، وكيف - لست بحاجة إلى ذلك ، وما تحتاج إلى التفكير فيه ، وما لا تحتاج إليه ، وما إلى ذلك. هـ) بشكل عام ، فإن الموضوع "يمتص حتى العظم".

لهذا السبب قد لا يلاحظ الجزء الآخر من جبل الجليد.

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

بعد قراءة هذه المقدمة ، قد يكون لديك سؤال: ما هو المعقد في مراجعة الكود؟ النقطة تافهة. علاوة على ذلك ، فإن معظم الأدوات المذكورة أعلاه على الفور وتقدم مراجعة التدفق (خارج الصندوق: تعيين ، الالتزام / البدء - وانطلق!).

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

ذات مرة ، عندما كنت أعمل في شركة أخرى ، كنت غارقًا بشدة في المحادثة حول مراجعات الكود مع أحد المطورين الرائدين. كان p1lot . ربما يكون أحد القراء على دراية به (p1lot ، مرحبا :)). إنه يعمل معنا حاليًا في Badoo ، وهو أمر رائع.

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

لماذا أحتاج إلى عملية مراجعة التعليمات البرمجية؟

هل لديك مراجعة في شركتك؟ هل تفعل ذلك بشكل صحيح؟ لدي اختبار قد يجعلك تشك في ذلك.

تحتاج للإجابة على ثلاثة أسئلة فقط:

1. ما المدة التي تستغرقها مراجعة الكود لمهمة متوسطة (كروية في فراغ)؟
   
2. كيف تقلل وقت المراجعة؟
   
3. كيف يمكنك تحديد ما إذا كانت مراجعة مهمة معينة تتم بشكل صحيح؟
   

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

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

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

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

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

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


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

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

مراجعة رمز سيئة

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

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

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

تقاسم المعرفة

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


لقد سألت الناس مرارًا وتكرارًا عما يقصدونه بـ "مشاركة المعرفة". وردا على ذلك سمعت أشياء مختلفة.

أولاً ، هذا عرض توضيحي للقادمين الجدد (في الفريق أو المكون المتأثر) للقواعد والممارسات المقبولة: هذه هي الطريقة المعتادة بالنسبة لنا للقيام بذلك ، ونحن لا نفعل ذلك ، ولهذا السبب.

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

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

دعنا نراجع جميع النقاط ونحاول تقييم مدى صلتها بعملية المراجعة.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

مراجعة الكود كنظرة جديدة على الكود

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

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

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

من الواضح أنه لا ، لأن: 1) فعلنا دائمًا بدون صودا ، ولم تكن النتيجة سيئة ؛ 2) من الممكن أن يأخذ العملاء الكعك منا ، وليس من مخبز آخر ، لأنهم لا يحبون طعم الصودا ؛ 3) الكعكة جاهزة ، الزفاف الليلة ، ولن يكون لدينا الوقت لخبز كعكة جديدة.

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

يمكن أن يضر التنفيذ غير المدروس لأفضل الممارسات الموضحة في المقالات أو التقارير بالشركة والمنتج. "يتم إضافة الصودا إلى الكعك من قبل جميع اللاعبين الرئيسيين:" Bugle "،" Tracebook "،" Rile.ru "،" Yumdeks ". الجميع يفعل ذلك ". اذن ماذا؟ وبسبب هذا ، هل يجب على بيتيا أن يعالج على الفور إعادة تصميم لمهمة جاهزة بالفعل؟

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

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

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

مراجعة الكود كمقدمة لجزء من الكود

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

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


دعونا نلقي نظرة على الموقف من خلال عيون الشخص الذي كتب الرمز. , ?

, - (, , , ). , ? , . , , , .

, , , , . . , ?

, - . , - . , : , . , , , , .

, . , - ? — . , , .

, , , - . , . , , . , , , . . , - : , , .

? , , — . .

best practices « -» « , ». اذن ماذا؟ Best practices , , . , ? . , - , .

best practices, , . . — - , / — . « », « », « — , DI». ? ?

, , . , , — , .

, -, «», , - . ? - , , , . , . , .

-, « » «» , . -, . , , - , : ? . , , ( : , ).

, , . , , ( , ?).

— . , , . . ? bus factor , , - , .

, , , : , ?

— , , ?
— .
— ?
— .

. , ? , , , ? , , , — ?

, , , , , ?

, , , . , , .

, . , , , ( ), , ( , , , — , . .). , .

— , , , . ( , , . .) . — — .

Code review

« ?» . , , .

: - , , - , , . git blame , , , , , .

, , — , , , ( ) — . , , . . , ?


. ?

, , , . , , , . , - ( , ). , , — , , , .

, , . ? , .

, , , . , . , ? .

, , — , . ( )?

« - - » . , . .

: . .

, , . , . , .

, , — . , .

— . , . , . , .

, , :

? , , ? ? , , ? - , ? ? ? وهكذا دواليك.

, . , . , .

, , . , , , . , , , .

, best practices, . , , , , . . , , . , .

,

. , , . - , , - .

, , . , API- . , bus factor, .

, . .

- ? , . , . null , « ». .

, . , ? ?

-

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

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

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

الخلاصة

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

وأخيرًا ، سأقدم بعض النصائح الإضافية.

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

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

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

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

لكن القرار ، بالطبع ، يبقى معك.