ما المقصود بجودة التعليمات البرمجية؟

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

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

• تُهدر الديون التقنية الناتجة عن تسريع التعليمات البرمجية ما يصل إلى 42% من وقت المطورين.

• وتؤدي التعليمات البرمجية منخفضة الجودة إلى عيوب أكثر 15 مرة من التعليمات البرمجية عالية الجودة.

• ويستغرق حل المشكلات في التعليمات البرمجية منخفضة الجودة (في المتوسط) وقتًا أطول بنسبة 124% من حل المشكلات في التعليمات البرمجية عالية الجودة.

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

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

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

تشمل السمات الشائعة للتعليمات البرمجية عالية الجودة ما يلي:

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

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

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

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

كتب باحثون من جامعة Calvin University وكلية Amherst College and Columbia في مجلة Harvard Data Science Review في عام 2023، واقترحوا إطارًا إرشاديًا للتعليمات البرمجية الجيدة: "The Four C’s"².

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

• الوضوح: يمكن لأي شخص يقرأ التعليمات البرمجية ويكتبها تحديد ما ينوي القيام به وإجراء التعديلات بشكل بديهي حسب الضرورة.

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

• الاتساق: يجب أن تحافظ قاعدة التعليمات البرمجية على الاتساق الداخلي للأسلوب واصطلاحات التسمية والتعليقات والمسافات البادئة والممارسات الأخرى.

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

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

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

للحصول على نهج أكثر معيارية، تحدد ورقة Harvard Data Science Review (HDSR) المذكورة أعلاه سلسلة من الإرشادات لضمان جودة التعليمات البرمجية. وعلى الرغم من أن هذه الإرشادات مصممة ظاهريًا لتلبية احتياجات عالم البيانات، إلا أن معظمها ينطبق على أي تخصص برمجة.

تعد اصطلاحات التسمية القوية ضرورية لقراءة التعليمات البرمجية والاتساق. ويقترح المؤلفون الممارسات التالية:

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

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

• استخدام الأحرف الكبيرة باستمرار. من الحكمة أيضًا تجنب الحالات التي يتم فيها التمييز بين اسمين فقط من خلال الكتابة بالأحرف الكبيرة.

• تجنب الأسماء غير الوصفية، فإنها تزيد بشكل كبير من صعوبة تفسير التعليمات البرمجية.

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

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

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

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

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

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

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

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

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

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

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

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

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

تتضمن قائمة Fowler وBeck لروائح التعليمات البرمجية التي يجب الحذر منها أمثلة مثل:

• دالة طويلة (طريقة طويلة): طريقة تحتوي على عدد كبير جدًا من أسطر التعليمات البرمجية.

• فئة كبيرة: فئة تحاول القيام بالكثير من المتغيرات وتحتوي على عدد كبير جدًا من المتغيرات، وتفتقر إلى التماسك.

• الهوس البدائي: استخدام أنواع البيانات البدائية بدلاً من الكائنات الصغيرة المتخصصة.

• الاسم الغامض: الدوال أو المتغيرات التي تحمل أسماءً غير مناسبة، تخفي الغرض الحقيقي منها.

• تجمعات البيانات: مجموعات من المتغيرات التي تظهر معًا بشكل متكرر في كل مكان.

• عناصر كسولة: الفئات أو الدوال التي تفعل القليل جدًا لتكون موجودة.

• قائمة معلمات طويلة: الدوال التي تتطلب الكثير من الوسيطات لتعمل بشكل صحيح.

• تعديلات متناثرة (Shotgun surgery): يتطلب تغيير واحد تعديل العديد من الوحدات المتفرقة في الوقت نفسه (وهو في الأساس عكس الفئة الكبيرة).

• تعليمات برمجية مكررة: هياكل تعليمات برمجية متطابقة أو متشابهة جدًا في أماكن متعددة.

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

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

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

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

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