ما هو الدين التقني؟ | التعريف والأمثلة

يخلط الكثير من الناس بين الديون التقنية والمتطلبات غير الوظيفية. فالعيوب لا يمكن أن تكون ديوناً تقنية لأن الديون التقنية لا تعني عدم تلبية المتطلبات سواء كانت وظيفية أو تقنية. ترتبط الديون الفنية بسوء التصميم أو سوء الترميز أو عدم تطبيق أنماط التصميم المناسبة، إلخ.
في حين أن العيوب هي عدم تلبية المتطلبات أو عدم ملاءمة المنتجات للاستخدام أو ضعف الأداء، إلخ. في كثير من الأحيان تنشأ هذه الالتباسات من قبل الأطباء الرشيقين (المدربين الرشيقين). ربما هؤلاء الأطباء ليسوا من خلفية تطويرية أو لم يكتبوا سطرًا واحدًا من التعليمات البرمجية في حياتهم. فهم لا يفهمون الفرق بين الديون التقنية والمتطلبات غير الوظيفية. عدم تلبية المتطلبات غير الوظيفية يعني وجود عيوب وهذه العيوب لا يمكن اعتبارها ديونًا فنية.
فيما يلي بعض الأمثلة على كل من الديون التقنية والمتطلبات غير الوظيفية. يرجى القراءة وإخباري إذا كنت تشعر أنني ذكرت أي شيء بشكل غير صحيح.
لقد وصف مارتن فاولر هذا بشكل جميل للغاية هنا. ولكن فقط لتسهيل فهم الأمر سأضيف بعض الأمثلة التي واجهتها في الماضي.
كنت أعمل على منتج تأمين في عام 2007 وكنا نعمل على تطوير بوابة إلكترونية. كان المنتج الفعلي هو WINS (AS 400) وكُلفنا بإنشاء بوابة باستخدام asp.net.
نظرًا لأن الواجهة الخلفية كانت AS400، كان هناك فريق آخر يكتب البرامج الوسيطة باستخدام BizTalk. كان فريق البرامج الوسيطة يطور الخدمات وكان من المفترض أن نستهلك تلك الخدمات لكتابة الواجهة الأمامية باستخدام asp.net.
بدأنا بشكل جيد للغاية ولكن مع مرور الوقت كنا متأخرين عن الجدول الزمني. في كل مرة كنا نحتاج فيها إلى أي تغيير، كنا نتصل بفريق البرمجيات الوسيطة لإجراء بعض التغييرات في طبقة الخدمة، لكنهم كانوا عادةً مشغولين بالكثير من التغييرات ويستغرقون وقتًا أطول للاستجابة.
وبما أن الضغط كان يتزايد يومًا بعد يوم، بدأ فريق الواجهة الأمامية في تجاوز البرمجيات الوسيطة وبدأنا في الإشارة إلى الواجهة الخلفية مباشرةً من أجل تقليل الوقت في إصلاح العيوب. تمكنا من إصلاح العيوب وتسليمها في الوقت المحدد. احتفظنا بسجل لجميع هذه التغييرات حتى يتمكن فريق البرمجيات الوسيطة من إصلاحها بشكل دائم في المستقبل.
ولكن للأسف لم يأتِ ذلك المستقبل أبدًا ولكن ذلك أدى إلى زيادة الديون الفنية لأن التغييرات الجديدة كانت تستغرق وقتًا أطول وأكثر لمجرد التحقق من كيفية الإصلاح ومكان الإصلاح. لذا فقد أبلينا بلاءً حسنًا في البداية في إطلاق البوابة في الوقت المحدد، لكن التغييرات اللاحقة استغرقت وقتًا أكثر فأكثر في حين كان من المفترض أن تستغرق وقتًا أقل لأن الفريق كان أكثر خبرة في ذلك الوقت.
أتقن فن التغلب على الديون التقنية والنهوض بمشاريعك. اكتشف الاستراتيجيات الرئيسية للتغلب على التحديات ودفع مبادراتك نحو النجاح، ابدأ رحلتك الآن!
حالة أخرى مع نفس المنتج، كان هناك العديد من قواعد العمل لإنشاء السياسة. كانت هذه القواعد مدفوعة من خلال XML وكنا نستخدم محرك القواعد. كانت هناك طريقة لإنشاء السياسة كانت مرتبطة بمحرك القواعد وكان هناك معلمة واحدة لهذه الطريقة في البداية.
مع تقدم التطوير، تغير العديد من أعضاء الفريق لأسباب مختلفة. أضاف كل مطور جديد بعض الأسطر الإضافية من التعليمات البرمجية لكنهم كانوا يخشون إجراء أي تغييرات في التعليمات البرمجية الحالية خوفًا من كسر الوظائف التي تعمل بالفعل. لم يكن هناك أي وثائق جيدة أيضًا مما خلق المزيد من الخوف بين المطورين الجدد.
كانت النتيجة فظيعة. كانت نفس الطريقة تحتوي على أكثر من 10 طرق تحميل زائد وأكثر من 100,000 سطر من التعليمات البرمجية بعد 18 شهرًا. لم يحاول أحد إعادة هيكلة الكود لتبسيطه. كانت الوظيفة مثالية ولكن الكود كان كارثة. في كل مرة كان الأمر يستغرق من أسبوعين إلى ثلاثة أسابيع للمطورين الجدد لمجرد فهم ما تمت كتابته.
يمكن أن يكون هناك ديون في التصميم أيضًا وإليك مثالاً على ذلك. كنا نعمل على تطوير تطبيق EMR في عام 2009 باستخدام WPF و WCF و SQL Server. كان WPF جديدًا جدًا ولم يكن هناك الكثير من المطورين ذوي الخبرة ولكن مع ذلك قرر الفريق التعلم والتطوير. استغرق التعلم المزيد من الوقت لكن الفريق لم يكن واثقًا جدًا من أنماط تصميم MVVM لكن الشركة أرادت إصداره بشكل أسرع.
تحرك الفريق إلى الأمام وبدأوا في بنائه دون أن يكون لديهم الكثير من الفهم حول MVVM. كانت النتيجة جيدة لكنهم كتبوا كودًا لم يكن من السهل فهمه وأضافوا أيضًا الكثير من الأكواد الإضافية التي عقّدت الأمور برمتها. قمنا بأشياء مماثلة مع تطبيق آخر باستخدام Silverlight في نفس الوقت.
ما هي المتطلبات غير الوظيفية؟
كما قلت أعلاه، المتطلبات غير الوظيفية هي متطلبات وليست ديوناً تقنية. إذا كانت الصفحات تستغرق وقتًا أطول لفتحها وكان العمل يشتكي منها فلا تعتبرها ديونًا تقنية. هذا متطلب وعدم تلبية المتطلبات يعني عيبًا. يجب على الفريق إصلاح ذلك. وبالمثل، إذا كان النظام غير قادر على التعامل مع الحمل أو رسائل الخطأ غير واضحة فهذا يعني وجود عيوب وليس ديونًا فنية.
فيما يلي بعض الأمثلة على المتطلبات غير الوظيفية. عدم الوفاء بها يعني وجود عيوب وليس ديون فنية. أمن البيانات إدارة جلسات المستخدم وتأمينها إدارة تحميل الخادم أثناء ساعات الاختيار وغير ساعات الاختيار وقت تحميل الصفحة وقت استجابة الخادم إدارة السجل السليم امتثال الحكومة للسجلات إلخ. آمل أن يساعدك ما سبق على فهم الديون التقنية وما هي الديون غير التقنية. لا يزال الأمر غير واضح، إذن تواصل معي.
نافين مدرب رشيق محترف ويعمل بشكل مستقل منذ فترة طويلة في منطقة آسيا والمحيط الهادئ. وهو يعمل مع فريق تطوير البرمجيات وفريق المنتج لتطوير منتجات رائعة بناءً على عمليات تجريبية.