كيف تتم مراجعة الكود عادة؟ يمكنك إرسال طلب تجمع وتلقي ملاحظات وإجراء تصحيحات وإرسال إصلاحات للمراجعة الثانية ثم الحصول على الموافقة ويحدث الدمج. يبدو الأمر بسيطًا ، ولكن في الواقع قد تستغرق عملية المراجعة وقتًا طويلاً للغاية.
تخيل أن لديك طلب تجمع مع مئات خطوط التغيير. يجب أن يقضي المراجع الكثير من الوقت لقراءة التعليمات البرمجية بالكامل وفهم التغييرات المقترحة. نتيجة لذلك ، قد تستغرق العملية برمتها من إنشاء طلب تجميع إلى موافقته عدة أيام - وهذا ليس ممتعًا للغاية لكل من المراجع ومؤلف التغييرات. وهناك احتمالات جيدة لأن المراجع في النهاية سوف يضيع شيئًا ما. أو قد يكون الشيك سطحيًا للغاية ، وفي أسوأ الحالات ، يمكن رفض طلب البلياردو على الفور.
اتضح أنه كلما كبر طلب التجمع ، كانت الفائدة أقل من التحقق من ذلك.
كيفية تجنب مثل هذه الحالات؟ كيفية جعل طلب التجميع أسهل وأكثر قابلية للفهم للمراجع وتحسين العملية برمتها؟
نحن نترجم مقالًا عن مطور الواجهة الخلفية لدينا ، سيرجي جوك ، حول كيفية عمل عملية مراجعة الكود الخاصة بفريق تطبيقات الأجهزة المحمولة Sky Sky.
تغيير الفئات
دعونا نتخيل أن لديك مهمة - لتنفيذ وظائف جديدة في المشروع. قد يحتوي طلب التجمع الذي تعمل عليه على فئات مختلفة من التغييرات. بالطبع سيكون هناك كود جديد فيه. ولكن في سياق العمل ، قد تلاحظ أن بعض التعليمات البرمجية تحتاج إلى إعادة تشكيلها مسبقًا حتى تساهم في إضافة وظائف جديدة. أو باستخدام هذه الوظيفة الجديدة ، ظهر التكرار في التعليمات البرمجية التي تريد القضاء عليها. أو وجدت فجأة خطأ وتريد إصلاحه. كيف ينبغي أن يبدو طلب البلياردو النهائي؟
أولاً ، دعونا نلقي نظرة على فئات التغييرات التي يمكن أن تحدث بالشفرة.
- التغييرات الوظيفية.
- إعادة هيكلة الهياكل - التغييرات في الفصول والواجهات والأساليب والحركة بين الفصول.
- إعادة بناء بسيطة - يمكن تنفيذها باستخدام IDE (على سبيل المثال ، استخراج المتغيرات / الأساليب / الثوابت ، وتبسيط الشروط).
- إعادة تسمية ونقل الفصول - إعادة تنظيم مساحة الاسم.
- إزالة غير المستخدمة (ميت) رمز.
- نمط رمز التصحيحات.
مراجعة الاستراتيجية
من المهم للغاية أن نفهم أن كل فئة من هذه الفئات تتم مراجعتها بشكل مختلف وعند النظر فيها ، يجب أن يركز المراجع على أشياء مختلفة. يمكن القول أن كل فئة من فئات التغيير تنطوي على إستراتيجية المراجعة الخاصة بها.
- التغيير الوظيفي: حل مشاكل العمل وتصميم النظام.
- إعادة هيكلة الهياكل: التوافق الخلفي وتحسين التصميم.
- إعادة بناء المساكن: تحسين قابلية القراءة. يمكن إجراء هذه التغييرات بشكل أساسي باستخدام IDE (على سبيل المثال ، استخراج المتغيرات / الأساليب / الثوابت ، وما إلى ذلك).
- إعادة تسمية / نقل الفئات: هل تم تحسين بنية مساحة الاسم؟
- إزالة التعليمات البرمجية غير المستخدمة: متوافق مع الإصدارات السابقة.
- نمط التعليمات البرمجية التصحيحات: يحدث في الغالب دمج طلب تجمع على الفور.
يتم استخدام طرق مختلفة للتحقق من التغييرات في الفئات المختلفة ، وبالتالي يختلف أيضًا مقدار الوقت والجهد المبذول في المراجعة.
التغييرات الوظيفية. هذه هي أطول عملية لأنها تنطوي على تغيير منطق المجال. يتطلع المراجع إلى معرفة ما إذا كان قد تم حل المشكلة والتحقق مما إذا كان الحل المقترح هو الأنسب أم يمكن تحسينه.
إعادة هيكلة الهيكلية. تتطلب هذه العملية وقتًا أقل بكثير من التغييرات الوظيفية. ولكن قد تكون هناك اقتراحات وخلافات حول كيفية تنظيم الكود بالضبط.
عند التحقق من الفئات المتبقية في 99 ٪ من الحالات ، يحدث الدمج على الفور.
- إعادة بناء بسيطة. هل أصبح الكود أكثر قابلية للقراءة؟ - merzhim.
- إعادة تسمية / نقل الطبقات. هل تم نقل الفصل إلى مساحة اسم أفضل؟
- إزالة غير المستخدمة (ميت) رمز هو merzhim.
- تصحيحات رمز النمط أو التنسيق - merzh. يجب على زملائك عدم التحقق من ذلك أثناء مراجعة التعليمات البرمجية ، فهذه هي مهمة linter.
لماذا يجب تصنيف التغييرات؟
لقد ناقشنا بالفعل أنه يتم مراجعة فئات مختلفة من التغييرات بشكل مختلف. على سبيل المثال ، نتحقق من التغييرات الوظيفية بناءً على متطلبات العمل ، وفي إعادة هيكلة الهيكلية ، نتحقق من التوافق مع الإصدارات السابقة. وإذا قمنا بخلط عدة فئات ، فسيكون من الصعب على المراجع وضع العديد من استراتيجيات المراجعة في الاعتبار في نفس الوقت. وعلى الأرجح ، سيقضي المراجع وقتًا أطول في طلب التجميع أكثر من اللازم ، ولهذا السبب قد يفوتك شيء. علاوة على ذلك ، إذا كان طلب المجموعة يحتوي على أنواع مختلفة من التغييرات ، فمع أي تصحيح ، سيتعين على المراجع مراجعة كل هذه الفئات مرة أخرى. على سبيل المثال ، يمكنك خلط إعادة هيكلة الهيكلية والتغييرات الوظيفية. حتى لو تم تنفيذ إعادة التسكين بشكل جيد ، ولكن هناك مشكلة في تنفيذ الوظيفية ، بعد المراجعة ، سيتعين على المراجع النظر في طلب المجمع بالكامل من البداية. وهذا هو ، إعادة التحقق من كل من إعادة هيكلة والتغييرات الوظيفية. لذلك يقضي المراجع المزيد من الوقت على طلب التجمع. بدلاً من التفكير في طلب مجمع منفصل فورًا بإعادة التسكين ، ينبغي للمراجع مرة أخرى مراجعة الرمز بالكامل.
ما هو بالضبط لا يستحق الاختلاط
إعادة تسمية / حذف فئة وإعادة بيعها. نحن هنا نواجه جيت ، الذي لا يفهم دائمًا هذه التغييرات بشكل صحيح. أعني تغييرات واسعة النطاق عندما تتغير خطوط كثيرة. عندما تقوم بإعادة تكوين فصل دراسي ثم تنقله إلى مكان ما ، فإن Git لا ترى أنه يتحرك. بدلاً من ذلك ، يفسر Git هذه التغييرات على أنها إزالة فئة واحدة وإنشاء أخرى. هذا يؤدي إلى مجموعة من الأسئلة أثناء مراجعة التعليمات البرمجية. ويُسأل مؤلف الرمز عن سبب كتابته لهذا الرمز القبيح ، رغم أنه في الواقع تم نقل هذا الرمز من مكان إلى آخر مع تغييرات طفيفة.
أي تغييرات وظيفية + أي إعادة بيع. لقد ناقشنا بالفعل هذه الحالة أعلاه. هذا يجعل المراجع تضع في الاعتبار إستراتيجيتين للمراجعة في وقت واحد. حتى إذا تمت إعادة التنظيم بشكل جيد ، فلن نتمكن من تأخير هذه التغييرات حتى تتم الموافقة على التغييرات الوظيفية.
أي تغييرات ميكانيكية + أي تغييرات قام بها الإنسان. يعني "التغييرات الميكانيكية" أي تنسيق يتم باستخدام IDE أو توليد الشفرة. على سبيل المثال ، نطبق نمط الشفرة الجديد ونحصل على 3000 سطر من التغييرات. وإذا قمنا بخلط هذه التغييرات مع أي تغييرات وظيفية أو أي تغييرات أخرى قام بها شخص ما ، فسوف نضطر المراجع إلى تصنيف هذه التغييرات عقلياً والسبب: هذا تغيير تم إجراؤه بواسطة جهاز كمبيوتر - يمكن تخطيه ، وهذا التغيير الذي قام به شخص مطلوب تحقق من. لذلك يقضي المراجع الكثير من الوقت الإضافي في التحقق.
مثال
فيما يلي طلب تجمع مع وظيفة أسلوب تغلق اتصال العميل بلطف إلى Memcached:
حتى إذا كان طلب التجمع صغيرًا ويحتوي على مائة سطر فقط من التعليمات البرمجية ، فلا يزال من الصعب التحقق منه. كما ترى من عمليات الالتزام ، فإنه يحتوي على فئات مختلفة من التغييرات:
- وظيفية (كود جديد) ،
- إعادة بيع (إنشاء / نقل الطبقات) ،
- التصويب رمز النمط (إزالة كتل قفص الاتهام الزائد).
في الوقت نفسه ، فإن الوظيفة الجديدة بحد ذاتها هي 10 خطوط فقط:
نتيجة لذلك ، يجب على المراجع مراجعة الرمز بالكامل و
- تحقق من أن إعادة بيع المباني على ما يرام.
- التحقق من تنفيذ الوظيفة الجديدة بشكل صحيح ؛
- تحديد ما إذا كان هذا التغيير تم إنشاؤه تلقائيًا بواسطة IDE أو بواسطة الشخص.
لذلك ، من الصعب مراجعة طلب التجميع هذا. لتصحيح الموقف ، يمكنك تقسيم هذه الالتزامات إلى فروع منفصلة وإنشاء مجموعة من الطلبات لكل منها.
1. إعادة بيع المباني: استخراج الطبقة
لا يوجد سوى ملفين. يجب على المراجع فحص التصميم الجديد فقط. إذا كان كل شيء في النظام - merzhim.
2. الخطوة التالية هي إعادة بناء المساكن ، فنحن ننتقل فقط إلى فئتين جديدتين
طلب التحقق هذا بسيط للغاية ؛ يمكن إنشاء مثيل له على الفور.
3. إزالة كتل قفص الاتهام الزائدة
لا شيء مثير للاهتمام هنا. مرزيم.
4. الوظيفية نفسها
والآن طلب التجمع مع التغييرات الوظيفية يحتوي فقط على الكود المطلوب. لذلك يمكن للمراجع الخاص بك التركيز فقط على هذه المهمة. طلب المسبح صغير وسهل التحقق.
الخاتمة
حكم الإبهام:لا تقم بإنشاء طلبات تجمع ضخمة مع فئات مختلطة من التغييرات.
كلما زاد طلب التجمع ، زاد صعوبة فهم المراجع للتغييرات التي اقترحتها. على الأرجح ، سيتم رفض طلب تجمع ضخم مع مئات أسطر التعليمات البرمجية. بدلاً من ذلك ، قم بتقسيمه إلى أجزاء منطقية صغيرة. إذا كانت عملية إعادة التوطين الخاصة بك في حالة جيدة ، ولكن التغييرات الوظيفية تحتوي على أخطاء ، يمكن إعادة التراجع عن إعادة التجهيز بسهولة ، وبالتالي يمكنك أنت والمراجع التركيز على الوظيفة دون النظر إلى جميع الشفرات من البداية.
واتبع دائمًا هذه الخطوات قبل إرسال طلب التجمع:
- تحسين التعليمات البرمجية الخاصة بك للقراءة. الكود هو أكثر قابلية للقراءة من الكتابة ؛
- صف التغييرات المقترحة من أجل توفير السياق اللازم لفهمها ؛
- تحقق دائمًا من الكود قبل إنشاء طلب تجمع. وفعل ذلك كما لو كان رمز شخص آخر. في بعض الأحيان يساعد في العثور على شيء فاتك. سيؤدي ذلك إلى تقليل احتمال رفض طلب التجمع الخاص بك وعدد التصحيحات.
أخبرني زميلي
أوليغ أنتونيفيتش عن فكرة تقسيم التغييرات إلى فئات.
من المحرر: يكتب سيرجي الكثير من الأشياء المثيرة للاهتمام حول البرمجة و PHP ، وأحيانًا نترجم شيئًا ما: خادم فيديو متدفق ، يعرض ملفات HTML . لا تتردد في طرح الأسئلة عليه في التعليقات على هذه المقالة - سوف يجيب!
حسنًا ، نذكرك أيضًا بأن لدينا دائمًا الكثير من الوظائف الشاغرة للمطورين!