المرونة في صياغة الشفرة البرمجية تعني انخفاضًا في الجودة

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

كل يوم تقريبًا أقرأ هذه العبارة وأشباهها في تعليقات المدونة: “ما الحاجة إلى مبادئ البرمجة كائنية التوجه إن كانت الشفرة البرمجية تعمل بشكل جيّد دون استخدامها؟ ما الهدف من إدخال طرق وأساليب جديدة يفترض بها أن تكون أفضل من سابقاتها، إن كانت الطريقة التقليدية الحالية - والتي تتوسط البرمجة الإجرائية وكائنية التوجه - تعمل جيّدًا؟”

لنفكّر في الأمر من زاوية مختلفة، وننظر إلى الأمور على نحو أعمّ ونفكّر من ناحية تطوير البرمجيات لا من ناحية البرمجة كائنية التوجه. هناك الكثير من الأمثلة التي تنطبق عليها عقلية “المهمّ أنّه يعمل”.

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

if a > b
  m = 'Hello!'
end

يمكن كتابة الشفرة السابقة بهذه الطريقة أيضًا:

m = if a > b
  'Hello!'
end

أو هذه:

m = 'Hello!' if a > b

وإليك المزيد:

m = a > b ? 'Hello' : nil

أيّ الشفرات السابقة صحيحة؟ هل يمكن ﻷي مبرمج بلغة Perl أن يخبرنا بذلك؟ هل يمكن اقتراح طرق أخرى للوصول إلى نفس النتيجة؟

أما في لغة Java (وهي لغة أكثر صرامة من Ruby) فليس من المفاجئ أن تكون هناك طريقة واحدة للقيام بذلك:

if (a > b) {
  m = "Hello!";
}

أعتقد أنّني أخطأت، فهنالك طريقة ثانية:

if (a > b) m = "Hello!";

ما الذي يمكن أن يجنيه المبرمجون من هذا التنوّع الكبير؟ أعتقد أن الإجابة تعتمد على كوننا نكتب الشفرة أم نقرؤها؟ كذلك يعتمد الأمر على موقفنا تجاه البرنامج الذي نعمل على إنشائه، فإما نرى بأنّه ملكنا (عقلية المخترق) أو أنّنا نبنيه وحسب (عقلية المصمّم).

إن كنا نكتب الشفرة البرمجية، وكنا نرى أنفسنا أصحاب تلك الشفرة، فسنحتاج إلى ترسانة أسلحة التجميل اللغوي Syntactic sugar لنثبت لأنفسنا بأننا أذكياء، وبالتأكيد لنتباهى أمام أصدقائنا بمفسّر Ruby الكئيب.

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

يمكن أن نعدّ صياغة لغة Ruby والتي تتيح هذا القدر الكبير من التجميل اللغوي مثالًا واضحًا على التناقض الحاصل بين مبدأي “المهمّ أن تعمل” و “المهم أن تكون جيدة”. إذ تتمثل فلسفة Ruby في أنّه لا أهمّية لطريقة كتابة الشفرة البرمجية ما دامت تؤدّي عملها المطلوب منها. أما فلسفة Java فمختلفة تمامًا، وهي أقرب ما تكون إلى: اكتب شفرة صحيحة وستعمل بالتأكيد. إضافة إلى ذلك، فإن نوع البيانات الضعيف والديناميكي Weak and dynamic type الذي تتمتع به لغة Ruby مقابل نوع البيانات الصلب والثابت Strong and static type في Java، يعدّ دليلًا آخر عمّا أتحدّث عنه.

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

وهذا الأمر ينطبق كذلك على عملية تطوير البرمجيات: فكلما زادت القيود المفروضة على المبرمجين وقلّت الخيارات المتاحة أمامهم في طريقة كتابة الشفرة البرمجية، زادت جودة البرنامج المكتوب بتلك اللغة. تحاول المحلّلات الساكنة Static analyzers مثل Checkstyle في لغة Java أو Rubocop في لغة Ruby حلّ هذه المشكلة وذلك بمنعنا من استخدام خصائص معيّنة في اللغة البرمجية، ولكنّها لا تقدّم نتائج جيّدة لأنّنا مبدعون في كتابة الشفرات بأساليب وأشكال متنوعة.

لنعد الآن إلى السؤال الخاص بالبرمجة كائنية التوجه: ما الحاجة إلى تطوير أي شيء إن كان يؤدي عمله بهيئته الحالية؟ الجواب: البرمجة كائنية التوجه الحديثة (كما في Java، Ruby و ++C) لا تنتج شفرة برمجية ذات جودة عالية لأنّها لا تتبع تصوّرا برمجيًّا Paradigm قويًا ومقيّدًا بشكل ملائم. كل ما في الأمر أنّها توفّر الكثير من “الميزات” التي أدخلتها في الغالب ++C وبقيت فيها لأجل منفعتنا المتبادلة.

هذه اللغات تعمل بالفعل، ولكنّ قابلية صيانة البرامج التي ننتجها بهذه اللغات تكون منخفضة للغاية. الواقع أن قابليّة الصيانة هذه أقل بكثير ممّا كان سيكون عليه الحال لو كان “إبداعنا” مقيّدًا.

ترجمة - وبتصرّف - للمقال Flexibility Equates to Lower Quality لصاحبه Yegor Bugayenko.