لا يعتمد الدين التقني على من كتب الكود، بل على تكلفة تعديله. فالوحدة البرمجية الصحيحة تمامًا التي لا يفهمها أحد في الفريق تُعتبر دينًا تقنيًا، حتى لو لم تحتوي على أي خطأ، لأن أي تعديل مستقبلي سيتطلب إعادة بناء المنطق الذي لم يبتكره أحد.
هذا الأمر مهم الآن أكثر من أي وقت مضى لأنه ظهر مسار سريع لتراكم التعليمات البرمجية الصحيحة ولكن غير المفهومة: قبول ما يولده النموذج دون فهم سبب كونه على هذا النحو.
عندما يقوم فريق بتعديل نظام ما، فإن العمل الحقيقي لا يكمن في كتابة أسطر جديدة من التعليمات البرمجية، بل في الإجابة على ثلاثة أسئلة قبل كتابتها: ما وظيفة هذا الكود الآن؟ ولماذا يتم تنفيذه بهذه الطريقة؟ وما الذي سيتعطل إذا قمت بتغييره؟.
يُطلق على هذا العمل اسم الفهم، وهو يستحوذ على معظم الوقت اللازم لإجراء أي تغيير على نظام ناضج. إذا لم يفهم أحد الكود عند تقديمه لأول مرة، فإنّ فاتورة الإصلاح لا تختفي، بل تُؤجّل وتُسدّد مع فوائد، لأنّ من سيدفعها لن يكون على دراية بسياق النقاش الأصلي.
هناك تباين غير مريح: التوليد أسرع من الفهم.. يستطيع النموذج إنتاج شيء في ثوانٍ معدودة، بينما يستغرق فهمه من قِبل شخص ما عشرين دقيقة. وعندما تتسارع وتيرة الإنتاج بينما لا تتسارع وتيرة الفهم، يتراكم هذا الخلل في قاعدة البيانات.
لا أحد يعلم ما إذا كان يتم استخدام قطعة ما. تظهر أكواد قد تكون ضرورية أو غير ضرورية، وعند الشك، يتم الاحتفاظ بها. يتضخم النظام بمواد لا يجرؤ أحد على حذفها.
تصبح المراجعات سطحية. عندما تحدث تغييرات كبيرة بشكل متكرر، تتحول عملية المراجعة من "أنا أفهم هذا وأوافق عليه" إلى "هذا يبدو معقولاً". إنه تغيير هادئ ولكنه حاسم.
يتم حل نفس المشاكل مرتين. تظهر ثلاث وظائف تقوم بنفس الشيء تقريبًا، لأنه لم يكن أحد يعلم بوجود الوظائف الأخرى.
يتم تصحيح الأخطاء عن طريق التغطية، وليس الإصلاح. يتم إضافة شرط فوق المشكلة بدلاً من حلها، لأن لمس الأصل أمر مخيف.
قامت شركة GitClear بقياس العرض الثالث: ازدادت كتل التعليمات البرمجية المكررة ثمانية أضعاف في عام 2024، وأشار تقريرها اللاحق إلى استمرار تزايد التكرار. يُعدّ التكرار مؤشراً إحصائياً على سوء الفهم: إذ يقوم المستخدمون بنسخ ما لا يفهمونه جيداً بما يكفي لإعادة استخدامه بفعالية.
نقترح واحدة فقط، ومن السهل الدفاع عنها في أي فريق:
لا أحد يدمج كودًا لا يستطيع شرحه على السبورة البيضاء.
لا يتطلب الأمر فهم كل تفاصيل التنفيذ. بل يتطلب القدرة على الإجابة على ثلاثة أسئلة: ما المشكلة التي يحلها، ولماذا تم حلها بهذه الطريقة وليس بطريقة أخرى، وماذا سيحدث إذا توقف عن الوجود.
عند تطبيق هذه القاعدة بشكل صحيح، فإنها لا تُبطئ العملية، بل تُعيد ترتيبها. ويظل توليد رمز 80% بمساعدةٍ ما ساريًا. أما ما لم يعد ساريًا فهو دمجه دون قراءته.
|
يمارس |
قبل |
مع الجيل التالي |
|---|---|---|
|
حجم التغيير |
محدود بالوقت المتاح لكتابته |
يمكنها أن تنمو بلا حدود طبيعية. |
|
محور المراجعة |
البحث عن الأخطاء |
تأكد من الفهم والملاءمة |
|
الخطر الرئيسي |
فشل محدد |
قبول هيكل لم يقرره أحد |
|
السيطرة الفعالة |
مراجعة الأقران |
تغيير الحد الأقصى للحجم والاختبار الإلزامي |
يُفسر حجم الصف نتائج دراسة DORA لعام 2024: فمع ازدياد استخدام الذكاء الاصطناعي، انخفض استقرار التسليم بمقدار 7.2%. والسبب ليس جودة الكود المُولّد، بل اختفاء الرادع الطبيعي لكتابته. فالتغيير الذي يتكون من ألف سطر لا يُراجع بنفس طريقة مراجعة التغيير الذي يتكون من خمسين سطرًا، مهما كانت كفاءة المُراجع.
لذلك، فإن التحكم الأكثر فعالية ليس أداة، بل معيار عملية: الحد من حجم التغييرات. إنه بسيط ويعمل.
الاختبارات التي كتبها شخص واحد. من المنطقي أن يقوم النموذج بإنشاء التنفيذ؛ ومن المنطقي أيضاً أن يقوم بإنشاء الاختبار الذي يتحقق من صحة هذا التنفيذ، وبذلك تكتمل العملية. يجب أن يعبر الاختبار عما تتوقعه جهة العمل، وهذا أمر لا يعرفه إلا شخصٌ ما.
توثيق القرار، وليس القانون. ليس من الضروري التعليق على كل سطر. المطلوب هو فقرة تشرح سبب اختيار هذا النهج وما البديل الذي تم استبعاده. هذا يسمح لأي شخص بتغييره خلال عام دون الحاجة إلى إعادة التحليل.
يوجد حد أقصى لحجم التغيير الواحد. أي حد معقول يصلح. لا تكمن قيمته في الرقم نفسه، بل في كونه يجبر على تقسيم العمل إلى وحدات مفهومة.
جميعها غير مكلفة ولا تتطلب أي منها أدوات جديدة. إنه نفس المنطق الأساسي الذي يقوم عليه معيار الهندسة الذي نطبقه على كل عملية تسليم: عقود واضحة، وبيئات معزولة، ووثائق يتم تسليمها إلى العميل، لأن يُعدّ الكود ووثائقه ملكاً لمن يدفع ثمنهما.
في عملية التدقيق، هناك سؤال واحد يوجه التشخيص بشكل أسرع من أي مقياس آخر: اختر وحدة نمطية عشوائياً واطلب من أحد أعضاء الفريق أن يشرح سبب تصميمها بهذه الطريقة..
إذا قُدِّم تفسير منطقي ومتسق، فسيكون النظام قابلاً للصيانة رغم عيوبه. أما إذا كان الجواب هو أنه يعمل دون معرفة السبب، فستكون تكلفة أي تغيير مستقبلي أعلى من أي تقدير، وسيزداد هذا الفرق.
هذا هو المؤشر الحقيقي للدين التقني. ليس عدد الأسطر، ولا عمر النظام، ولا الأداة التي كُتب بها: بل الفجوة بين ما يفعله النظام وما تفهمه المؤسسة عنه.
إنها التكلفة الإضافية المتكبدة مع كل تغيير مستقبلي نتيجةً للقرارات المتخذة لتسريع العملية في حينه. ولا تُقاس هذه التكلفة بعمر الكود أو هوية كاتبه، بل بتكلفة تعديله بشكل آمن.
ليس بسبب جودته الجوهرية، بل لأن القيود الطبيعية لكتابته تتلاشى: فالتغييرات تتضخم، والمراجعات تصبح سطحية، والتكرار يزداد. وقد وثّقت GitClear أن الكتل المكررة زادت ثمانية أضعاف في عام 2024.
بقاعدة بسيطة: لا أحد يدمج كودًا لا يستطيع شرحه على السبورة، موضحًا المشكلة التي يحلها، وسبب حلها بهذه الطريقة، وماذا سيحدث لو اختفى. لا يتطلب الأمر فهم كل تفاصيل التنفيذ.
ثلاثة: دليل كتابي من شخص واحد يعبر عما تتوقعه الشركة، وتوثيق القرار والبديل المستبعد، وحد أقصى لحجم كل تغيير يجبر العمل على التقسيم إلى وحدات مفهومة.
لأن النسخ هو الرد المعتاد عندما لا تفهم ما هو موجود بالفعل بشكل كافٍ لإعادة استخدامه. كل نسخة تزيد من عدد المواضع التي سيتعين فيها تطبيق نفس الإصلاح في المستقبل.
اطلب من أحد أعضاء الفريق شرح سبب تصميم وحدة مختارة عشوائيًا بهذه الطريقة. إذا كان الشرح منطقيًا، فسيكون النظام قابلاً للصيانة رغم عيوبه؛ أما إذا كان الجواب هو أنه يعمل ولا أحد يعرف السبب، فسيكلف كل تغيير أكثر من المتوقع.
ما مدى فهم فريقك لنظامك اليوم؟ نقوم بمراجعة البنية، والبرمجيات، والديون، والأمن، ونقدم التشخيص المكتوب في غضون 10 أيام عمل، بسعر ثابت. طلب التدقيق →
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
