كل مؤسس اشتغلت معاه ورث كود توقف عن التطور، وصل في مرحلة سأل فيها نفس السؤال، بنفس نبرة الإرهاق:
"مش الأفضل نعيد كتابة كل حاجة من الأول؟"
عايش مع النظام مدة كافية عشان يعرف إيه المكسور فيه. شايف الفتحات. كل خاصية جديدة بتاخد ضعف الوقت اللي المفروض تاخده. الباجز بترجع تاني. آخر ثلاث مبرمجين اتعاملوا معاه — واحد سابك واثنين اختفوا. وعلى الطرف التاني من السؤال في خيال: كود بيز نظيف، فريق سريع، ولا مفاجآت.
اتعاملت مع القرار ده من الجهتين — طُلب مني إعادة كتابة أنظمة كان المفروض ما نعيد كتابتها، وطُلب مني تصليح أنظمة كانت فعلاً محتاجة إعادة كتابة. الغلطة واحدة في الاتجاهين: القرار بيتعامل معاه كأنه سؤال تقني، بينما هو في الأصل سؤال بيزنس.
الأول: أنت فعلاً في الموقف ده؟
قبل ما تصرف أسبوع تناقش تصليح ولا إعادة كتابة، تأكد إنك فعلاً في الموقف المحتاج النقاش ده. غالباً المؤسسين بيفتكروا إنهم محتاجين إعادة كتابة، بينما هم فعلاً محتاجين حاجة أبسط من واحدة من التلاتة دول:
شخص خبير لمدة أسبوعين. أحياناً المشكلة مش في الكود — المشكلة إن اللي بيلمسه دلوقتي مش فاهمه. لما تجيب شخص خبرته أعلى يعمل مراجعة، ويوثّق، ويصلح أسوأ ثلاث نقاط، الوضع بيتغير كلياً. مش حاجة براقة، لكنها أعلى قرار من ناحية الفايدة/التكلفة.
نظام اختبارات مش موجود. لو كل نشرة (deploy) بتحس إنها روليت روسي، الحل مش إعادة الكتابة — الحل تكتب الاختبارات اللي بتخليك تغير الكود بأمان. الكود اللي مش قادر تغيره هو كود بتخاف منه، مش كود سيء بذاته.
ترقية استضافة أو بنية تحتية. "النظام بطيء" أو "النظام مكسور" غالباً بيطلع "قاعدة البيانات على أرخص خطة" أو "مفيش طبقة كاش". شفت مؤسسين وافقوا على إعادة كتابة بـ 200,000 ريال لمشكلة كان ترقية قاعدة بيانات بـ 800 ريال هتحلها.
أنت فعلاً في موقف قرار "تصليح ولا إعادة كتابة" لما التلات نقاط دي كلها صح:
1. الكود فعلاً متشعبك — مش مجرد غير مألوف. أكتر من مبرمج شافه وقالوا نفس الرأي بشكل مستقل. 2. إضافة خاصية جديدة بتكلف 3-5 أضعاف اللي هتكلفه على كود نظيف، والوضع مش بيتحسن. 3. مشكلة البيزنس اللي محتاج تحلها بتتطلب تغيير هيكلي المعمارية الحالية مش قادرة تستوعبه (دور مستخدم جديد، نموذج بيانات جديد، multi-tenancy، أو حجم مختلف كلياً).
لو عندك واحدة بس من التلاتة دول، مش محتاج إعادة كتابة. محتاج واحدة من الحلول التلاتة الأبسط اللي فوق.
طريق التصليح — لما يكسب (في الغالب)
التصليح (Refactor) هو الإجابة الافتراضية، والصح تقريباً في 80% من الحالات. ليه:
الكود اللي عندك بيشتغل، حتى لو شكله وحش. كل خاصية فيه بتمثل تغذية راجعة من العملاء، وحالات استثنائية اكتشفتها بالطريقة الصعبة، وتكاملات مع أنظمة تانية كلفتك جهد لحد ما ضبطتها. إعادة الكتابة بتفقد كل ده كمعرفة ضمنية، والفريق الجديد بيتعلمها تاني. كل إعادة كتابة عاصرتها اكتشفت من جديد نفس الثلاث أو أربع سلوكيات "الغريبة" اللي طلعت في الآخر متطلبات عميل حرفية.
التصليح قابل للتراجع. لو التصليح مشى غلط، تقدر توقف، تشحن النسخة الحالية، وتكمل بعدين. إعادة الكتابة رهان كبير — مش هتقدر تشحن "نص إعادة الكتابة" جنب النظام القديم من غير ما تعمل نمط الـ Strangler (هنتكلم عنه). أغلب الفرق مش بتعمل ده.
التصليح بيحافظ على استمرار الدخل. خلال إعادة كتابة كاملة، عادة بتجمّد الكود القديم — مفيش خصائص جديدة، مفيش تصليح باجز إلا الحرجة، كل حاجة بتتضحى بيها عشان إعادة الكتابة. التجميد ده غالباً هو المرحلة اللي المؤسسين بيخسروا فيها عملاء وزخم.
التصليح بيتراكم. كل جولة تصليح بتخلي الخاصية اللي بعدها أرخص شوية. إعادة الكتابة مش بتتراكم؛ بتـ reset.
طريق التصليح بيكسب لما بيزنسك لسه بيتعلم إيه اللي هيبنيه، ولما قاعدة عملائك بتكبر، ولما تقدر تتحرك بثبات لكن مش تقدر توقف، ولما المعمارية سليمة أساساً بس التنفيذ مبعثر.
طريق إعادة الكتابة — لما فعلاً يكسب (نادراً)
إعادة الكتابة الحقيقية نادرة ومحددة. في سبع سنين من شحن منتجات في مجالات مختلفة، أقدر أعد على أصابع يد واحدة المواقف اللي كنت هقول فيها لمؤسس يعيد الكتابة.
إعادة الكتابة هي القرار الصح لما:
الافتراض الأساسي تحت التطبيق بقى غلط. بنيت SaaS لعميل واحد ودلوقتي كل صفقة enterprise بتتطلب multi-tenant. بنيت لدولة واحدة ودلوقتي الالتزام القانوني بيفرض عزل بيانات لكل منطقة. بنيت synchronous والبيزنس محتاج eventual consistency. دي مش تصليحات؛ دي منتجات مختلفة.
الـ tech stack فعلاً مش قابل للدعم. مش "قديم" — مش قابل للدعم. Frameworks اتخلى عنها أصحابها، محركات قواعد بيانات محدش قادر يوظف عليها، منصات استضافة بتقفل. في فرق بين "أنا مش عاجبني Laravel" وبين "PHP 5.6 خلاص وقفت الدعم، والاستضافة هتقفل الدعم خلال 6 شهور".
الفريق كله مشي ومحدش عايز يلمس الكود. ده إشارة بيزنس، مش تقنية. لو قدرتك على التوظيف اتحبست بسبب الـ stack، ده تكلفة حقيقية.
إعادة الكتابة بتدفع تكلفتها في أقل من 12 شهر. مش "هتبقى حاجة كويسة" — رياضة فعلية. لو إعادة الكتابة بتفتح صفقة معينة، أو زيادة سعر معينة، أو تقليل تكلفة معينة بتسدد الاستثمار في سنة أو أقل، اعمل. لو مش قادر تحط رقم على التسديد، مش بتاخد قرار بيزنس.
كل حاجة تانية إما تصليح، أو الطريق الثالث اللي أغلب المؤسسين بيفوتوه.
الطريق التالت: إعادة كتابة جراحية (نمط الـ "Strangler")
الغلطة اللي بيقع فيها أنصار إعادة الكتابة إنهم بيتعاملوا مع القرار كأنه ثنائي. مش كده. في خيار تالت بياخد فوائد الاتنين وسلبيات ولا واحد فيهم، وده اللي بنصح بيه غالباً.
سيّب النظام القديم شغال. مرر الخصائص الجديدة من نظام جديد. هاجر الخصائص القديمة واحدة واحدة، بس لما تلمسها.
ده نمط الـ Strangler (اسمه من شجر الـ strangler figs، اللي بينمو حوالين شجرة مضيفة ويستبدلوها تدريجياً). في التطبيق:
- بتضيف طبقة توجيه (routing) قدام التطبيق القديم.
- الخصائص الجديدة بتتبنى في الـ stack الجديد، ورا طبقة التوجيه.
- الخصائص القديمة بتفضل على الـ stack القديم لحد ما تحتاج تغيير محدد.
- على مدى 6-18 شهر، الـ stack الجديد بيكبر والقديم بيصغر. في النهاية تقدر تقفل القديم.
الميزة: مش بتتوقف عن شحن الخصائص للعملاء أبداً. التطبيق القديم بيفضل شغال. الدخل بيفضل جاي. بتهاجر بشكل انتهازي — لما خاصية محتاجة تغيير على أي حال، بتبنيها في الـ stack الجديد بدل ما ترقّع القديم.
العيب: بتشغّل نظامين لفترة. هيكون في تكرار، تعقيد في التوجيه، وهتحتاج انضباط عشان الحالة "المؤقتة" ما تبقاش دايمة (هتبقى دايمة لو ما وضعتش milestones).
تقريباً كل إعادة كتابة كبيرة سمعت عنها ونجحت، استخدمت نسخة من النمط ده. تقريباً كل إعادة كتابة "big bang" سمعت عنها وفشلت، مش استخدمته.
إطار القرار — 5 أسئلة
لما مؤسس بيجيبلي السؤال ده، بمشي على الخمس أسئلة دي. ولا واحد منهم تقني.
1. دخلك بينمو، ثابت، ولا بينزل؟ لو الدخل بينمو، مش قادر تتحمل تجميد. اعمل نمط الـ Strangler أو تصليح. لو بينزل، السؤال الصريح هل الكود هو السبب — لو لأ، إعادة الكتابة مش هتنقذك؛ product-market fit هينقذك.
2. عندك كام شهر runway؟ إعادة الكتابة بتاخد وقت أطول من تقديرك. كل واحدة عاصرتها زادت 30-60% عن الجدول الزمني. لو عندك أقل من 12 شهر، مش قادر تتحمل إعادة كتابة بتاخد 6 شهور من الهندسة من غير قيمة قابلة للشحن في وسطها.
3. إيه نتيجة البيزنس المحددة اللي إعادة الكتابة بتفتحها؟ "تطوير أسرع في المستقبل" مش نتيجة — دي أمنية. "نقدر نقفل صفقات enterprise محتاجة multi-tenancy" نتيجة. "نقدم تعاون real-time المنافس بيحاسب عليه 3 أضعاف" نتيجة. لو مش قادر تسمي النتيجة في جملة واحدة، معندكش case بيزنس.
4. مين اللي هيعمل الشغل ده؟ نفس الفريق اللي بنى الكود الحالي؟ هيعيدوا نفس فئة المشاكل في الجديد — مش إهانة؛ ده طبيعة البشر. فريق جديد بنفس العمليات؟ نفس النتيجة. إعادة الكتابة أرجح إنها تنتهي أحسن من التصليح بس لو الناس، أو العمليات، أو الاتنين، مختلفين كمان.
5. إيه اللي هيحصل لو ما عملتش ده لمدة 6 شهور تانية؟ لو الإجابة الصريحة "هنشحن أبطأ شوية ونتذمر أكتر"، صلّح. لو "هنخسر تالت أكبر عميل" أو "مش هنقدر ناخد الصفقة قدامنا"، بقى عندك دافع حقيقي.
لو أربعة من خمسة أسئلة بيوجهوا لنفس الاتجاه، ده جوابك. لو مختلطين، الجواب تقريباً دايماً هو الطريق الجراحي/الـ Strangler.
مثال حقيقي
اشتغلت مع صاحب بيزنس صغير في مصر عنده متجر إلكتروني اتبنى بواسطة freelancer 3 سنين فاتوا واختفى. الموقع شغال بس كل تغيير كان بياخد أسابيع. عايز يعيد كتابة كل حاجة على stack مودرن.
مشينا على الإطار:
- الدخل: بينمو (مش قادر يتحمل تجميد)
- الـ runway: صحي بس مش لانهائي
- نتيجة البيزنس: "عايزين نضيف برنامج ولاء للعملاء الموقع الحالي مش قادر يدعمه"
- الفريق: نفس المبرمج اللي ورث الموقع (ولا إعادة كتابة هتصلح العملية)
- تكلفة عدم عمل حاجة لـ 6 شهور: مزعجة، مش وجودية
الجواب مكانش إعادة كتابة. كان تصليح لمدة أسبوعين لتدفق الـ checkout (النقطة الساخنة الوحيدة اللي بتفرق)، بالإضافة لموديل ولاء جديد اتبنى كخدمة منفصلة بتتكلم مع الموقع الموجود عن طريق API. ستة أسابيع شغل بدل ستة شهور. الكود القديم فضل بيعمل شغله. الخاصية الجديدة اتشحنت. الدخل فضل بينمو خلال ده كله.
ده اللي "جراحي" شكله في التطبيق: بتبني الشيء الجديد جنب الشيء القديم، مش على رماده.
إيه اللي تعمله الأسبوع ده
لو أنت المؤسس اللي بيقرا ده والقرار ده معلق عليك:
ما تاخدش القرار تحت ضغط. أسوأ إعادات كتابة شفتها ابتدت في حالة ذعر — بعد انقطاع سيء، بعد ما مبرمج سنيور مشي، بعد شكوى من عميل كبير. اديها لنفسك أسبوع قبل ما تلتزم بأي حاجة هيكلية.
اطلب رأي من الخارج. مش من شركة هتبيعلك إعادة كتابة (هيوصوا بيها دايماً). من حد الدافع بتاعه إنه يديك الجواب الصريح — صديق تقني، مستشار، أو مراجعة كود مستقلة. ساعتين مع الشخص الصح هيوفروا عليك شهور من القرار الغلط.
شغّل الخمس أسئلة اللي فوق مع فريقك. اكتب الإجابات. لو مش قادر تحط أرقام محددة أو نتائج محددة جنب كل واحد، مش جاهز تاخد القرار.
لو لسه مش متأكد إيه اللي مشروعك محتاجه بالظبط، أداة التخطيط المجانية على الموقع هتحدد لك نطاق واقعي، جدول زمني، وتقدير تكلفة في حوالي 60 ثانية بالعربية. مش هتقولك تعيد الكتابة ولا لأ — بس هتديك خط أساس لشكل النسخة المرتبة من منتجك، وده غالباً القطعة الناقصة في القرار ده.
التصليح هو الافتراضي. إعادة الكتابة نادرة ومحددة. نمط الـ Strangler هو غالباً اللي أنت فعلاً محتاجه.
المؤسسون اللي بياخدوا القرار ده صح مش هم أصحاب أفضل حدس تقني. هم اللي بيسألوا سؤال البيزنس الأول ويسيبوا الجواب التقني يتبعه.
---
لو أنت بتبص على كود بيز ومش عارف على أي من الثلاث طرق دي أنت، ده بالظبط اللي بشتغله. تواصل من خلال صفحة التواصل بفقرة عن اللي بيحصل، وهقولك بصراحة إيه اللي هعمله في مكانك — من غير عرض بيع.