تطبيق مفاهيم البرمجة بالذكاء الاصطناعي بشكل عشوائي يضاعف ديونك التقنية. ليلة الخميس قبل تسليم منصة إدارة المخزون لعميل في الدار البيضاء، واجهت موقفا حاسما. كنت أراجع الكود النهائي للمشروع. الشاشة أمامي امتلأت بعشرات الأسطر لسكريبت مزامنة معقد.
المطور في فريقي قضى يومين يبني هذا السكريبت. الهدف كان تجنب تكرار الكود بين ملفات الإعدادات المختلفة. الحل بدا ذكيا جدا في ظاهره. لكنه كان تعقيدا برمجيا لا داعي له إطلاقا. كان يكفينا توحيد مصدر الإعدادات في ملف مركزي واحد. بدلا من ذلك، بنينا جسرا تقنيا متطورا فوق مشكلة معمارية سطحية.
أدركت حينها الفخ الذي وقعنا فيه. كنا نستخدم GitHub Copilot لكتابة حلول سريعة. هذه الحلول عالجت مشاكل كان يجب ألا توجد أصلا. أوقفت العمل فورا وحذفت السكريبت بالكامل. بدأت من الصفر وجمعت الإعدادات في وحدة مركزية. في عشرين دقيقة تخلصنا من مئة وخمسين سطرا برمجيا زائدا. سلمنا المشروع ليعمل باستقرار تام دون أعطال.
لهذا أسست مدونة Hcouch Digital منذ سنوات. المطورون العرب يستحقون تعلم بناء أساس تقني متين. لا يجب تغليف الأخطاء المعمارية بأتمتة معقدة.
- 1 فخ الإنتاجية الوهمية في عصر الأتمتة الذكية
- 2 تأثير مفاهيم البرمجة بالذكاء الاصطناعي على الديون التقنية
- 3 تحليل الفجوة بين الأوامر (Prompts) والمبادئ الهندسية
- 4 لماذا نفضل الهندسة المفرطة على الإصلاح الهيكلي؟
- 5 متى تكون الأتمتة ضرورة وليست رفاهية هندسية؟
- 6 استراتيجيات إعادة توجيه الذكاء الاصطناعي نحو البساطة
- 7 كيف قلصت حجم مشروع React بنسبة 40٪ دون أدوات إضافية
- 8 العودة إلى الأساسيات الهندسية
فخ الإنتاجية الوهمية في عصر الأتمتة الذكية
في المشهد التقني الحالي، نخلط غالبا بين إنجاز المزيد وإنجاز الأفضل. نستخدم قوة أدوات الأتمتة لإخفاء مشاكل هيكلية عميقة في تصميم الأنظمة.
كتابة كود إضافي لحل مشكلة تنظيمية يعتبر هندسة مفرطة. إنها تشبه استخدام سيارة سباق لحرث حقل زراعي. الأداة قوية، لكن الاستخدام خاطئ تماما.
1.1 الفرق بين حل المشكلة وأتمتة أعراضها
المطور المحترف يبحث دائما عن الجذر الهيكلي للمشكلة. بينما المطور المعتمد كليا على الأدوات يكتفي بمعالجة النتائج السطحية. واجهت هذا في مشروع تطبيق مالي حديث. المطور كتب خمسين سطرا من الأتمتة لمزامنة المتغيرات. كان الأجدر به نقل خمسة أسطر فقط إلى وحدة مشتركة.
عندما نؤتمت الأعراض، نحن نضاعف الفوضى بدلا من تقليلها. الأتمتة تعمل كمضاعف للقوة المتاحة. إذا ضاعفت نظاما فوضويا، ستحصل على فوضى أسرع وأكثر تعقيدا. يجب أن نسأل أنفسنا دائما عن سبب المشكلة الأصلي.
1.2 مبدأ DRY مقابل حلول الجسور التقنية
مبدأ DRY (Don’t Repeat Yourself) هو أساس التصميم البرمجي النظيف. غياب هذا المبدأ يخلق بيئة خصبة للأخطاء والتكرار. بدلا من تطبيق هذا المبدأ، نبني جسورا تقنية معقدة. نستخدم أدوات الذكاء الاصطناعي لربط أجزاء مكررة كان يجب دمجها.
هذا النهج يخلق وهما بالإنتاجية والإنجاز السريع. الكود المولد يعمل وينفذ المطلوب بدقة عالية. لكنه يضيف طبقات من التعقيد غير المبرر للمشروع. هذا الخلط بين الإنتاجية والتعقيد يقودنا مباشرة لفهم كيف تتضخم الديون المخفية.
تأثير مفاهيم البرمجة بالذكاء الاصطناعي على الديون التقنية
الديون التقنية كانت مكلفة جدا في الماضي القريب. إعادة هيكلة الكود (Refactoring) تطلبت ساعات من التركيز العميق. كان على الفريق تتبع الاعتماديات يدويا واختبار كل تغيير. هذه التكلفة العالية كانت تدفع الفرق لتجنب الديون منذ البداية.
2.1 مفارقة الديون الرخيصة وسهولة التأجيل
اليوم، انخفضت تكلفة إعادة الهيكلة بشكل جذري. يمكنك تمرير كود فوضوي إلى نموذج لغوي كبير. سيقوم بتنظيفه وتنظيمه في ثوان معدودة. هذه السهولة خلقت مفارقة خطيرة في بيئة العمل. المطورون يؤجلون الإصلاحات لأنهم يعلمون أن الذكاء الاصطناعي سيحلها لاحقا.
بدلا من معالجة السبب الجذري، تبني الفرق حلولا مؤقتة. لقد تحول الأمر إلى ظاهرة حيث يصبح التعقيد المفرط ميزة بفضل الذكاء الاصطناعي. المطور لا يسأل كيف يصلح المعمارية. بل يسأل الأداة كيف تؤتمت هذا الإزعاج التقني.
2.2 تراكم ديون الاستيعاب (Comprehension Debt)
الاعتماد الكلي على الأكواد المولدة يخلق نوعا جديدا من الديون. أسمي هذا “ديون الاستيعاب” أو الفهم الداخلي للنظام. النظام يعمل بكفاءة، لكن الفريق لا يفهم تفاصيله الدقيقة. التعقيد ينمو بسرعة تتجاوز قدرة العقل البشري على استيعابه.
في أحد مشاريع التجارة الإلكترونية، واجهنا هذه المشكلة بدقة. وظفنا الذكاء الاصطناعي لتوليد نظام معقد لخصومات المنتجات. الكود كان يعمل بشكل مثالي في البداية. لكن عند حدوث خطأ، عجز الفريق عن تتبع المنطق الداخلي. تراكم هذه الديون يفرض علينا مراجعة الطريقة التي نوجه بها أدواتنا الذكية.
تحليل الفجوة بين الأوامر (Prompts) والمبادئ الهندسية
جوهر المشكلة يكمن في طريقة صياغتنا للمشاكل التقنية. لحل مشكلة برمجية، يجب على المطور فهم طبيعتها أولا. إذا لم يفهم المطور قيمة “المصدر الوحيد للحقيقة”، سيوجه الأداة بشكل خاطئ. سيطلب من الذكاء الاصطناعي الحفاظ على النهج الخاطئ بدلا من إصلاحه.
3.1 خطورة التحسين المحلي على حساب النظام الكلي
أنظمة الذكاء الاصطناعي بارعة جدا في تحسين الأوامر المباشرة. لكنها تعمل في نطاق محلي ضيق جدا. لا تملك هذه الأدوات سياقا شموليا لمعمارية النظام بالكامل. لذلك، تنتج حلولا صحيحة محليا ومضرة هيكليا.
هذا يذكرني بمحاولات استخلاص البيانات بالذكاء الاصطناعي كبديل لأدوات تقليدية. طلبنا من الأداة معالجة بيانات غير مهيكلة محليا. النتيجة كانت استهلاكا هائلا للموارد بدلا من إصلاح واجهة برمجة التطبيقات (API). قمنا بتحسين وظيفة صغيرة، لكننا أرهقنا الخادم بأكمله.
3.2 صياغة الأوامر بمنظور المعماري لا المبرمج
توجيه النماذج اللغوية يتطلب عقلية مهندس معماري أولا. يجب ألا نطلب كتابة كود لحل مشكلة سطحية. بل يجب أن نطلب اقتراح هيكلة تلغي المشكلة من جذورها. البرومبت الناجح يركز على تقليل التعقيد، وليس زيادة الأسطر.
في مشروع إدارة موارد بشرية، غيرنا طريقة كتابة الأوامر. بدلا من طلب “اكتب دالة لمزامنة بيانات الموظفين”. طلبنا “كيف نصمم قاعدة بيانات تمنع تكرار بيانات الموظفين؟”. النتيجة كانت تصميما نظيفا ألغى الحاجة لأي كود مزامنة. رغم وضوح هذه المبادئ، يظل هناك ميل غريب لاختيار الحلول الأكثر تعقيدا.
لماذا نفضل الهندسة المفرطة على الإصلاح الهيكلي؟
هذا النمط المتكرر في هندسة البرمجيات ليس صدفة. هناك دوافع نفسية ومؤسسية تدفعنا نحو التعقيد المفرط. الحلول البسيطة غالبا لا تبدو مبهرة أو متطورة كفاية. بينما بناء أدوات معقدة يمنح شعورا عميقا بالإنجاز التقني.
4.1 جاذبية الأدوات الحديثة في بيئة العمل
الأتمتة الذكية تبدو دائما وكأنها تقدم حقيقي. بناء وكيل ذكي (AI Agent) لإدارة الإعدادات يبدو عملا ضخما. مقارنة ذلك بإعادة هيكلة بسيطة تجعل الإصلاح يبدو مملا. المطورون ينجذبون لتجربة أحدث التقنيات في مشاريعهم اليومية.
في وكالة تسويق رقمي تعاملت معها، صمموا نظاما معقدا. بنوا بوت ذكاء اصطناعي لتتبع التغييرات في لوحة التحكم. كان بإمكانهم ببساطة استخدام نظام صلاحيات قياسي متوفر مجانا. الرغبة في استخدام التقنية الحديثة أعمتهم عن الحل البسيط.
4.2 نظام المكافآت والظهور بمظهر المبتكر
الشركات تكافئ غالبا المطور الذي يسلم ميزات مرئية. لا أحد يصفق لمن يحذف مئة سطر من الكود التالف. تحسين جودة التصميم الداخلي لا يظهر في تقارير الأداء. هذا يشجع الفرق على بناء أدوات جديدة بدلا من التبسيط.
التحسين قصير الأجل يسيطر على قرارات التطوير السريعة. من الأسهل معالجة الأعراض بأداة جاهزة وسريعة. العودة للقرارات التأسيسية تتطلب وقتا وشجاعة للاعتراف بالخطأ. لكن يجب ألا ننسى أن هناك سيناريوهات تكون فيها هذه الأتمتة حتمية.
متى تكون الأتمتة ضرورة وليست رفاهية هندسية؟
ليس كل سكريبت مزامنة يعبر عن خلل في التصميم. يجب أن نميز بوضوح بين التعقيد المتأصل والتعقيد المضاف. بعض المشاريع تفرض قيودا هندسية لا يمكن تجاوزها ببساطة. هنا، تصبح أدوات الذكاء الاصطناعي ضرورة قصوى وليست رفاهية.
5.1 التعامل مع الأنظمة الموزعة والقيود الحتمية
الأنظمة الموزعة (Distributed Systems) تتطلب مستوى حتميا من التكرار. عند النشر في بيئات متعددة، لا مفر من مزامنة البيانات. البنية التحتية للخدمات المصغرة (Microservices) تفرض تنسيقا مستمرا بين الخوادم. في هذه الحالات، الأتمتة تعالج قيودا حقيقية في النظام.
عملت على إعداد خوادم Kubernetes لشركة لوجستية. احتجنا لمزامنة مفاتيح التشفير بين عدة خوادم منفصلة جغرافيا. هنا استخدمنا سكريبتات ذكية لمراقبة وتحديث المفاتيح تلقائيا. هذا لم يكن عيبا معماريا، بل استجابة طبيعية لتعقيد البنية.
5.2 اختبار ‘المصدر الوحيد للحقيقة’ قبل البرمجة
قبل كتابة أي كود أتمتة، طبق اختبارا بسيطا جدا. اسأل نفسك: هل يمكن دمج هذه البيانات في مكان واحد؟ إذا كانت الإجابة نعم، فأنت أمام مشكلة تصميم هيكلي. لا تكتب كودا جديدا، بل أعد تنظيم الكود الحالي.
إذا كانت الإجابة لا بسبب قيود أمنية أو جغرافية. فهنا يمكنك توظيف الذكاء الاصطناعي لبناء جسر مزامنة آمن. هذا الاختبار السريع يوفر مئات الساعات من الصيانة المستقبلية. تمييز هذه الحالات يقودنا لتبني استراتيجيات تجعل الذكاء الاصطناعي شريكا في التبسيط.
استراتيجيات إعادة توجيه الذكاء الاصطناعي نحو البساطة
الهدف الأساسي للمطور ليس كتابة كود أكثر ذكاء. الهدف هو حل المشاكل بأقل قدر ممكن من التعقيد. يمكننا تحويل الذكاء الاصطناعي من أداة تعقيد إلى شريك تبسيط. يتطلب هذا تغييرا في طريقة تواصلنا مع هذه النماذج.
6.1 استخدام الذكاء الاصطناعي في كشف التعقيد المفرط
بدلا من طلب كتابة كود، اطلب مراجعة الكود الحالي. وجه الأداة للبحث عن الأجزاء التي تخالف مبادئ التصميم النظيف. اطلب منها تحديد المنطق المكرر واقتراح طرق لدمجه مركزيا. الذكاء الاصطناعي ممتاز جدا في كشف الأنماط المتكررة المخفية.
في أحد المراجعات، مررت طلبا (Pull Request) إلى ChatGPT. طلبت منه تحديدا البحث عن انتهاكات لمبدأ عدم التكرار. استخرج الأداة ثلاث دوال مختلفة تقوم بنفس الوظيفة بالضبط. قمنا بدمجها فورا قبل اعتماد التحديث في النسخة النهائية.
6.2 هندسة الأوامر لتقليل عدد السطور والاعتماديات
عند الحاجة لكتابة كود جديد، اشترط البساطة في أوامرك. اطلب حلولا تعتمد على أدنى حد من المكتبات الخارجية. استخدم مصطلحات مثل (Minimalist Solution) في توجيهاتك للنماذج اللغوية. هذا يحد من ميل الذكاء الاصطناعي لاستعراض عضلاته البرمجية.
اشترط دائما أن يكون الحل قابلا للقراءة بواسطة مطور مبتدئ. إذا كان الكود المولد معقدا جدا، اطلب تبسيطه فورا. الكود الأقل يعني أخطاء أقل وصيانة أسهل في المستقبل. لتوضيح هذه الاستراتيجيات، سأشارككم كيف طبقتها مؤخرا في أحد المشاريع المعقدة.
كيف قلصت حجم مشروع React بنسبة 40٪ دون أدوات إضافية
استلمت مشروع واجهة مستخدم مبني بإطار React من فريق آخر. المشروع كان بطيئا جدا ومليئا بدوال مساعدة (Helper Functions) مولدة آليا. كل وظيفة بسيطة كان لها سكريبت ذكي خاص بها. الكود كان يعمل، لكن الصيانة أصبحت كابوسا يوميا للفريق.
قررت استخدام Claude 3.5 Sonnet بطريقة مختلفة تماما. لم أطلب منه كتابة سطر واحد من الكود الجديد. بدلا من ذلك، طلبت منه رسم خريطة لاعتماديات الحالة (State Management). قلت له: “حدد لي مسارات المنطق المكررة التي تدير نفس البيانات”. النتيجة كانت صادمة، وجدنا تكرارا هائلا في جلب البيانات وتخزينها.
بدأنا في حذف الأكواد الزائدة بناء على هذا التحليل. لم نضف أي أدوات جديدة أو مكتبات خارجية معقدة. اعتمدنا فقط على توحيد مصدر البيانات في مكونات رئيسية. النتيجة كانت تقليص حجم الكود بنسبة 40٪ بالكامل. التطبيق أصبح أسرع بكثير، واستعاد الفريق قدرته على فهم المشروع.
العودة إلى الأساسيات الهندسية
الذكاء الاصطناعي أداة قوية لاستكشاف آفاق تقنية جديدة ومعقدة. يجب استخدامه لتحسين الخوارزميات الصعبة ومعالجة المهام الروتينية الحتمية. لكنه لا يجب أن يصبح طبقة افتراضية لترقيع الأساسات الضعيفة. إذا كنت ترقي أدواتك فقط للتأقلم مع فوضى مشروعك، فتوقف.
الوقت قد حان لإعادة تشكيل بيئة المشروع من الداخل. التوقف عن الاحتفاء بأتمتة المهام التي كان يجب حذفها أصلا. افتح آخر مشروع برمجته بمساعدة الذكاء الاصطناعي هذا الأسبوع. ابحث عن ملفات المزامنة أو الأكواد المكررة في مشروعك. كم سطرا برمجيا يمكنك حذفه الآن بمجرد توحيد مصدر البيانات؟
اكتشاف المزيد من أشكوش ديجيتال
اشترك للحصول على أحدث التدوينات المرسلة إلى بريدك الإلكتروني.
