«نعيده من الصفر» من أكثر الجمل اللي نسمعها من أصحاب المنتجات اللي انبنت بـ vibe coding، وأحيانًا يقولها لهم مبرمج. أحيانًا تكون صح. بس اللي نشوفه أكثر: هيكل الكود مقبول، والناقص هو طبقة الإنتاج: الصلاحيات، والمفاتيح، والنشر، والنسخ الاحتياطي. إعادة البناء (rewrite) بنفس الطريقة ترجّع لك نفس المشاكل، بعد شهور.
قبل ما تقرر، جاوب على هالست أسئلة بصراحة.
1. عندك عملاء وبيانات حقيقية؟
إذا إيه، إعادة البناء معناها نقل البيانات والحسابات والاشتراكات للنظام الجديد، بدون ما يضيع شي وبدون ما يوقف شي. هذا مشروع لحاله. كل ما كبرت البيانات، صار الإصلاح أرخص بالمقارنة.
2. المشكلة في مكان واحد ولا في كل مكان؟
إذا جزء واحد يتعطّل دايم، مثل الدفع أو الحجوزات، غالبًا الأصح تعيد بناء هذا الجزء بس، والباقي يبقى. هذا اسمه بالإنجليزي refactor، وهو غير الـ rewrite. إذا المشاكل في كل مكان، اسأل السؤال اللي بعده.
3. الأساس نفسه مناسب؟
فيه حالات إعادة البناء فيها مبررة: البيانات محفوظة في متصفح المستخدم بدل قاعدة بيانات، أو ما فيه نظام خلفي أصلًا، أو شكل البيانات ما يناسب المنتج، مثل جدول واحد لكل شي. هنا الإصلاح يصير ترقيع فوق ترقيع.
4. فيه أحد يفهم النظام؟
إذا ولا أحد يقدر يشرح وين يصير الدفع، أو وش يصير لما عميل يسجّل، فالخطوة الأولى خريطة للنظام، مو إعادة بناء. كثير من الكود اللي يبان «فوضى» يصير مفهوم بعد يوم قراءة.
5. كل إصلاح يخرّب شي ثاني؟
هذي علامة إن ما فيه اختبارات، مو بالضرورة إن الكود سيء. أضف اختبارات لأهم المسارات أول، وبعدها قرر. الطريقة في درس كيف توقف الدوامة.
6. كم وقت وفلوس عندك؟
إعادة البناء تاخذ شهور، وطول هالشهور منتجك الحالي ما يتطوّر، ومنافسك يتطوّر. إذا عندك عملاء ينتظرون مزايا، هذي تكلفة حقيقية لازم تنحسب.
غالبًا الجواب بالنص
في أغلب المنتجات اللي نشوفها، الجواب: نصلّح طبقة الإنتاج، ونعيد بناء جزء أو جزأين بس. هذا اللي يسويه مستوى «إعادة بناء الجزء المعطّل» في الإصلاح المباشر.
لا تقرر لحالك
قرار بهالحجم يستاهل رأي من أحد ما له مصلحة في الجواب. المراجعة التقنية المستقلة بـ 1,100 ر.س تعطيك توصية مكتوبة: إصلاح، أو إعادة بناء، أو بشروط نسمّيها لك.