قائمة مراجعة مراجعة الكود: 7 خطوات لرفع مستوى عملية المراجعة الخاصة بك
تتم مراجعة الكود عندما يقوم شخص آخر غير المؤلف بفحص الكود المصدري والبحث عن المشكلات.
سواء كان عليك تقديم مراجعات التعليمات البرمجية أو الجلوس على الطرف المتلقي، فقد رأيت فترات الاستجابة التي يمكن إضافتها إلى سير العمل الخاص بك.
ولحسن الحظ، يمكن لقائمة مراجعة التعليمات البرمجية الرائعة أن تسرع العملية وتزيد من دقة مراجعات التعليمات البرمجية.
إن اتباع أفضل ممارسات مراجعة التعليمات البرمجية يمكن أن يفيد عملك والمنتج النهائي.
سواء كانت مراجعاتك تعتمد على عدة أشخاص، أو أتمتة، أو تعليقات غير متزامنة، فإن دليلنا يغطي كيف يمكنك أن تصبح مراجعًا أفضل للأكواد.
ولتحقيق المزيد من التقدم، سنشارك الموارد التي يجب أن يمتلكها كل مطور، بما في ذلك نموذج قائمة مراجعة التعليمات البرمجية الخاصة بنا.
قائمة مرجعية شاملة لمراجعة التعليمات البرمجية
يتبع كبار المطورين العديد من إرشادات مراجعة التعليمات البرمجية عند دراسة عمل شخص ما. يجب عليهم أن يأخذوا في الاعتبار تصميم الكود وأسلوبه ووظيفته وتعقيده وتسميته واختباره.
هناك الكثير من الأجزاء المتحركة لمراجعة التعليمات البرمجية الشاملة، ولهذا السبب من المهم جدًا أن يتخذ مراجعو التعليمات البرمجية أسلوبًا منظمًا ودقيقًا. إن الاستفادة من قائمة المراجعة المكونة من سبع خطوات ستضمن عدم تفويت أي شيء.
1. التحقق من متطلبات الميزة
تبدأ كل مراجعة بسؤال أساسي: “هل يحقق هذا الكود ما يحتاجه المستخدم النهائي؟” المطورون الذين يعملون في مشروع ما لا يقومون بالبرمجة في فراغ.
يحتاج برنامجهم إلى أداء الوظائف التي يتوقعها المستخدم بشكل موثوق. إذا فات المطور الخاص بك هذه الخطوة، فقم بتأجيل المراجعة حتى يقدم الكود مجموعة كاملة من الميزات.
للتحقق من متطلبات الميزة، اسأل نفسك:
- هل هناك أي وظيفة مفقودة؟
- هل هناك أي وظائف سيئة التنفيذ؟
- هل يمكنهم إضافة أي وظائف ذات صلة يرغب بها المستخدم؟
2. تقييم سهولة القراءة
حتى لو كان الكود ينفذ ما تم الإعلان عنه، فأنت لم تخرج من المشكلة بعد. بالإضافة إلى تلبية المتطلبات الأساسية، فأنت تريد تعليمات برمجية واضحة وسهلة الفهم.
راجع الوضوح من خلال السؤال:
- هل يمكنك بسهولة تحديد نقطة البداية والنهاية لكتلة التعليمات البرمجية؟
- هل يمكن أن تتناسب الخطوط مع شاشة الكمبيوتر المحمول القياسية (14 بوصة) أو شاشة سطح المكتب (22-24 بوصة)؟
- هل يتحدث الكود عن نفسه وينقل الغرض منه؟
- هل تعطي الأولوية للوضوح والإيجاز؟
- هل يتجنب اللغة الغامضة؟
- هل يمكنك تمييز دور وظائف أو طرق أو فئات محددة؟
- هل قام المطور بتقسيم الكود إلى أجزاء سهلة الفهم؟
3. اختبار قابلية الصيانة
مع مرور الوقت، قد تضطر إلى توسيع التعليمات البرمجية الخاصة بك أو تغييرها، لذا فإن التأكد من سهولة صيانتها وتعديلها سيوفر عليك بعض المتاعب.
اسأل نفسك هذه الأسئلة لتقييم قابلية الصيانة:
- هل الكود سهل الاختبار والتصحيح؟
- هل يمكنك تكوين الكود لتغيير قيم البيانات بسرعة؟
- هل الكود مرتبط بنظام آخر أم ببرنامج قديم؟
- هل يعتمد الكود على الوظائف أو التكنولوجيا التي تريد التخلص التدريجي منها؟
4. التحقق من وجود ثغرات أمنية
لا يزال من الممكن أن يعرض الكود الذي يعمل بشكل مثالي نقاط الضعف التي كان مطورك مشغولًا جدًا بحيث لم يتمكن من ملاحظتها.
في حين أن المبرمج المحروم من النوم قد يفوت بعض المخاطر الأمنية، إلا أن مراجعي التعليمات البرمجية لا يمكنهم المخاطرة باستغلال شخص ما للتعليمات البرمجية الخاصة بهم.
لتجنب الثغرات الأمنية، اطرح الأسئلة التالية:
- هل يستخدم الكود أدوات قديمة أو أدوات بها مشكلات أمنية معروفة؟
- إذا أردت سرقة البيانات أو الوصول إلى النظام، هل ترى نقاط ضعف؟
- هل يستفيد الرمز من المصادقة والترخيص للأمان؟
- هل يتم تعقيم مدخلات المستخدم لمنع الهجمات الأمنية؟
- هل يقوم الكود بتخزين بيانات المستخدم بشكل آمن؟
- هل يحمي الكود P2 أو البيانات الأخرى المتعلقة باللائحة العامة لحماية البيانات؟
5. خذ بعين الاعتبار السرعة والأداء
مشاكلك لا تنتهي بالأمن؛ لا يزال المستخدم يتوقع أداءً موثوقًا. يحتاج مراجعو التعليمات البرمجية أيضًا إلى الموازنة بين استهلاك موارد البرنامج وسرعته.
إن تحقيق التوازن بين هذه الأولويات ليس بالأمر السهل دائمًا، ولكن يجب أن تحدد التعليمات البرمجية الرائعة كلا المربعين.
اسأل نفسك بعض الأسئلة لتقييم السرعة والأداء:
- هل يحتوي الكود على سلاسل أو تسجيلات أو تخصيصات غير فعالة للكائنات؟
- هل يمكنك رؤية الكود المكرر الذي لا تحتاجه؟
- هل سيؤثر البرنامج سلباً على أداء النظام بشكل عام؟
- هل يعتمد الكود على أصول سيئة التحسين أو طلبات متعددة لواجهة برمجة التطبيقات؟
6. تأكيد الوثائق الكافية
تشرح أفضل الوثائق ما تفعله قاعدة التعليمات البرمجية وكيف يمكنك استخدامها. ومع ذلك، حتى التعليمات البرمجية الرائعة قد تحتاج إلى بعض الوثائق الخارجية لسهولة الاستخدام.
للتأكد من أن الوثائق على مستوى المطلوب، اسأل:
- هل تشرح الوثائق الغرض من الكود؟
- هل تعلم الوثائق المستخدم كيفية استخدام الكود؟
- هل تتطلب أي ميزات جديدة أو تغييرات في التعليمات البرمجية وثائق إضافية؟
- هل الوثائق واضحة ومكتوبة بشكل جيد؟
7. فحص اصطلاحات التسمية
تسهل اصطلاحات التسمية الواضحة قراءة التعليمات البرمجية وفهمها. عندما يختار المبرمجون أسماء عشوائية أو دون المستوى الأمثل، حتى البرامج العظيمة يصبح من الصعب على الآخرين فهمها.
يمكنك فحص اصطلاحات التسمية عن طريق طرح السؤال التالي:
- هل قمت بمراجعة أسماء المتغيرات والثوابت وحقول الفئة والخصائص والأساليب؟
- هل الأسماء بسيطة ومقروءة؟
- هل تتناسب الأسماء مع اصطلاحات التسمية الخاصة بشركتك؟
- هل تنقل الأسماء ما هي الوظيفة أو المتغير؟
- هل تشرح الأسماء سياق أو نطاق قاعدة التعليمات البرمجية الشاملة؟
قالب قائمة مراجعة مراجعة الكود
هل تريد الاحتفاظ بقائمة مراجعة التعليمات البرمجية هذه في متناول اليد؟ لقد قمنا بإنشاء ملف PDF قابل للتنزيل لمساعدتك. اضغط على زر التنزيل أدناه للحصول على قالب مستند مراجعة التعليمات البرمجية الخاص بك.
ما هو الغرض من مراجعات الكود؟
الميزة الأكثر وضوحًا لمراجعة التعليمات البرمجية هي ضمان عدم وصول التعليمات البرمجية السيئة إلى مرحلة الإنتاج. ومع ذلك، هناك الكثير من الفوائد الأخرى، مثل تبادل المعرفة، وتحسين الأمان، وتعزيز العمل الجماعي.
كما يساعد المديرون الذين يقومون بمراجعة التعليمات البرمجية المؤسسات على تحقيق قدر أكبر من التوحيد القياسي.
ضمان رمز الجودة
بحلول الوقت الذي تنتهي فيه من البرمجة، ربما تكون قد سئمت من التحديق في نفس أسطر التعليمات البرمجية. في هذه المرحلة، من الصعب أن تظل موضوعيًا، كما أنك تتعرض لخطر تفويت الأخطاء.
وذلك عندما يساعد زوج من العيون الطازجة. أولاً، يمنحك راحة البال لأن شخصًا آخر سيكتشف أي مشكلات في كود المصدر أثناء قيامك بإعداد القهوة (أو الشاي) التي تشتد الحاجة إليها.
تعمل المراجعات أيضًا على التخلص من تصحيح الأخطاء في وقت مبكر من دورة حياة التطوير بدلاً من تصحيح الأخطاء بعد الإصدار.
تبادل المعرفة وتحسين العمل الجماعي
على الرغم من أنها يمكن أن تبدو وكأنها عثرة في السرعة أثناء الإنتاج، إلا أن مراجعات التعليمات البرمجية تمنح كل من المراجع والمراجع الفرصة للتعلم. على سبيل المثال:
- يجب على الشخص الذي يقوم بمراجعة الكود أن يدرس الكود المصدري والأسلوب.
- يمكن لمؤلفي المدونة التعلم من أي تعليقات تمت مشاركتها والحصول على فرصة لوضع دروسهم موضع التنفيذ.
- يستفيد كلا الطرفين من تحسين التواصل.
من خلال هذه العملية، يمكن لمؤلفي الكود والمراجعين طرح الأفكار ومناقشة الأهداف وتطوير سير العمل. علاوة على ذلك، يؤدي التعاون الإضافي إلى كسر العزلة بين الموظفين.
تحسين الأمن
تساعد مراجعات التعليمات البرمجية الآمنة في تحديد نقاط الضعف والعيوب الأمنية في عملية يدوية أو آلية. يمكن أن تؤدي الهفوات الأمنية إلى:
- عيوب المرحلة المتأخرة
- سوء الجودة الشاملة
- قابلية صيانة أقل مع مرور الوقت
- ارتفاع الديون الفنية
- سرقة معلومات المستخدم
يؤدي منع المشكلات الأمنية مسبقًا إلى توفير الوقت وسمعة عملك. إن قضاء بضع دقائق إضافية في التحقق من الأمان سيغطي تكاليفه أكثر من نفسه.
تقليل تكاليف التطوير
تكتشف مراجعات التعليمات البرمجية المشكلات البسيطة التي يمكن أن تتصاعد إلى مشكلات كبيرة. يمكن أن يؤدي إصلاح الأخطاء مبكرًا إلى توفير تكاليف التطوير ومساعدة المراجع في تحديد المشكلات التي يجب البحث عنها.
عندما يكون الأمر مربحًا وتعليميًا، لا يمكنك (حرفيًا) تحمل تكلفة تخطي المراجعة.
ما لا يجب التركيز عليه في مراجعة الكود
هناك طرق أفضل لقضاء وقتك بدلاً من التحقق من كل التفاصيل في مراجعة الكود. تتمتع بعض المجالات بالأولوية على غيرها، خاصة عندما تتطلع إلى تبسيط عمليتك. ومع أخذ ذلك في الاعتبار، يمكنك تجنب التركيز على:
- المهام القابلة للأتمتة: قم بدمج الأتمتة في مراجعة التعليمات البرمجية الخاصة بك لتوفير الوقت. باستخدام الأتمتة، يمكنك التركيز على المهام التي لا يستطيع الذكاء الاصطناعي التعامل معها. فقط تأكد من التحقق مرة أخرى من العمل الآلي لتجنب مشكلات الأتمتة.
- الجماليات: على الرغم من أهمية سهولة القراءة، إلا أنك لا تحتاج إلى دفع العرض التقديمي على الكود إلى أبعد من اللازم. اجعله واضحًا وسهل المتابعة، ولكن لا تهدر الموارد على الذوق البصري.
- التفضيلات الشخصية: قم بتوحيد التعليمات البرمجية وفقًا لتفضيلات عملك أو فريقك، وليس تفضيلاتك. إن الالتزام بإرشادات العمل يجعل رمز كل شخص قابلاً للتعرف على الآخرين في الفريق.
كيفية تحسين عملية مراجعة التعليمات البرمجية الخاصة بك
الآن بعد أن عرفت ما الذي تبحث عنه في مراجعة الكود، يمكنك تحسين العملية. لقد أوضحنا بعض النصائح لتحسين عملية مراجعة التعليمات البرمجية الخاصة بك:
- اعتماد دليل الأسلوب: تسوية المناقشات المتعلقة بالأسلوب من خلال اعتماد دليل أسلوب التعليمات البرمجية على مستوى المؤسسة. لا ينبغي أن تحدد فقط العناصر السطحية مثل قواعد المسافات البيضاء أو اصطلاحات التسمية، ولكن أيضًا كيفية الاستفادة من ميزات أي لغة برمجة.
- عرض مراجعات التعليمات البرمجية كمهام ذات أولوية عالية: قم بوضع إرشادات داخلية حول مدى السرعة التي يجب أن تنتهي بها التعليمات البرمجية (مثل تنفيذ تعليمات برمجية ذات طول معين لمدة يوم واحد أو أطول إذا كانت التعليمات البرمجية أكبر بكثير).
- استهدف الحصول على تعليقات قابلة للتنفيذ وأسئلة استقصائية: بدلاً من التعليق على الكود، اسأل المؤلف عن سبب تنسيق الكود بطريقة معينة أو نيته من وراء القرار. أنت تهدف إلى الحوار هنا.
- استبدل “أنت” بـ”نحن”: عند طرح مشكلة ما، قم بتنسيق إجابتك في عبارة “نود أن نفعل X لأن Y”. تجنب التعليقات مثل: “أنت لم تتبع إرشادات أسلوبنا هنا.” إن تذكير المطورين بأنك تعمل جميعًا في نفس الفريق يؤدي إلى ارتفاع الروح المعنوية.
- اعتمد على المبادئ، وليس الآراء: أهدف إلى الحصول على تعليقات موضوعية بناءً على أطر أو مبادئ الترميز. يوفر هذا أيضًا ثقافة تعليمية للمؤلف لفهم “السبب” وراء جزء معين من التعليقات بشكل أفضل.
- ركز على الجوانب التي ستحقق أكبر قيمة: لا تركز على كل فرصة لتحسين التعليمات البرمجية أثناء المراجعة. الكمال أمر رائع، ولكن بالنظر إلى وقت المشروع ونطاقه، ركز على المجالات التي سيكون لها التأثير الأكبر.
الأسئلة الشائعة حول مراجعة الكود
هل لا تزال لديك بعض الأسئلة حول إرشادات مراجعة الكود أو ما الذي يجب البحث عنه في مراجعة الكود؟ لا عرق، لدينا إجابات.
ما الفرق بين مراجعة الكود ومدقق الكود؟
يستخدم مدققو الكود برنامجًا لتحليل كود المصدر. تستخدم بعض المؤسسات أدوات فحص التعليمات البرمجية أثناء التطوير لتسريع عملية المراجعة وتقليل احتمالية حدوث خطأ بشري.
يستخدم هذا البرنامج التحليل الثابت لمراجعة الكود المصدري للأخطاء والأخطاء المنطقية والأسلوب والوثائق وبناء الجملة.
ما هي الأدوات التي تبسط مراجعات التعليمات البرمجية؟
لا يتعين على المديرين العمل من خلال قائمة مراجعة مراجعة التعليمات البرمجية الآمنة بمفردهم. باستخدام الأدوات المناسبة، يمكنك تسريع العملية. نوصي:
- أدوات تحليل التعليمات البرمجية الثابتة: يقوم التحليل الثابت بمسح تحليل التعليمات البرمجية المصدر بحثًا عن الأخطاء والمشكلات الأمنية. يمكن أن يساعدك استخدام واحدة قبل المراجعة في التركيز على المشكلات التي يصعب العثور عليها.
- المكونات الإضافية للتصحيحات: يمكن أن تساعدك المكونات الإضافية للتنسيق وتصحيح الأخطاء واقتراح أفضل الممارسات أثناء المراجعة. أثناء المراجعة، تشير هذه المكونات الإضافية إلى المشكلات التي ربما فاتتك.
- أدوات تتبع تعليقات مراجعة التعليمات البرمجية: تحدد تطبيقات المراجعة التعاونية وأدوات تتبع التعليقات الأشخاص الذين تفاعلوا مع التعليمات البرمجية وقاموا بتغييرها. عندما تمر مراجعتك بأكثر من مرحلة، يمكن أن تساعد هذه الأدوات في تنظيم العملية.
ما هي المعايير والمقاييس التي يجب أن أضعها في الاعتبار؟
يجب على الفرق تحديد مقاييس أو معايير هندسة البرمجيات لتتبع فعالية مراجعات التعليمات البرمجية الخاصة بك وتأثيرها على جودة التعليمات البرمجية.
توفر المقاييس أيضًا للفرق مقاييس موضوعية لتنظيم مراجعات التعليمات البرمجية حولها.
تعتبر المقاييس الأربعة التالية نقاط بداية جيدة يجب تضمينها في عملية المراجعة الخاصة بك:
- وقت رد الفعل: يساعد هذا المقياس في تعزيز التعاون في المشاريع مع مطورين متعددين. ما عليك سوى رسم المدة التي يستغرقها المراجع للرد على تعليق موجه إليه. تعني أوقات رد الفعل الأقصر بشكل عام وجود فريق أكثر تعاونًا واستجابة.
- العلاقات العامة غير المراجعة: يشير القادة إلى العلاقات العامة غير المراجعة لمعرفة المدة التي ينتظرها الكود لمراجعة النظراء بعد إرساله. تشير الأوقات الأقصر إلى مسار فعال حيث تتم مراجعات التعليمات البرمجية في الموعد المحدد.
- العلاقات العامة التي تمت مراجعتها بدقة: يقيس هذا المقياس عمق كل مراجعة. إن تتبع العلاقات العامة التي تمت مراجعتها بدقة يضمن عدم قيام أي شخص بالموافقة على مراجعاتهم.
- علاقات عامة متكررة: يمكنك معرفة عدد المرات التي تؤدي فيها مراجعات التعليمات البرمجية إلى إصلاح الأخطاء أو تحسين الجودة من خلال علاقات عامة متكررة. يعني وجود عدد كبير من العلاقات العامة المتكررة أن مراجعات التعليمات البرمجية الخاصة بك تؤدي إلى تحسينات قابلة للقياس.
كم عدد أسطر التعليمات البرمجية التي يجب علي مراجعتها مرة واحدة؟
للحصول على أفضل النتائج، قم بمراجعة ما لا يزيد عن 400 سطر من التعليمات البرمجية في المرة الواحدة. إذا قمت بأكثر من ذلك، فإنك تخاطر بفقدان الأخطاء والعيوب المنطقية والعيوب الأخرى.
والأفضل من ذلك، إذا كان بإمكانك قصر نفسك على 200 سطر من التعليمات البرمجية في المرة الواحدة، فستحقق أكبر قدر من النجاح.
المصدر: pluralsight
شاهد المزيد:
