من أشهر الاستعارات فى تكنولوجيا تطوير البرمجيات حول العالم هو الاستعارة المجازية “الديون المالية“. الفكرة هى أن إهمال الجودة الداخلية للبرنامج سوا الكود أو التصميم هو مثل الاقتراض بالفائدة، وبالرغم من قدم التشبية إلا أنهت عادة تفهم خطأ أو يتم اختزالها من قبل الكثير. فيما يلى ترجمة بتصرف لمقالات كتبها مارتن فاولر وهو من أشهر المتحدثين والمؤلفين فى مجال تكنولوجيا البرمجيات.
أنظمة البرمجيات عرضة لتراكم العيوب cruft– ألا وهي أوجه القصور في جودة النظام (البرنامج) الداخلية التي تجعل محاولات التعديل والإضافة أكثر صعوبة من لوكانت جودة البرنامج الداخلية من الناحية المثالية خالية من العيوب. مصطلح “الديون الفنية” هو استعارة بلاغية، صاغها وارد كانينجهام والتي تحدد كيفية التفكير في التعامل مع هذه العيوب، والتفكير في الأمر وكأنه دين مالي.يعتبر الجهد الزائد الذي نضطر لبذله لإضافة خصائص ومتطلبات جديدة هو بمثابة الفائدة المدفوعة على الدين.
تخيل أن لدي جزء صعب الفهم في كود البرنامج الخاصة بي وأحتاج إلى إضافة خاصية feature جديدة.إذا كان بنيان ذلك الجزء من الكود واضحًا، فسيستغرق الأمر ٤ أيام لإضافة الخاصية،
ولكن مع عيوب الكود cruft، يستغرق الأمر ٦ أيام. فرق اليومين هو “الفائدة المستحقة على الدين“.
أكثر ما يعجبنى فى ذلك التشبيه (الديون) هو كيف أنه يحدد كيفية تفكيرى في التعامل مع تلك العيوب cruft. قد يستغرق الأمر ٥ أيام لتحسين بنية هذا الجزء من البرنامج، وإزالة ذلك العيب cruft، ورد “الدين” المجازي. إذا قمت بذلك فقط من أجل هذه الخاصية، فهذا ليس مكسبًا، لأنني سأستغرق ٩ أيام بدلاً من ٦. ولكن إذا كان لدي فى الخطة كتابة خاصيتان إضافيتين في المستقبل القريب، فالمحصلة أنى أديت العمل بشكل أسرع عن طريق إزالة العيب cruft أولاً.
من هذا المنطلق ، يبدو الأمر كمسألة حسابية بسيطة، ويستطيع أي مدير باستخدام اكسيل excel استيعاب الخيارات المتاحة. لكن للأسف بما أننا لا نستطيع قياس الإنتاجية (تطوير البرنامج)، فلا يمكن قياس أي من هذه التكاليف بشكل موضوعي.ربما يمكننا تقدير الوقت المستغرق لكتابة خاصية جديدة، وتقدير ما قد يكون عليه الحال إذا أزيلت العيوب cruft، وتقدير تكلفة إزالة العيوب (الدين) ولكن دقة هذه التقديرات منخفض جدًا.
وبالنظر إلى ذلك، فإن أفضل طريق عادة هو التعامل بنفس الطريقة التى عادةً ما نتعامل بها مع الديون المالية، ألا وهى دفع أصل الدين تدريجيا. عند كتابة الخاصية الأولى، سأقضي يومين إضافيين لإزالة بعض العيوب (الدين). قد يكون ذلك كافيًا لخفض قيمة الفوائد على التحسينات والإضافات المستقبلية ليوم واحد. ما زال هذا يستغرق وقتًا إضافيًا، ولكن من خلال إزالة العيوب cruft ، فأنا أقلل تكلفة التغييرات المستقبلية على هذا الكود (البرنامج). إن الفائدة الكبرى من هذا التحسين التدريجي هو أنه يعني بطبيعة الحال أننا نقضي المزيد من الوقت في إزالة العيوب cruft في تلك المناطق التي نقوم بتعديلها بشكل متكرر، وهي بالضبط تلك الأجزاء فى الكود التى نحتاج فيها إلى إزالة العيوب cruft.
التفكير في هذا على أنه دفع الفائدة مقابل دفع رأس المال يمكن أن يساعد في تحديد أي عيوب (جزء من الدين) يجب معالجتها. إذا كان لديّ جزئ سيئ من الكود لدرجة أنه كالكابوس أن نفكر في تعديله، فلن تكون مشكلة إذا لم اضطر إلي تعديله. أنا أقوم فقط بدفع فائدة عندما يكون عليّ العمل مع هذا الجزء من البرنامج (هذا هو المكان الذي تنهار فيه الاستعارة، نظرًا لأن مدفوعات الفوائد المالية لا تتوقف عن التراكم مع مرورالوقت). يمكننا عدم تحسين الأجزاء في الكود ذات العيوب ولكنها مستقرة وتعمل ولا نعيرها انتباها. في المقابل، تحتاج الاجزاء النشطة من الكود (يحدث فيها إضافات وتعديلات) إلى أن نأخذها التعامل مع عيوبها بجدية كاملة، ذلك لأن قيمة الفائدة مرتفعة بشكل معيق. هذا مهم بشكل خاص حيث تتراكم العيوب cruft حين يقوم المطورون بإجراء تغييرات دون الانتباه إلى الجودة الداخلية للكود – وكلما زادت التغييرات، كلما زاد خطر تراكم العيوبcruft.
يسأ استخدام استعارة “الديون” أحيانًا لتبرير إهمال الجودة الداخلية للكود. الحجة هي أن الأمر يستغرق وقتًا وجهدًا لإيقاف تcruft. إذا كانت هناك ميزات جديدة مطلوبة بشكل عاجل ، فربما يكون من الأفضل تحمل الدين ، وقبول أنه يجب إدارة هذا الدين في المستقبل.
الخطر هنا هو أن هذا التقييم لا يتم بشكل جيد في معظم الأحيان. عيوب الجودة الداخلية للكود لها cruft تأثير سريع، مما يؤدي إلى إبطاء تطوير الخواص الجديدة الجديدة المطلوبة بسرعة. الشركات التي تقوم بذلك ينتهي بها الأمر إلى نفاذ حدود الائتمان في جميع “بطاقات الائتمان” الخاصة بها ولا تزال تقوم بالتسليم إضافات وتعديلات البرامج في وقت متأخر عما كانت ستفعله لو بذلوا الجهد في تحسين الجودة الداخلية للكود. غالباً ما تؤدي الاستعارة (التشبيه بالديون) هنا إلى تضليل الناس، لأن الديناميكيات لا تتطابق بالكامل مع تلك الخاصة بالقروض المالية. إن تحمل الديون لتسريع التسليم لا يجدي إلا إذا بقيت تحت خط “العائد علي التصميم الجيد” من فرضية Design Stamina Hypothesis (عدد أو كم الخصائص الذي تحته يمكن مقايضة قلة جودة تصميم الكود/البرنامج مقابل السرعة في التنفيذ)، ويكون هذا في حدود عدة أسابيع وليس شهورا.
هناك مناقشات منتظمة حول ما إذا كان ينبغي اعتبار الأنواع المختلفة من عيوب الجودة الداخلية ديونًا أم لا. لقد وجدت أنه من المفيد التفكير فيما إذا كان الدين قد أخذ عن عمد وما إذا كان رشيدًا أو مستهترًا – مما يقودني إلى “مناطق الديون التقنية”
Leave a Reply