في هذه الصفحة
تعد مراجعة الكود خطوة مهمة للتحسين من جودة الكود، بالإضافة لميزات أخرى كانخفاض تكلفة التطوير عند اكتشاف الأخطاء في وقت مبكر من دورة حياة التطوير، ومشاركة المعرفة، وتطوير مهارات الفريق ولذلك تعد هذه القائمة بالإضافة إلى بعض القواعد والإرشادات أمرًا بالغ الأهمية؛ حيث يمكن أن تجعل مراجعة الكود أكثر فائدة لفريقك وتسرع تلك العملية بشكل كبير؛ لأنها تحسن قدرة الفريق على تقليل الأخطاء واكتشافها بسرعة.
قائمة اسئلة مراجعة الكود في مرحلة التنفيذ
- هل بتغيير هذا الكود يفعل ما يفترض أن يفعله؟
- هل يمكن تبسيط هذا الحل؟
- هل يضيف هذا التغيير تبعات أثناء compile-time or run-time غير المرغوب فيها؟
- هل تم استخدام framework ،API ،library، أو service لا ينبغي استخدامها؟
- هل عزفنا عن استخدام framework ،API ،library، أو service يمكنها تحسين الحل؟
- هل الكود على مستوى abstraction الصحيح؟
- هل الكود modular بما فيه الكفاية؟
- هل الكود يحل المشكلة بطريقة مختلفة وأفضل من حيث إمكانية صيانة الكود وقراءته وأداءه وحمايته (code maintainability، readability، performance، and security)؟
- هل توجد functionality مماثلة بالفعل في codebase؟ إذا كان الأمر كذلك، فلماذا لا يُعاد استخدام هذه functionality؟
- هل هذا الكود يتبع مبادئ SOLID؟
- هل هناك أي best practice ،design patterns، أو language-specific patterns يمكنها تحسين هذا الكود بشكل كبير؟
- هل يمكنك التفكير في أي مدخلات أو events خارجية يمكن أن تُحدث خلل فى الكود؟
- هل يمكنك التفكير في أي use case لا يتصرف فيها الكود بالشكل المقصود؟
قائمة أسئلة لمراجعة error handling وتسجيلها فى الكود
- هل error handling يتم بالطريقة الصحيحة؟
- هل يجب إضافة أو إزالة أي معلومات لها علاقة بالـlogging أو الـdebugging؟
- هل error messages سهلة الاستخدام؟
- هل هناك log events كافية وهل هي مكتوبة بطريقة تتيح تصحيح الأخطاء بسهولة؟
قائمة أسئلة لمراجعة Testing and Testability
- هل الكود قابل للاختبار testable؟
- هل يوجد بها عدد كاف من automated tests؟
- هل الـtests الحالية تغطي بشكل معقول تغيير الكود وedge cases؟
قائمة أسئلة لمراجعة التبعيات (Dependencies)
- إذا كان هذا التغيير يتطلب تحديثات خارج الكود، مثل تحديث documentation configuration، and readme files،فهل تم ذلك؟
- هل يمكن أن يكون لهذا التغيير أي تداعيات على أجزاء أخرى من system وهل التغيير متوافق مع الإصدارات السابقة (backward compatibility)؟
قائمة أسئلة لمراجعة قابلية قراءة وفهم الكود
- هل كان الكود سهل الفهم؟
- هل هناك أجزاء من الكود كانت مربكة لك؟ ولماذا؟
- هل يمكن تحسين سهولة قراءة الكود عن طريق كتابة methods أصغر؟
- هل يمكن تحسين قابلية قراءة الكود من خلال تغير اسم function/method أو variable؟
- هل الكود موجود في file/folder/package الصحيح؟
- هل تدفق البيانات(data flow) مفهوم؟
- هل هناك تعليقات (comments) زائدة عن الحاجة أو مكررة فى الكود؟
- هل ستجعل المزيد من التعليقات (comments) الكود أكثر قابلية للفهم؟
- هل يمكن إزالة بعض التعليقات (comments) وجعل الكود نفسه أكثر قابلية للقراءة؟
- هل هناك أي كود commented-out؟
قائمة أسئلة لمراجعة سهولة الاستخدام والوصول للكود
- هل الحل المقترح مصمم بشكل جيد من منظور قابلية الاستخدام؟
- هل API موثق جيدًا؟
- هل الحل المقترح (UI) يمكن الوصول إليه؟
- هل API سهل الاستخدام ؟
قائمة أسئلة لمراجعة الأمان وخصوصية البيانات (Security and Data Privacy)
- هل هذا الكود يُعَرض البرنامج للثغرات الأمنية (security vulnerabilities)؟
- هل يتم التعامل مع authorization and authentication بالطريقة الصحيحة؟
- هل يتم التعامل مع البيانات الحساسة مثل بيانات المستخدم ومعلومات بطاقة الائتمان وتخزينها بشكل آمن؟ هل يتم استخدام التشفير(encryption) الصحيح؟
- هل يكشف تغيير هذا الكود عن بعض المعلومات السرية (مثل أسماء المستخدمين وما إلى ذلك)؟
قائمة أسئلة لمراجعة الأداء (Performance)
- هل تعتقد أن هذا التغيير في الكود سيؤثر على system performance بطريقة سلبية؟
- هل ترى أي إمكانية لتحسين أداء الكود(code performance)؟
في الختام
هذه القائمة ليست شاملة، ولكنها تعمل كموجه لمراجع الكود لإجراء مراجعة فعالة وفي النهاية تقديم كود جيد الجودة. قد يستغرق الأمر بعض الوقت في البداية لمراجعة الكود من جوانب مختلفة. ولكن! بعد قليل من الممارسة، يمكن لمراجعي الكود إجراء مراجعات فعالة، دون بذل الكثير من الجهد والوقت.
