تُنتج تقنية البرمجة التفاعلية - التي تعتمد على وصف المطلوب وقبول الكود الناتج عن النموذج دون مراجعة معمقة - نماذج أولية في غضون ساعات وأنظمة هشة في غضون أشهر. إنها ليست تقنية غير مشروعة، بل هي تقنية ممتازة لاستكشاف فكرة ما، ولكنها خطيرة عند بناء شيء تعتمد عليه شركة ما.
يكمن الإشكال في الخلط بين المفهومين. فما ينتج عن جلسة تصميم منتج من قِبل المستخدم يشبه إلى حد كبير المنتج الحقيقي: له واجهة، ويستجيب، وينفذ ما طُلب منه أمام المستخدم. لكن الفرق مع المنتج الحقيقي لا يكمن في وظيفته، بل في كل ما لم يُحسم بعد: ماذا يحدث عند تعطلّه، ومن يمكنه رؤية ما يُعرض عليه، وكيف سيتم تعديله خلال عام، ومن يفهم سبب كتابته بهذه الطريقة.
|
الأبعاد |
تم إنشاء النموذج الأولي |
النظام قيد الإنتاج |
|---|---|---|
|
هدف |
لإثبات أن الفكرة ممكنة |
يعمل بكفاءة وموثوقية لسنوات |
|
أخطاء |
يتم تصحيحها عن طريق التجديد |
يتم إصلاحها دون إتلاف الباقي |
|
بيانات |
تم اختباره، نظيف |
حقيقي، غير مكتمل، متناقض |
|
حماية |
بعيد عن متناول اليد |
الأذونات، والتشفير، والتدقيق |
|
صيانة |
غير قابل للتطبيق |
يمثل البند 60-70% من التكلفة الإجمالية |
|
ملكية المعيار |
حدد النموذج البنية |
لقد اتخذ أحدهم هذا القرار وهو يعلم السبب. |
يحمل السطر الأخير أهمية بالغة على المدى المتوسط. فعندما لا يُحسم أمر البنية، لا يمكن لأحد الدفاع عنها أو تطويرها. تصبح نصًا يتطلب تفسيرًا في كل مرة يُعاد النظر فيه، وهذا التفسير يستغرق وقتًا مع كل تغيير مستقبلي.
هذا ليس مجرد حدس صناعي. فقد وجدت شركة GitClear، من خلال تحليل 211 مليون سطر من التعليمات البرمجية بين عامي 2020 و2024، أن أعمال إعادة هيكلة التعليمات البرمجية - أي إعادة تنظيم التعليمات البرمجية الحالية لجعلها مفهومة - انخفضت من حوالي 25% من إجمالي التغيير في عام 2021 إلى أقل من 10% في عام 2024، بينما ارتفع النسخ واللصق من 8.3% إلى 12.3% وزادت الكتل المكررة ثمانية أضعاف.
استند تقرير DORA لعام 2024 الصادر عن Google Cloud، والذي شمل استطلاعًا لآراء حوالي 39,000 متخصص، إلى قياس تأثير الذكاء الاصطناعي على سرعة التسليم: حيث ارتبطت زيادة بنسبة 25% في تبني الذكاء الاصطناعي بانخفاض بنسبة 1.5% في الإنتاجية وانخفاض بنسبة 7.2% في الاستقرار. وفي الدراسة نفسها، أفاد 39.2% من المطورين بانعدام ثقتهم أو ضعفها في الكود المُولّد.
النمط الذي يصفانه متسق: يتم إنتاج المزيد، ويتم مراجعة الكمية نفسها، ويتم إعادة تنظيم كمية أقل. لا تظهر النتيجة في الأسبوع الأول؛ بل تظهر عندما يكون هناك حاجة للتغيير.
من الحماقة التخلي عن أداة تزيد سرعة الاستكشاف بشكل ملحوظ. هذه هي التطبيقات التي يُعد فيها ترميز Vibe الخيار الأمثل:
في جميع الحالات الأربع، توجد سمة مشتركة: لا يشترط أن تبقى النتيجة. في اللحظة التي يقول فيها أحدهم "هذا يكاد يكون ناجحاً، فلنضعه في الإنتاج"، يكون الاستخدام قد تغير في فئته، ويجب أن تتغير المعايير تبعاً لذلك.
قبل وضع أي شيء تم إنشاؤه بهذه الطريقة في مرحلة الإنتاج، يُنصح بالإجابة على هذا السؤال:
لم يعد النموذج الأولي الذي يجيب على خمسة أسئلة مجرد نموذج أولي، بل أصبح نظامًا تم بناؤه بسرعة، وهذا بالضبط ما نسعى إليه. لم تكن المشكلة أبدًا هي السرعة.
النمط الذي نراه في عمليات التدقيق هو نفسه دائماً. فريق صغير ينجز في ثلاثة أسابيع ما كان سيستغرق ثلاثة أشهر. تستنتج الإدارة بشكل منطقي أن التطوير أصبح أقل تكلفة. ويتم الموافقة على المزيد من المبادرات باستخدام المعايير نفسها.
بعد ستة أشهر، يستغرق كل تغيير وقتًا أطول من سابقه، ولا أحد يرغب في تعديل وحدتين محددتين، ولم تعد التقديرات موثوقة. هذه هي الصورة السريرية للدين التقني، وقد ناقشناها بالتفصيل في تكمن المشكلة مرة أخرى في الهندسة المعمارية.
الأمر اللافت للنظر هو أن التشخيص نادراً ما يشير إلى الأصل، لأن السرعة الأولية كانت حقيقية ويتذكرها الجميع على أنها نجاح.
النمط الذي نراه في عمليات التدقيق هو نفسه دائماً. فريق صغير ينجز في ثلاثة أسابيع ما كان سيستغرق ثلاثة أشهر. تستنتج الإدارة بشكل منطقي أن التطوير أصبح أقل تكلفة. ويتم الموافقة على المزيد من المبادرات باستخدام المعايير نفسها.
بعد ستة أشهر، يستغرق كل تغيير وقتًا أطول من سابقه، ولا أحد يرغب في تعديل وحدتين محددتين، ولم تعد التقديرات موثوقة. هذه هي الصورة السريرية للدين التقني، وقد ناقشناها بالتفصيل في تكمن المشكلة مرة أخرى في الهندسة المعمارية.
الأمر اللافت للنظر هو أن التشخيص نادراً ما يشير إلى الأصل، لأن السرعة الأولية كانت حقيقية ويتذكرها الجميع على أنها نجاح.
لا داعي للاختيار بين سرعة الإنتاج وجودة البناء. يجب الفصل بين المرحلتين، ويجب أن تكون واضحًا بشأن المرحلة التي أنت فيها حاليًا.
مرحلة الاستكشاف. أنشئ ما تشاء، دون مراجعة دقيقة، باستخدام بيانات وهمية، ودون التفكير في الصيانة. الهدف هو التعلم.
نقطة حاسمة. يُعلن أحدهم أن الفكرة صحيحة. وهنا يُتخذ القرار الذي نادراً ما يتخذه أحد: ما تم استكشافه يتم التخلص منه. ما يتم الحفاظ عليه هو المعرفة، وليس الشفرة.
مرحلة البناء. يتم تحديد البنية، ويتم تحديد نموذج البيانات، ويتم إبرام العقود، ثم يتم استخدام التوليد المدعوم، الآن ضمن هيكل يحدده شخص ما.
قد يبدو التخلص من النموذج الأولي إهدارًا، ولكنه ليس كذلك: فقد أدى النموذج الأولي غرضه بالفعل، وهو الإجابة على سؤال. إن الحفاظ عليه هو ما يحوّل أداة الاستكشاف إلى أساس لبناء شيء ما.
هذا الفصل هو السبب في أن الهندسة المعمارية في نظام TCG-SAF™ تسبق البناء. ليس لأسباب احتفالية، بل لأنها الطريقة الوحيدة للاستفادة من سرعة التوليد دون توريث الفوضى.
هي ممارسة توليد البرمجيات من خلال وصف المطلوب وقبول الكود الناتج عن نموذج دون مراجعته بدقة. وهي فعّالة جدًا لاستكشاف الأفكار وبناء النماذج الأولية، لكنها تُصبح إشكالية عند نشر النتيجة في بيئة الإنتاج دون إعادة تصميم.
فقط إذا أجاب على خمسة أسئلة: هل يمكن لأحد أن يشرح سبب هيكلته بهذه الطريقة، وهل هناك اختبارات تكشف عن التراجعات، وهل تم تحديد البيانات التي يتعامل معها ومن يمكنه رؤيتها، وهل هناك سجل وآلية للعودة إلى العمليات العادية، وهل هناك شخص يمكنه صيانته في غضون عام.
تشير البيانات إلى تحول في الأنماط بدلاً من تدهور مباشر. وثّقت GitClear انخفاض عمليات إعادة هيكلة الكود من حوالي 25% من إجمالي التغيير في عام 2021 إلى أقل من 10% في عام 2024، وزيادة التكرار ثمانية أضعاف. وقد رصدت DORA انخفاضًا في الإنتاجية والاستقرار في عام 2024 مع ازدياد تبني الذكاء الاصطناعي.
للتحقق من صحة فكرة ما قبل الاستثمار فيها، استكشف بدائل واجهة المستخدم، أو أنشئ أدوات داخلية مؤقتة، أو تعلّم مجالًا جديدًا. السمة المشتركة هي أن النتيجة ليست بالضرورة أن تستمر.
افصل المراحل: احتفظ بالمعرفة وتخلص من الكود. ثم حدد البنية، ونموذج البيانات، والعقود، وأعد استخدام التوليد المدعوم ضمن تلك البنية التي يحددها شخص ما.
لأن السرعة الأولية حقيقية ويتم تذكرها على أنها نجاح، بينما تصبح التكلفة واضحة عندما يكون هناك حاجة إلى تغيير شيء ما: تستغرق التغييرات وقتًا أطول فأطول، وهناك وحدات لا أحد يريد لمسها، وتتوقف التقديرات عن كونها موثوقة.
هل لديك منتج قيد الإنتاج بدأ كنموذج أولي؟ يخبرك التدقيق الفني الذي نقدمه في غضون 10 أيام عمل، وبسعر ثابت، بما يمكن الاحتفاظ به، وما يحتاج إلى إعادة هيكلة، وما يكلف المال كل شهر. طلب التدقيق →
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
