ما هو الدين الفني وهل يمكنك تجنبه؟

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

ما هو الدين الفني؟

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

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

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

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

حصلت عليه.

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

هل يمكنك تجنب الديون التقنية؟

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

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

النظر في الدين الفني الهادف

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

هذا عندما تحتاج إلى التفكير في الحصول على قرض والدخول في ديون فنية.

لديك بالفعل ثلاثة خيارات هنا:

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

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

سداد قرض الدين المقصود

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

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

النظر في الدين الفني للقواعد القديمة

نوع آخر شائع من الديون الفنية هو أن WordPress يراكم الكثير من الديون في الوقت الحالي. يمكن تشغيل WordPress على PHP 5.x. ومع ذلك ، سيخبر التحديث الأحدث المستخدمين أنه يجب أن يكون PHP 5.6 على الأقل. بحلول نهاية عام 2019 ، سيتطلب WP Core PHP 7.x. ومع ذلك ، من خلال زيادة المتطلبات ، يجب تحديث الكثير من التعليمات البرمجية القديمة. لأنه لا يزال هناك كود PHP 5.x في المكونات الإضافية والسمات والجوهر نفسه.

ناهيك عن محرر البلوك الجديد. إنه مكتوب بلغة JavaScript. رد على وجه التحديد. هذا لا شيء بالقرب من PHP. في الواقع ، تتم إعادة كتابة جزء كبير من WordPress Core إلى JavaScript شيئًا فشيئًا. ولكن يجب أن تكمل كل هذه JS وتتوافق مع PHP أيضًا. يعتبر التعامل مع التكنولوجيا الجديدة أمرًا رائعًا ، كما أن اعتماد متطلبات إصدار جديدة أمر ضروري. ولكن عند القيام بذلك ، فأنت تدفع فائدة على الدين التقني الذي لا مفر منه والذي تتحمله من وجود هذا البرنامج لفترة من الوقت.

سداد ديون Legacy Code

هذا نوع صعب لأنه لا توجد طريقة رائعة للقيام بذلك. يمكنك اتخاذ الخيار النووي والقيام بإعادة كتابة كاملة من الألف إلى الياء في اللغة / إطار العمل / الإصدار الجديد (انظر إلى ما فعلناه بين Divi 2 و Divi 3.0 ، من Backbone.js إلى React). ومع ذلك ، لا يزال هذا لا يحل مشكلة الديون تمامًا ، حيث لا يزال لديك أشخاص يستخدمون المكتبة القديمة. في مرحلة ما ، سيتعين عليك إسقاط الدعم لقاعدة الشفرة القديمة. وهو نوع من مثل سداد القرض. حتى تضطر إلى إخراج التالي.

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

النظر في العديد من المطورين بمرور الوقت

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

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

سداد الديون الفنية للمطورين القدامى

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

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

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

تغليف

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

كيف تتعامل مع الديون الفنية ضمن مشاريعك وفرق التطوير الخاصة بك؟

صورة مميزة للمقال أندريه سوسلوف / shutterstock.com