إنقاذ أم إعادة بناء؟ كيف تقرّر بشأن تطبيق بناه الذكاء الاصطناعي

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

هناك قاعدة تحسم الأمر، وهي ليست عن حجم الكود الذي كتبه الذكاء الاصطناعي. إنها عن قاعدة البيانات.

القاعدة: دع نموذج البيانات يقرّر

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

فالسؤال ليس «كم الكود سيئ؟» بل «هل المخطط صحيح؟»

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

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

كيف تفحص مخططك في عشر دقائق

لا تحتاج أن تكون خبير قواعد بيانات. افتح مخططك وأجب عن خمسة أسئلة بصدق.

1. هل تُخزَّن الحقيقة نفسها في أكثر من موضع؟ إن كان بريد العميل في جدول المستخدمين ومرة أخرى في جدول الطلبات، فيمكن أن يتناقضا، وسيتناقضان يوماً ما. التكرار الموجود للسرعة مقبول حين يكون مقصوداً وباتجاه واحد. أما التكرار الموجود لأن النموذج لم يُصمَّم أصلاً فهو خلل.
2. هل العلاقات موجودة أم مفترضة؟ ابحث عن مفاتيح خارجية فعلية. أدوات الذكاء الاصطناعي تولّد كثيراً جداول تشير إلى بعضها بمعرّف بلا شيء يفرضه، وهو ما يعمل تماماً حتى أول سجل يتيم، ثم يفسد تقاريرك بصمت.
3. هل يُخزَّن شيء مهم كنص غير مهيكل أو JSON؟ حقل حالة يحمل نصاً حراً بدل مجموعة قيم محدّدة يعني أن كل استعلام يرشّح عليه إنما يخمّن. كتلة JSON واحدة لبيانات وصفية مرنة معقولة؛ أما حقول الأعمال الأساسية داخل عمود JSON فلا.
4. هل تستطيع الإجابة عن أهم ثلاثة أسئلة في عملك باستعلام؟ الإيراد الشهري لكل عميل، والمستخدمون النشطون الأسبوع الماضي، والطلبات العالقة في حالة معينة. إن احتاج أي منها كوداً في التطبيق ليحسبه لأن البيانات لا تستطيع التعبير عنه، فالنموذج ينقصه شيء بنيوي.
5. هل يترك حذف سجل خلفه ركاماً؟ إن كان حذف عميل يترك طلباته وجلساته وملفاته تشير إلى لا شيء، فليست لديك قواعد حذف متسلسل، وهذه مشكلة صحّة بيانات، وفي معظم أنظمة الخصوصية مشكلة امتثال أيضاً.

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

ماذا يتضمن الإنقاذ فعلياً

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

1. المفاتيح أولاً. مفاتيح الواجهات البرمجية وروابط قواعد البيانات ورموز الخدمات المودعة في المستودع أو المشحونة إلى حزمة المتصفح. دوّرها، وانقلها إلى متغيرات بيئة، ونظّف سجل git حتى لا يسرّبها التزام قديم لاحقاً. هذا عمل ساعات وهو دائماً الشيء الأول.
2. الصلاحيات ثانياً. كل نقطة نهاية تفترض أن الواجهة تحققت مسبقاً ممّن يسأل. والنمط الكلاسيكي المولَّد بالذكاء الاصطناعي مسار يقرأ معرّف مستخدم من جسم الطلب ويثق به. وأي شخص يستطيع تغيير ذلك الرقم.
3. مسارات المال وفقدان البيانات ثالثاً. معالجة المدفوعات، وفرض الحصص، وكل ما يكتب بلا رجعة. هذه تحتاج اختبارات قبل أن يحصل عليها أي شيء آخر، لأنها الأعطال التي لا يمكنك الاعتذار عنها.
4. معالجة الأخطاء رابعاً. كتل catch الفارغة تجعل الأعطال صامتة، ما يعني أنك تعرف بها من عميل لا من المراقبة. استبدلها بتسجيل واستجابات خطأ حقيقية.
5. ثم البقية. الفهارس، وحدود المعدل، والتخزين المؤقت، وتغطية اختبارات للمسارات الحرجة، وعملية نشر ليست حاسوب شخص واحد.

في معظم التطبيقات التي نراها، هذا نحو أسبوعين من انتباه هندسي خبير. لا إعادة كتابة ولا جهد بطولي. فقط الأجزاء التي لم يطلبها أحد، منفَّذة بالترتيب الصحيح.

ماذا تتضمن إعادة البناء فعلياً

إعادة البناء لا تعني حذف كل شيء. إن نُفِّذت كما ينبغي فهي الإبقاء على الأجزاء التي تحمل معرفة حقيقية واستبدال الأساس تحتها.

• أبقِ: قرارات منتجك، وتصميم واجهتك، ونصوصك، وتكاملاتك، وقبل كل شيء فهمك لما يحتاجه العملاء فعلاً. تلك المعرفة كلّفتك شهوراً ولا شيء منها في المخطط.
• استبدل: نموذج البيانات، وطبقة الوصول، وكل ما أجبره شكل النموذج على بنية سيئة.
• رحّل: البيانات الحيّة، وهو الجزء الذي ينسى الناس تقدير كلفته. نقل سجلات العملاء القائمة إلى مخطط مصحَّح هندسة حقيقية، وهو سبب تجاوز إعادة البناء للتقدير الذي أهمله.

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

ثلاث حالات لا تنطبق فيها القاعدة

هناك مواقف يكون المخطط فيها سليماً ومع ذلك يجب أن تعيد البناء، وموقف يكون فيه المخطط خاطئاً ولا يجب.

أعد البناء رغم ذلك إن تغيّر اتجاه المنتج

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

أعد البناء رغم ذلك إن لم يستطع أحد قراءته

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

أنقذ رغم ذلك إن لم يكن لديك إيراد ولا مستخدمون

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

كم يكلّف هذا، وماذا تطلب

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

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

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

الخلاصة

• تجاهل حجم الكود الذي ولّده الذكاء الاصطناعي. ليس هو المتغيّر.
• افحص المخطط مقابل الأسئلة الخمسة. «نعم» واحدة أو لا شيء تعني إنقاذاً؛ وثلاث أو أكثر تعني إعادة بناء.
• في الإنقاذ، أصلح بترتيب الخطورة: المفاتيح، ثم الصلاحيات، ثم مسارات المال، ثم معالجة الأخطاء، ثم البقية.
• في إعادة البناء، احتفظ بمعرفة المنتج وقدّر كلفة ترحيل البيانات كما ينبغي.
• احصل على التشخيص مكتوباً قبل أن يبدأ أحد، وتأكد أنه يسمّي تفاصيل محدّدة.

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