٣١ أكتوبر ٢٠٢٠

تعفُّن البرمجيات

By null

من المعروف أن البرمجيات لا تخضع لقواعد الفيزياء العامة "wear-and-tear", فمن المستحيل أن يصدأ كود "C++" بعد اشهر من كتابته.

ولكن ما يغفل عنه بعض المبرمجين أن على الرغم من أن البرمجيات منيعة ضد القواعد الفيزيائية (على افتراض صحة الأجهزة المُشغّلة) لكنها تتأثر بما يعرف بالـ "التعفن البرمجي" أو "التحلل البرمجي".

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

"تعفن البرمجيات" يحدث نتيجة لعوامل كثيرة أهمها — حسب كتاب The Pragmatic Programmer — هي الثقافة وبيئة العمل المحيطة بتلك البرمجيات.

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

النوافذ المحطمة

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

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

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

— الموسوعة الحرة ويكيبيديا

النوافذ المحطمة في البرمجيات

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

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

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

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

وتبعاً لنظرية النوافذ المكسورة, إذا كان جودة البرمجيات على مستوى عالٍ خالٍ من النوافذ المكسورة فذلك من المرجح أن يحفز جودة إنتاجنا, و يزيد حرصنا على الاهتمام بجودة تلك البرمجيات.

إذا وجدت نفسك في فريق ومشروع ذو جودة عالية فمن المرجح ان يزيد اهتمامك بذلك المشروع حتى لا تكون أول من يُفسدها.

— من كتاب "The Pragmatic Programmer"


Written by Nabil Tharwat

Nabil Tharwat is a software engineer and mentor who's super in love with all things accessibility and performance. He's host of The Weekly Noob podcast and his content has reached thousands of people around the world.

Learn more about Nabil.