هناك ثلاث طرق لوراثة قاعدة كود: استحوذت شركتك على واحدة، أو توليت القيادة التقنية، أو اختفت الوكالة التي بنتها. في كل الحالات تُعطى نظامًا، مجموعة توقعات، وحوالي شهر قبل أن يطلب أحد كبار المسؤولين رأيًا.
الإغراء هو البدء بقراءة الكود. لا تفعل. جودة الكود هي من أقل الأمور توقعًا يمكنك تقييمها في الأسبوع الأول، وهي الأسهل لتكوين رأي غير عادل عنها. هذا هو الترتيب الذي نعمل به.
قاعدة واحدة قبل البدء: لا تغير شيئًا في الأسبوع الأول. لا تبعية، لا قيمة إعداد، ولا تحديث composer. لا يمكنك تحديد ما هو حاسم بعد، وتعطل تسببه يدمر مصداقيتك في الإبلاغ عن الأعطال التي لم تسببها.
الأسبوع 1: هل يمكنك تشغيله؟
كل شيء آخر هو تخمين حتى تشغل النظام على جهاز تسيطر عليه.
- قم بإعداد بيئة محلية من نسخة نظيفة، وقِس الزمن الذي يستغرقه ذلك. هذا الرقم هو أفضل مؤشر وحيد لتكلفة كل تغيير مستقبلي. ساعتان تعتبر مدة صحية؛ وأسبوعان يخبرانك بمعظم ما تحتاج إلى معرفته.
- قم بجرد البيئات. الإنتاج، والمرحلة التجريبية، والخادمان اللذان لم يذكرهما أحد. اعثر عليهما من خلال قراءة DNS وحساب السحابة، لا بالسؤال.
- حدد ما الذي يعمل في كل مكان — خوادم الويب، العمال، المهام المجدولة (cron)، الطوابير، التقارير المجدولة، مستقبلات webhook. المهمة المجدولة غير الموثقة هي الفخ الكلاسيكي.
- تأكد من امتلاكك للحسابات. مسجل النطاق، DNS، الاستضافة، السحابة، المستودعات، CI، تتبع الأخطاء، بوابات الدفع، توصيل البريد الإلكتروني. فقدان الوصول هو مشكلة تجارية يجب تصعيدها في اليوم الثاني، وليس في الأسبوع الرابع.
- تحقق من وجود النسخ الاحتياطية واستعادتها. النسخ الاحتياطية غير المختبرة مجرد إشاعة. استعد نسخة إلى بيئة اختبار وانظر إليها.
- اكتشف من يعرف الأمور. غالباً شخص واحد، وأحياناً في شركة لم تعد توظفه. هذه هي أهم أصولك القابلة للتلف — احجز وقتاً معه فوراً.
الأسبوع 2: التركيز على المخاطر لا على الجودة
الآن قِس مستوى التعرض. هذه هي النتائج التي تغير القرارات وتحصل على الموافقة على الميزانية.
- إصدار PHP، لكل بيئة، مقابل الجدول الزمني للدعم الرسمي. الإصدار غير المدعوم هو النتيجة التي تتفوق على كل شيء آخر في هذه القائمة.
- عمر التبعيات وحالة الثغرات الأمنية. قم بتشغيل تدقيق على ملف القفل. احسب عدد الإصدارات الرئيسية التي يتخلف عنها الإطار — هذا الرقم، وليس أسلوب الكود، يخبرك بتكلفة الترقية.
- التبعيات المهجورة. الحزم التي لم تصدر تحديثاً منذ سنوات، أو الفروع التي تشير إلى مستودع شخصي. كل واحدة منها مشروع ورثته دون أن تدري.
- الأسرار في المستودع. تفقد التاريخ كاملاً، وليس الشجرة الحالية فقط. افترض أن أي شيء يُعثر عليه قد تم اختراقه.
- كيفية حماية البيانات. أين توجد البيانات الشخصية، من يمكنه قراءتها، ما هو مشفر، وما هي التزاماتك تجاهها.
- ما إذا كان النشر قابلاً للتكرار. النظام الذي ينشر عبر تعديل الملفات على الخادم لا يملك استرجاعاً موثوقاً، وهذا يؤثر على كل تقييم للمخاطر بعد ذلك.
اكتب النتائج كمخاطر مع احتمال، وتأثير، وتكلفة إصلاح — لا تكتبها كشكاوى من الفريق السابق. الجمهور لهذا المستند تجاري، وهذا الكود سيء ليس قابلاً للتنفيذ بينما نحن على بعد 14 شهراً من عدم وجود تصحيحات قابل للتنفيذ.
الأسبوع 3: اقرأ الشيفرة الآن
مع تأسيس السياق، يصبح تقييم الكود مفيداً بدلاً من كونه حكماً. ابحث عن الهيكلية وقابلية الاختبار بدلاً من الأسلوب.
- قم بتشغيل تحليل ثابت على مستوى منخفض وسجل الخط الأساسي. أنت لا تصلحه؛ أنت تقيسه. الاتجاه خلال العام القادم هو المهم.
- تحقق من تغطية الاختبارات حيثما يهم — الخروج، الدفع، التسعير، أي شيء يتعلق بالمال. النسبة الإجمالية مقياس ضعيف؛ تغطية المسارات الخطرة هي المقياس الحقيقي.
- ابحث عن منطق الأعمال. في قاعدة كود صحية يكون في أماكن محددة. في قاعدة غير صحية يكون منتشرًا عبر المتحكمات، والقوالب، وإجراء مخزن لا يعرفه أحد.
- ابحث عن الكائنات الإلهية — الفئة التي تتعامل معها كل ميزة. ستخبرك أين يكون التغيير أكثر تكلفة ومن أين سيأتي الحادث التالي.
- اقرأ تاريخ git للاضطراب. الملفات التي تتغير أكثر هي حيث تعمل الأعمال فعلياً، وحيث يعود الاستثمار بأسرع وقت.
- حدد ما لا يمكن المساس به. كل نظام قديم لديه وحدة لا يجرؤ أحد على تعديلها. اكتشف ما هي ولماذا.
عامل الحافلة يستحق ملاحظة خاصة. إذا كان شخص واحد فقط يمكنه شرح خط أنابيب الطلبات ولا أحد غيره يستطيع، فهذه مخاطرة أعلى من أي رائحة كود ستجدها، والتخفيف — التزاوج، التوثيق، شخص ثانٍ يعرفه حقاً — يجب أن يبدأ فوراً وليس بعد التقييم.
الأسبوع 4: قيّمها وقدّم توصيات
قم بتقييم كل بُعد من 1 (صحي) إلى 5 (حرج)، ودع المجموع يوجه التوصية بدلاً من حدسك.
- الأمان وحداثة الإصدار — البُعد الوحيد الذي يمكنه فرض قرار بمفرده
- صحة التبعيات — مدى التخلف، وكم منها مهجور
- قابلية التشغيل — هل يمكنك النشر، الاسترجاع، المراقبة والاستعادة؟
- قابلية الاختبار — هل يمكنك تغيير منطق التسعير ومعرفة ما إذا كنت قد أفسدته؟
- سهولة الفهم — كم من الوقت حتى يصبح المهندس الجديد منتجاً؟
- ملاءمة الأعمال — هل لا يزال يلبي احتياجات العمل، أم أنه يقاوم خارطة الطريق؟
ثم ضع التقييم:
- غالباً 1–2: الصيانة والتحسين. النظام جيد. أصلح النتائج المحددة واستمر في خارطة الطريق.
- غالباً 2–3: استثمر بشكل مدروس. برنامج تصحيح ممول — ترقية الإصدار، حوكمة التبعيات، اختبارات على مسارات المال — جنباً إلى جنب مع التسليم العادي.
- غالباً 3–4: الاستبدال التدريجي. نمط strangler fig، استبدال النظام جزءاً جزءاً أثناء استمراره في العمل. نصف هذا النمط بالتفصيل في ترحيل مونوليث PHP القديم إلى Laravel.
- غالباً 4–5، أو ملاءمة الأعمال 5: إعادة البناء. نادرة، ويجب أن تبدو حتمية أكثر من كونها جذابة. إعادة البناء المبررة بجودة الكود فقط عادة ما تكون إعادة بناء يُندم عليها.
كن مشككاً في حدسك الخاص لإعادة البناء. تقريباً كل مهندس يرث قاعدة كود غير مألوفة يرغب في ذلك. نادراً ما تسلم المشاريع الناتجة ما وُعِد به في الوقت المحدد. اشترط أن يبرر التقييم ذلك.
ما الذي يجب تسليمه
الناتج هو مستند واحد، يمكن لشخص غير تقني قراءته، يحتوي على:
- ملخص من صفحة واحدة مع التوصية وثلاثة أسباب داعمة لها
- سجل المخاطر — كل نتيجة مع احتمال، وتأثير، وتكلفة إصلاح، مرتبة حسب الأولوية
- موقف الإصدار والتبعيات، مع تواريخ انتهاء الدعم
- خطة 90 يوماً للأمور التي لا يجب تأجيلها، مع التكلفة المقدرة
- فجوات الوصول والملكية، التي تكون عادة تجارية أكثر منها تقنية
- تصريح صادق بما لم تتمكن من تقييمه وما يتطلبه الأمر لاكتشافه
العنصر الأخير هو ما يميز التقييم المهني عن التقييم الواثق. شهر واحد غير كافٍ لمعرفة كل شيء، والاعتراف بذلك أكثر مصداقية من التظاهر بالعكس.
نُجري هذا التقييم للعملاء من خلال ممارستنا المخصصة في PHP وفريق تطوير PHP الخاص بنا — غالبًا قبل إتمام الاستحواذ، وأحيانًا بعد انتهاء علاقة مع وكالة بشكل سيء. السؤال المتعلق بما إذا كانت اللغة نفسها هي المشكلة مغطى في هل لا يزال PHP الخيار الصحيح للتجارة الإلكترونية.
الأسئلة الشائعة
كم من الوقت يجب أن يستغرق تقييم الكود القديم؟
أربعة أسابيع من جهد بدوام جزئي تكفي لإخراج توصية يمكن الدفاع عنها لمعظم الأنظمة متوسطة الحجم. أقل من أسبوعين ينتج رأيًا بدلًا من تقييم؛ أكثر من ستة أسابيع عادةً يعني أن أحدهم يحاول إصلاح الأمور بدلًا من قياسها.
ما هو أول شيء يجب فحصه؟
ما إذا كان يمكنك تشغيله محلياً من نسخة نظيفة من المستودع، وكم يستغرق ذلك. هذا الرقم الواحد يتنبأ بتكلفة كل تغيير مستقبلي أفضل من أي مقياس لجودة الشيفرة، وهو متاح منذ اليوم الأول.
هل نعيد بناء نظام PHP موروث أم نعيد هيكلته؟
في معظم الحالات، أعد هيكلته أو استبدله تدريجياً. أعد البناء فقط عندما يفشل الملاءمة مع العمل فعلاً — أي عندما يتوقف النظام عن أداء ما يحتاجه العمل — وليس لأن الشيفرة غير ممتعة. غالباً ما يندم الفرق على إعادة بناء مبررة بجودة الشيفرة وحدها.
ما أكبر خطر في قاعدة شيفرة موروثة؟
عادةً ليس الشيفرة نفسها. الخطر يكون في نسخة PHP غير مدعومة، أو عدم وجود وصول إلى نطاق أو حساب سحابي، أو نسخ احتياطية غير مُختبرة، أو وجود شخص واحد فقط يفهم نظاماً فرعياً حرجاً. هذه هي النتائج التي تغيّر القرارات.
كيف نعرض النتائج لأصحاب المصلحة غير التقنيين؟
كـ «سجل مخاطر»: كل نتيجة مع احتمالية الحدوث، وتأثيرها على العمل، وتكلفة الإصلاح، مرتبة حسب درجة الإلحاح. لا تعرضها أبداً كنوع من نقد الفريق السابق — ذلك يُقرأ كمحاولة للتموضع ويُسهّل رفض الوثيقة بأكملها.
اطلب رأياً ثانياً
إذا ورثت شيئًا وتحتاج إلى تقييم مستقل قبل تخصيص ميزانية له، سنجري التقييم ونقدم لك الوثيقة. تواصل مع فريقنا؛ نرد خلال يوم عمل.