ورثت قاعدة كود فوضوية؟ كيف تنقذ مشروعًا متعثرًا
اختفى المطوّر، أو توقف البناء، وأنت الآن تحدّق في قاعدة كود لا يفهمها أحد. إليك كيف أتسلّم المشاريع الفوضوية بأمان، وكيف تقرر بين الإصلاح وإعادة البناء.
Shayan Jamil·20 مايو 2026·5 دقائق قراءة
يبدأ جزء كبير على نحو مفاجئ من عملي بالطريقة نفسها: مؤسس لديه منتج نصف مكتمل، والمطوّر الأصلي رحل أو لا يرد، ولم يبقَ أحد يستطيع شرح كيف يعمل. توقف المشروع، والميزانية التي أُنفقت تبدو في خطر، والسؤال بسيط لكنه مقلق: هل يمكن إنقاذ هذا، أم نبدأ من جديد؟
تسلّمت الكثير من هذه المشاريع، ونادرًا ما يكون الوضع ميؤوسًا منه كما يبدو في تلك اللحظة. لكنه يحتاج إلى تعامل حذر. فالاندفاع وتغيير الأشياء دون فهم هو ما يحوّل عملية الإنقاذ إلى كارثة ثانية. إليك طريقتي في التعامل مع ذلك.
المشكلة من منظور الأعمال: أنت عالق والعدّاد يدور
المشروع المتعثر مؤلم بطريقة محددة. لقد استثمرت مالًا ووقتًا بالفعل، ولا تستطيع التقدم، ولست متأكدًا حتى مما لديك. كل خيار يبدو محفوفًا بالمخاطر: إذا واصلت فقد تبني على الرمال، وإذا بدأت من جديد فقد ترمي عملًا كان سليمًا في الحقيقة.
أسوأ خطوة هي الذعر، سواء بالتخلي عن كل شيء بشكل انفعالي أو بتوظيف شخص يبدأ فورًا بإعادة الكتابة دون فهم ما هو موجود. كلاهما يهدر المال. والخطوة الأولى الصحيحة هي نفسها دائمًا: افهم قبل أن تلمس.
الخطوة الأولى: قيّم قبل تغيير أي شيء
قبل أن أغيّر سطرًا واحدًا، أريد صورة واضحة لما هو موجود. وهذا يعني قراءة الكود، وتشغيل التطبيق، ومعرفة:
- ما الذي يعمل فعلًا مقابل ما هو معطّل أو نصف مكتمل.
- كيف بُني: الهيكل، ونموذج البيانات، والقرارات الرئيسية.
- ما هو الخطير: غياب النسخ الاحتياطية، والثغرات الأمنية، وعدم وجود طريقة آمنة للنشر.
- ما هو قديم: كثيرًا ما تكون المشاريع المتعثرة عالقة على إصدار بيئة تشغيل أو إطار عمل لم يعد يتلقى إصلاحات أمنية. فـ Node.js 20 مثلًا، وهو خيار شائع قبل عامين، انتهى دعمه في أبريل 2026. ومعرفة ذلك مبكرًا تخبرك ما إذا كانت الترقيات يجب أن تكون جزءًا من الخطة.
- ما يمكن إنقاذه وما تجاوز فعلًا مرحلة الإنقاذ.
هذا التقييم هو الجزء الأثمن في عملية الإنقاذ. فهو يحوّل عبارة "ليست لدينا أي فكرة عما لدينا" إلى خريطة واضحة وصادقة، وعليها يعتمد كل قرار جيد بعد ذلك.
أول ما أتحقق منه في أي عملية إنقاذ
هل يمكن تشغيل المشروع وأخذ نسخة احتياطية منه ونشره بأمان دون خطر فقدان البيانات أو كسر ما يعمل؟ قبل تحسين أي شيء، أتأكد من وجود شبكة أمان. لا تُجرى عملية جراحية قبل القدرة على إيقاف النزيف أولًا.
إصلاح أم إعادة بناء؟ كيف أقرر
هذا هو السؤال الذي يريد المؤسسون إجابته أكثر من أي سؤال آخر، والإجابة الصادقة هي "يعتمد ذلك على الأسس". إليك المنطق التقريبي:
مِل نحو الإصلاح عندما يكون الهيكل الأساسي سليمًا، ونموذج البيانات منطقيًا، والبنية معقولة، وتكون المشكلات فوضى وأجزاء ناقصة لا عيوبًا جوهرية. معظم المشاريع المتعثرة تقع هنا. إنها لا تحتاج إلى إعادة كتابة، بل إلى شخص يفهمها ويثبّتها ويكمل المهمة.
مِل نحو إعادة البناء عندما تكون الأسس معطوبة فعلًا: نموذج بيانات لا يستطيع دعم المنتج، أو بنية تجعل كل تغيير خطيرًا. وحتى في هذه الحالة، نادرًا ما يعني الأمر "رمي كل شيء". بل عادةً ما يعني إعادة بناء الجوهر المعطوب مع الإبقاء على الأجزاء التي تعمل.
تبدو إعادة الكتابة من الصفر نظيفة ومغرية، لكنها ترمي كل درس تعلّمه الكود الحالي بالفعل. أعامل إعادة البناء الكاملة كملاذ أخير لا كخيار افتراضي، لأن المشروع في أغلب الأحيان يمكن إنقاذه بتكلفة أقل بكثير من البدء من جديد. (وإرساء هذه الأسس بشكل صحيح هو أيضًا ما يهدف تحديد نطاق المنتج الأولي جيدًا إلى منعه من الأساس.)
لماذا يهم التسلّم الحذر
عملية الإنقاذ المستعجلة تميل إلى خلق مشكلات جديدة أثناء إصلاح القديمة. أما الحذرة فتفعل العكس: تثبّت ما هو هش، وتوثّق ما كان لغزًا، وتوصل المشروع إلى مرحلة يمكن فيها مواصلة العمل بأمان. وهذا التوثيق أهم مما يتوقعه المؤسسون، فسبب تعثر المشروع غالبًا هو أن كل شيء كان يعيش في رأس شخص واحد. وتدوينه يعني أنك لن تكون مكشوفًا بهذا الشكل مرة أخرى. وعادةً ما يكون النشر والبيئات الموثوقة جزءًا من الإصلاح أيضًا، إذ كثيرًا ما تفتقر المشاريع المتعثرة إلى طريقة آمنة لنشر التغييرات.
مثال واقعي
جزء كبير من عملي تضمّن تسلّم كود كتبه آخرون ومواصلته: إكمال الميزات، وتثبيت ما كان مهزوزًا، وإيصال المنتجات إلى مرحلة يمكن فيها إطلاقها ونموها فعلًا. وشكل العمل ثابت: أفهمه أولًا، وأجعل تغييره آمنًا، وأصلح الأجزاء الصحيحة أو أعيد بناءها بناءً على الأسس، وأوثّق أثناء العمل حتى لا يُترك الشخص التالي (أو المؤسس) يخمّن. والارتياح لدى المؤسس عادةً لا يأتي من الكود الذكي بقدر ما يأتي من امتلاك وضوح أخيرًا حول ما لديه وطريق واقعي للمضي قدمًا.
أخطاء شائعة عند إنقاذ مشروع
- الاندفاع بذعر نحو إعادة كتابة كاملة قبل فهم ما هو موجود فعلًا.
- تغيير الأشياء قبل وجود طريقة آمنة للنسخ الاحتياطي والنشر.
- افتراض أن كل شيء سيئ لأن بعضه كذلك.
- توظيف شخص يرفض قراءة الكود الحالي ويريد فقط البدء من جديد.
- عدم توثيق ما تم تعلّمه، فيبقى المشروع على بُعد شخص واحد من التعثر مجددًا.
- إصلاح الأعراض بدلًا من المشكلات الجوهرية التي سببت الفوضى.
كيف أتعامل مع عملية الإنقاذ
- أقيّم أولًا: أقرأ الكود، وأشغّله، وأرسم خريطة لما يعمل وما هو خطير.
- أضع شبكة أمان: نسخ احتياطية وطريقة آمنة للنشر قبل تغيير أي شيء.
- أقدم لك حكمًا صادقًا: إصلاح، أو إعادة بناء جزئية، أو إعادة بناء كاملة، مع الأسباب.
- أثبّت المخاطر العاجلة قبل إضافة أي شيء جديد.
- أوثّق أثناء العمل، حتى لا يعود المشروع صندوقًا أسود مرة أخرى.
- أدفعه إلى الأمام نحو الإطلاق أو المرحلة التي كنت عالقًا عندها.
الهدف هو إخراجك من حالة التعثر بأقل هدر ممكن: إنقاذ ما يستحق الإنقاذ، واستبدال ما يحتاج إلى ذلك فعلًا فقط، وإعادة مشروع يمكنك الوثوق به إليك.
هل أنت عالق مع مشروع متعثر؟
إذا كان لديك منتج نصف مكتمل ومطوّر لم يعد يرد، أو قاعدة كود لا يستطيع أحد شرحها، يمكنني تقييمها بصدق وإخبارك ما إذا كان الأفضل الإصلاح أم إعادة البناء، ثم إعادة تحريكها.
اقرأ عن طريقة عملي، وشاهد ما بنيته، ثم تواصل معي وأخبرني أين وصلت الأمور. لنحدد معًا الطريق الواقعي للمضي قدمًا.