هل الكود الحالي قابل للتطوير؟ مؤشرات يقرؤها المهندس في ساعات
فريق يقول إن الكود متعب ويقترح إعادة البناء، وآخر يقول إنه مقبول. هذه المقالة لصاحب المشروع ومدير التقنية: ما الذي يقيسه المهندس في ساعات، وكيف تقرأ تقريره وتحوله إلى قرار لكل جزء من النظام.
تقييم قابلية الكود للتطوير لا يحتاج أسابيع ليجيب عن السؤال الأول: هل نبني عليه أم هو عبء؟ مهندس متمرس يستطيع في ساعات من المراجعة المحددة أن يقيس ستة مؤشرات: البنية والتقسيم، والاختبارات، وحداثة المكتبات ودعم الإطار، والتكرار، والأمان الأساسي، وسهولة التشغيل المحلي. ويضيف إليها تجربتين تكشفان ما لا تكشفه الأدوات: تعديل صغير يُنفذ فعلًا ليُرى كم ملفًا يمس، وقراءة تاريخ المستودع لمعرفة أين يتركز الألم. النتيجة لا تكون «جيد» أو «سيئ»، بل مسار لكل جزء: استمرار التطوير، أو إعادة هيكلة، أو استبدال تدريجي، أو إعادة بناء.
لديك تطبيق يعمل، وفريق جديد أو ميزة كبيرة على الطريق. أحدهم يقول إن الكود «متعب» ويقترح إعادة البناء، وآخر يقول إنه «مقبول». كلاهما انطباع. ما تحتاجه قبل أن تلتزم بميزانية هو أدلة يمكن تكرارها: ما الذي قيس، وكيف، وما الذي يعنيه لعملك. هذه المقالة تشرح ما يقرؤه المهندس في مراجعة قصيرة محددة الوقت، وكيف تقرأ أنت تقريره وتحوله إلى قرار.
ما الذي تقيسه مراجعة الساعات، وما الذي لا تقيسه؟
المراجعة القصيرة ليست تدقيقًا شاملًا. هدفها فرز أولي: هل الكود في حالة تسمح بالبناء عليه بتكلفة معقولة؟ وأين الأجزاء التي تحتاج إلى معالجة قبل أي ميزة؟ تُنفذ بصلاحية قراءة على المستودع والبيئات، وتتبع ترتيبًا ثابتًا حتى تكون نتائجها قابلة للمقارنة بين مشروع وآخر.
- التشغيل المحليمن الاستنساخ إلى تطبيق يعملالمهندس
- القراءة البنيويةالتقسيم والطبقات وأين يعيش المنطقالمهندس
- الأدواتالاختبارات والتحليل والمكتبات والأسرارآلي
- تجربة التغييرتعديل صغير حقيقي من الواجهة إلى القاعدةالمهندس
- التقدير والمسارمستوى كل مؤشر والمسار لكل جزءالمهندس وصاحب القرار
ما لا تقيسه مراجعة الساعات: صحة منطق الأعمال في كل الحالات الاستثنائية، وأداء النظام تحت حمل حقيقي، والأمن بعمق اختبار الاختراق، وسلامة البيانات التاريخية. هذه تحتاج إلى مراجعة كود وتدقيق معمارية أوسع، أو اختبارات متخصصة. المراجعة القصيرة تخبرك هل تحتاج إليها، وأين تركز.
ستة مؤشرات لتقييم قابلية الكود للتطوير وما يعنيه كل مستوى
لكل مؤشر ثلاثة مستويات. «سليم» يعني أن التطوير يستمر دون عمل تمهيدي. «يحتاج معالجة» يعني عملًا محددًا قبل الميزات الكبيرة أو معها. «عبء» يعني أن هذا الجانب سيرفع تكلفة كل تعديل حتى يُعالج جذريًا.
| المؤشر | سليم | يحتاج معالجة | عبء |
|---|---|---|---|
| التشغيل المحلي | يعمل باتباع التوثيق في ساعات | يعمل بعد أسئلة وخطوات غير مكتوبة | لا يعمل دون المطور السابق أو نسخة من خادمه |
| البنية والتقسيم | طبقات واضحة، ومنطق العمل في مكان واحد | تقسيم موجود لكن يُخرق في أجزاء | منطق العمل داخل الشاشات، وكل جزء يعرف كل جزء |
| الاختبارات | تغطي المسارات الحرجة وتعمل في خط البناء | قليلة أو لشاشات غير حرجة | لا توجد، أو معطلة منذ مدة |
| المكتبات ودعم الإطار | الإطار في فترة دعم، والمكتبات قريبة من الحالية | تأخر يمكن سده بترقيات متدرجة | إطار أو لغة خارج دعم الأمان، أو مكتبات مهجورة في مسارات حرجة |
| التكرار | قواعد العمل مكتوبة مرة واحدة | تكرار موضعي في شاشات متشابهة | القاعدة نفسها بصيغ مختلفة في التطبيق والخادم واللوحة |
| الأمان الأساسي | لا أسرار في الكود، والصلاحيات تُفحص في الخادم | ملاحظات محدودة قابلة للإصلاح المباشر | أسرار في التاريخ، أو صلاحيات تعتمد على الواجهة وحدها |
التشغيل المحلي: أول مؤشر وأصدقها
المهندس يستنسخ المستودع على جهاز نظيف ويحاول التشغيل باتباع ما هو مكتوب فقط. كل خطوة غير مكتوبة تُسجل. هذا المؤشر يقيس ثلاثة أشياء معًا: التوثيق، وفصل الإعدادات عن الكود، واعتماد المشروع على شخص. وإن لم يعمل المشروع محليًا، فكل تقدير لاحق لأي ميزة سيحمل احتياطًا كبيرًا.
البنية والتقسيم: أين يعيش منطق العمل؟
السؤال العملي: لو تغيرت طريقة حساب الخصم، في كم مكان يجب أن نعدل؟ في البنية السليمة يكون الجواب مكانًا واحدًا في الخادم. في البنية المتشابكة يكون الجواب «في الشاشة، وفي الخادم، وفي تقرير اللوحة»، وكل منها بصيغة مختلفة قليلًا. هذا ما يجعل الأعطال تظهر في أماكن لم يُعدل فيها شيء.
المكتبات ودعم الإطار: التاريخ مهم لا الرقم فقط
لكل لغة وإطار جدول دعم منشور، ويقارن المهندس إصدار المشروع به. مثلًا، تعلن صفحة إصدارات PHP المدعومة أن دعم الأمان لإصدار 8.2 ينتهي في 31 ديسمبر 2026، وتنص سياسة دعم Laravel على إصلاح الأخطاء لثمانية عشر شهرًا وإصلاحات الأمان لسنتين لكل إصدار رئيسي. خادم على إصدار خرج من دعم الأمان ليس سببًا لإعادة البناء بذاته، لكنه يضع ترقية إلزامية في أول الخطة. وفي تطبيقات Flutter، يبين أمر dart pub outdated مقدار تأخر كل مكتبة عن أحدث إصداراتها.
التكرار والأمان الأساسي
أدوات تحليل الجودة تقيس نسب التكرار وتعقيد الدوال، وأدوات فحص الأسرار والمكتبات تكشف المفاتيح المكتوبة والثغرات المعروفة. المهندس لا يكتفي بالأرقام؛ يسأل أين يقع التكرار والتعقيد. التعقيد في شاشة إعدادات نادرة الاستخدام لا يساوي التعقيد في منطق الأسعار أو الدفع.
تجربتان تكشفان ما لا تكشفه الأدوات
الأدوات تصف حالة الكود ساكنًا. لكن ما يهمك هو تكلفة تغييره. تجربتان تقيسان ذلك مباشرة.
تجربة التغيير الصغير
يختار المهندس تعديلًا تمثيليًا صغيرًا، مثل إضافة حقل جديد إلى نموذج الطلب يظهر في التطبيق ويُحفظ في القاعدة ويظهر في لوحة التحكم، وينفذه فعلًا في فرع تجريبي. ثم يسجل: كم ملفًا لمس؟ كم طبقة؟ هل كسر اختبارًا أو شاشة أخرى؟ هل احتاج إلى تعديل يدوي في قاعدة البيانات لأن ملفات الترحيل غير موجودة؟ تعديل يمس عددًا قليلًا من الملفات المتوقعة يعني كودًا يتقبل التغيير. تعديل يمتد إلى ملفات لا علاقة ظاهرة لها بالحقل يعني أن كل ميزة ستكلف أكثر مما تبدو.
قراءة تاريخ المستودع: أين يتركز الألم؟
سجل التعديلات يحكي ما لا يحكيه الكود. الملفات الأكثر تعديلًا، إذا كانت أيضًا الأعقد والأطول، هي نقاط الاحتكاك: هناك تتركز الأعطال وهناك يتباطأ الفريق. ورسائل التعديلات المتكررة من نوع «إصلاح» على الملف نفسه علامة على جزء لم يستقر يومًا. هذه القراءة تحدد أي الأجزاء تستحق المعالجة أولًا، بدل معالجة الكود كله بالتساوي.
إن كنت صاحب المشروع ولست مبرمجًا، فبعض هذه المؤشرات تستطيع أن تطلب دليلها بنفسك قبل الاستلام، كما في فحص الكود المصدري قبل الاستلام لغير المبرمج. المراجعة الهندسية هنا تذهب أعمق: تقرأ البنية وتنفذ التغيير وتفسر النتائج.
من المؤشرات إلى القرار: أي مسار لأي جزء؟
النتيجة ليست قرارًا واحدًا للنظام كله. في أغلب المشاريع يكون الحكم مختلفًا بين تطبيق الجوال والخادم ولوحة التحكم، بل بين وحدات الخادم نفسه. وتسمي صفحة إعادة تطوير التطبيقات أربعة مسارات: إعادة الهيكلة، ونقل المنصة، وإعادة الهندسة، وإعادة البناء، وكثيرًا ما يجمع المشروع أكثر من مسار لأجزاء مختلفة. هذا الجدول يربط نمط المؤشرات بالمسار الأقرب:
| نمط النتائج في الجزء | المسار المرجح | ما يحدث عمليًا |
|---|---|---|
| أغلب المؤشرات سليمة، وملاحظات متفرقة | استمرار التطوير | الميزات تبدأ، والملاحظات تُعالج ضمنها |
| البنية مقبولة، والاختبارات والتكرار «يحتاج معالجة» | إعادة هيكلة تدريجية | اختبارات حول المسارات الحرجة، ثم توحيد المنطق المكرر عند لمسه |
| المنطق سليم، والإطار أو اللغة أو الاستضافة خارج الدعم | ترقية أو نقل منصة | مشروع ترقية مستقل قبل الميزات الكبيرة، دون تغيير المنطق |
| جزء محدد «عبء» في البنية وتجربة التغيير، والباقي مقبول | استبدال تدريجي لذلك الجزء | بناء الجزء الجديد بجانب القديم ونقل الوظائف إليه واحدة بعد الأخرى |
| «عبء» في أغلب المؤشرات، مع إطار خارج الدعم ومتطلبات تغيرت جذريًا | إعادة بناء | بعد توثيق قواعد العمل المدفونة في الكود القديم، وخطة انتقال للبيانات والمستخدمين |
إعادة البناء في آخر الجدول عن قصد. كما تشرح صفحة إعادة البناء أم تطوير الحالي، إعادة البناء تعني دفع ثمن ما بُني مرة ثانية وإعادة اكتشاف قواعد عمل مدفونة، ولذلك لا نوصي بها إلا إذا أثبت التقييم أنها الخيار الأقل تكلفة ومخاطرة، مع الأسباب مكتوبة.
مثال افتراضي للتوضيح سلسلة مقاهٍ لديها تطبيق ولاء بـ Flutter وخادم بـ Laravel ولوحة تحكم. نتيجة المراجعة: التطبيق يعمل محليًا باتباع التوثيق، وبنيته مقسمة، ومكتباته متأخرة قليلًا، أي «سليم» في أغلب مؤشراته. الخادم يعمل بعد خطوتين غير مكتوبتين، وإصداره من Laravel خرج من دعم الأمان، ووحدة احتساب النقاط مكررة بين الخادم واللوحة بصيغتين. تجربة إضافة نوع مكافأة جديد لمست ملفات في الخادم واللوحة وتطلبت تعديلًا يدويًا في القاعدة. القرار: استمرار تطوير التطبيق، وترقية الخادم إلى إصدار مدعوم، واستبدال تدريجي لوحدة النقاط بوحدة واحدة في الخادم تقرأ منها اللوحة، بدل إعادة بناء النظام كله كما اقتُرح في البداية.
متى لا تكفي مراجعة الساعات؟
المراجعة القصيرة تعطيك اتجاهًا موثوقًا، لكنها لا تكفي وحدها في هذه الحالات:
- القرار المطروح إعادة بناء أو استثمار كبير؛ هنا يحتاج كل مسار إلى تقدير تكلفة ومخاطر مكتوب.
- النظام يتعامل مع مدفوعات أو بيانات صحية أو مالية؛ الأمان يحتاج إلى مراجعة أعمق من الفحص الأساسي.
- الأعطال في الأداء تحت الحمل أو في سلامة البيانات؛ هذه لا تظهر في قراءة الكود وحدها.
- النتائج متضاربة: مؤشرات سليمة، وتجربة تغيير سيئة، أو العكس.
- لا توجد وثائق أصلًا وقواعد العمل غير معروفة؛ هنا تبدأ بإعادة بناء المعرفة كما في تطبيق بدون توثيق.
في هذه الحالات تمتد المراجعة إلى تقرير كامل: ملاحظات مرتبة حسب الخطورة لكل منها موقعها في الكود ودليلها، وملخص تنفيذي لصاحب القرار، وتقدير تقريبي لمعالجة كل مجموعة، وتوصية بالمسار. والفحص يجمع الأدوات الآلية والمراجعة اليدوية، بصلاحيات قراءة فقط واتفاقية سرية قبل الاطلاع على الكود.
أخطاء شائعة في تقييم الكود الحالي
- الحكم بالانطباع: «الكود سيئ» من فريق جديد دون أرقام أو تجربة تغيير. كل فريق يرى في كود غيره عيوبًا، والبناء من الصفر أسهل للفريق لا بالضرورة لك.
- حكم واحد للنظام كله: فيُعاد بناء أجزاء سليمة مع الجزء المتعب، أو يُترك الجزء المتعب لأن الباقي جيد.
- الاكتفاء بتقارير الأدوات: نسبة تغطية أو تكرار دون سؤال «أين؟» و«ما أثره على التعديل؟».
- الخلط بين قديم وغير قابل للصيانة: إطار قديم مع منطق نظيف حالة ترقية، لا إعادة بناء.
- تجاهل تاريخ المستودع: وهو أرخص مصدر لمعرفة أين تتركز الأعطال والبطء.
- تقييم بلا معايير مكتوبة: فلا يمكن مقارنة تقرير اليوم بتقرير بعد ستة أشهر لمعرفة هل تحسن الكود.
ما تجهزه قبل التواصل وما تطلبه من المزود الذي يراجع الكود
ما تجهزه
- صلاحية قراءة على كل المستودعات: التطبيق والخادم واللوحة وأي خدمة مساعدة.
- وصول للقراءة إلى بيئة الاختبار، أو نسخة من قاعدة بيانات منقحة من البيانات الشخصية.
- القرار الذي تريد أن تتخذه: ميزة كبيرة، أو تغيير فريق، أو استثمار، أو إعادة بناء مقترحة.
- أكثر الشكاوى تكرارًا من فريقك ومستخدميك: ما يتعطل، وما يتأخر.
- خطط العمل للسنة القادمة، لأن الكود يُقيّم مقابل ما سيُطلب منه.
ما تطلبه من المزود
- مستوى كل مؤشر من الستة، مع الدليل: أمر شُغل، أو ملف، أو لقطة.
- نتيجة تجربة التغيير: ما التعديل، وما الملفات التي لمسها، وما الذي كسره.
- نقاط الاحتكاك من تاريخ المستودع، مرتبة.
- المسار المقترح لكل جزء، وسببه، وما البديل الذي استُبعد ولماذا.
- ملخص في صفحة لصاحب القرار، وتفاصيل للفريق التقني.
- أن يكون التقرير ملكك ويمكن مشاركته مع أي فريق.
الخلاصة: قِس، وجرّب التغيير، ثم قرر لكل جزء
الكود الحالي ليس «صالحًا» أو «عبئًا» ككتلة واحدة. ستة مؤشرات قابلة للقياس وتجربتان عمليتان تكفي لتفرز أجزاءه: ما يُبنى عليه مباشرة، وما يحتاج إلى إعادة هيكلة أو ترقية، وما يستحق استبدالًا تدريجيًا، ونادرًا ما يستحق إعادة بناء. اطلب الدليل مع كل حكم، والمسار مع كل جزء. وإن كان أمامك قرار تطوير أو إعادة بناء، اطلب مراجعة المشروع لتبدأ من أدلة لا من انطباعات.
أسئلة شائعة
الفرز الأولي بالمؤشرات الستة وتجربة التغيير يُنجز في مراجعة قصيرة محددة الوقت لمشروع متوسط. أما التقرير الكامل بالملاحظات والتقديرات لكل مسار، فيعتمد على حجم الكود وعدد مكوناته وعمق المراجعة المطلوب، ويُحدد في النطاق قبل البدء.
اطلب الدليل: مستوى كل مؤشر، ونتيجة تجربة تغيير فعلية، والأجزاء التي يقصدها تحديدًا. البناء من الصفر أسهل لأي فريق من فهم كود غيره، لكنه ليس دائمًا الأوفر لك. إن كان الحكم عامًا بلا أدلة، فاطلب رأيًا مستقلًا.
لا. إطار أو لغة خارج فترة الدعم مع منطق عمل نظيف ومقسم حالة ترقية أو نقل منصة، لا إعادة بناء. يصبح القدم مشكلة بنيوية حين تكون الترقية مستحيلة دون إعادة كتابة أجزاء كبيرة، أو حين تعتمد المسارات الحرجة على مكتبات مهجورة بلا بديل.
نعم، وهذا الشائع. قد يكون تطبيق الجوال سليمًا والخادم عبئًا، أو تكون وحدة واحدة في الخادم هي المشكلة. لذلك يُقيّم كل جزء على حدة ويُحدد له مساره، بدل حكم واحد يدفعك إلى إعادة بناء ما لا يحتاج.
لا تكشف صحة منطق الأعمال في كل الحالات الاستثنائية، ولا الأداء تحت حمل حقيقي، ولا الثغرات التي تحتاج اختبار اختراق، ولا سلامة البيانات التاريخية. تخبرك هل تحتاج إلى هذه الفحوص الأعمق وأين تركزها.
خدمات وصفحات مرتبطة
اقرأ أيضًا
قبل قرار البناء أو إعادة البناء: قيّم الكود بأدلة
أرسل وصف نظامك والقرار الذي أمامك، ونراجع الكود والمعمارية بتقرير يحدد حالة كل جزء ومساره المقترح وأسبابه بلغة يفهمها صاحب القرار.