🎡 ⏫ 🔟 مراجعة الكود - تحسين العملية 🙋 👈🏾 🌛

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

كيف يمكن تجنب ذلك؟الإجابة على السؤال في العنوان هي مراجعة الكود.

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

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

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

فيما يلي توصيات للمساعدة في تسريع مراجعة التعليمات البرمجية وتحسين جودتها.

نقسم السؤال إلى ثلاثة أجزاء وننظر في كل جزء على حدة:

الجزء الفني: كيفية التحقق من الرمز وما الذي تبحث عنه عند التحقق؟
جزء الاتصال: كيف تمنع الخلافات وتقلل من التوتر أثناء المناقشة؟
الجزء التنظيمي: ما الذي يمكن عمله لجعل عملية مراجعة المدونة فعالة؟

الجزء 1. التحقق من الرمز

قم بتشغيل كود المؤلف في المنزل

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

تذكر تجربة المستخدم

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

نحن ننظر إلى المنطق العام

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

نحن ننظر إلى بنية الكود

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

نكتب أسهل

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

تعدد

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

التحسين المفرط

كما كتب دونالد كنوث الكلاسيكي ، التحسين المبكر هو أصل كل الشر. من الأفضل تحسين ما هو مطلوب هنا والآن.

نعمل على حل الأخطاء

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

الالتزام

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

الأسماء والمظهر

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

تعليقات التعليمات البرمجية

يجب أن تجيب التعليقات على السؤال: "لماذا يتم ذلك؟" ، وليس "كيف يتم ذلك؟". تذكر هذا.

الجزء 2. نناقش

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

كقاعدة ، يتم تنفيذ طلب السحب على استضافة ويب خاصة (github.com ، bitbucket.org ، gitlab.com ، إلخ) ، حيث يمكن عرض التغييرات وترك تعليق على قطعة معينة من التعليمات البرمجية.

نحن نلتزم بالاتفاقية

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

نحن نقدم بديل

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

يمكنك المتابعة على النحو التالي:

نكتب ما هو الخطأ في التعليمات البرمجية
لماذا من الأفضل عدم الكتابة
نحن نقدم خيارات بديلة

نبقى في إطار المشكلة

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

مديح

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

جميع التعليقات متساوية.

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

عبر بوضوح عن أفكارك

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

يسأل اسئلة

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

نحن نحل النزاعات

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

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

الجزء 3. تحسين العملية

نحن نصف ما فعلوه

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

قسم طلب السحب إلى أجزاء

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

الرد على جميع التعليقات

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

بحث عن؟

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

تنتظر الجميع؟

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

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

أشياء قليلة

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

استنتاج

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

مراجعة الكود - تحسين العملية