يمكن أن يشعر المرء بأن بناء البرمجيات يشبه الأداء أمام الجمهور؛ فالإنترنت يكافئ عمليات الإطلاق، ولقطات الشاشة، ونقاط سجل التغييرات. لذا، عندما يقضي المطور جلسة كاملة في مشروع ما دون أن يكون لديه شيء ملموس ليعرضه، فإن الغريزة تدفعه لاعتبار ذلك اليوم ضائعاً. لكن أحدث سجل تطوير (dev log) لـ "منصة مدونة الطعام" يثبت العكس. لم تكن هناك وصفات جديدة لعرضها، ولا بطاقات مصممة من جديد، ولا أزرار إضافية لينقر عليها المستخدمون. بل كان مجرد كود تم تفكيكه، وفحصه، وإعادة تجميعه بشكل أفضل مما كان عليه.
هذا هو العمل غير المرئي الذي يبقي المشاريع طويلة الأمد حية.
الميزات تنال المجد؛ وإعادة الهيكلة (Refactoring) هي ما يبقي الأنوار مضاءة
عندما تدير منصة مدونة طعام، يبدو المظهر الخارجي بسيطاً؛ ينشر المستخدمون الوصفات، ويرفعون الصور، ويتصفحون حسب الفئة. ولكن في العمق، أنت تتعامل مع مسارات معالجة الصور (image pipelines)، وعلاقات قواعد البيانات بين المكونات والتعليمات، وفهارس البحث، وطبقات التخزين المؤقت (caching layers). ومع مرور الوقت، تتراكم الإصلاحات السريعة؛ دالة مساعدة (helper function) تم نسخها في ثلاثة ملفات مختلفة، أو استعلام قاعدة بيانات كان منطقياً لعشرة منشورات ولكنه أصبح بطيئاً جداً عند الوصول إلى ألف منشور، أو ملف CSS بدأ منظماً حتى حولته خمس رقع برمجية طارئة إلى متاهة.
إعادة الهيكلة (Refactoring) تعني مواجهة هذه الفوضى وجهاً لوجه. قد يعني ذلك دمج المنطق المكرر بحيث يستمد نموذج تحرير الوصفة ولوحة تحكم المسؤول من نفس طبقة التحقق من الصحة (validation layer) بدلاً من صيانة نسخ متوازية. قد يعني تبسيط كيفية معالجة الصور بحيث يعمل روتين الضغط مرة واحدة بدلاً من كل مرة يتم فيها إعادة تحميل الصفحة. أو قد يتضمن إعادة هيكلة قاعدة الكود (codebase) بحيث لا يتطلب إضافة نوع محتوى جديد لاحقاً البحث في ستة أدلة (directories) غير مرتبطة.
لا يظهر أي من هذا في واجهة المستخدم. لن يرى الزائر الذي يدخل الموقع لافتة تقول "تم تحسين الاستعلام" أو "تم فك ارتباط المكونات". لكنه سيشعر بذلك عندما يتم تحميل الموقع بشكل أسرع. سيلاحظ ذلك عندما تظهر ميزة جديدة بعد ثلاثة أيام من طلبها بدلاً من ثلاثة أسابيع. لم يضف المطور قدرات جديدة اليوم، بل مهد الطريق لتتم إضافة القدرات دون صراع مع قاعدة الكود.
الكود النظيف هو استثمار ضد الفشل المستقبلي
كل مشروع يستمر لأكثر من شهر تتراكم فيه العقبات. تبني نموذجاً أولياً سريعاً لاختبار فكرة ما، ثم يبدأ المستخدمون بالظهور فعلياً، ثم تحتاج إلى طبقة مصادقة (authentication layer)، ثم قائمة انتظار للإشراف (moderation queue)، ثم تخطيط للهاتف المحمول. كل إضافة من هذه الإضافات يتم تثبيتها فوق أي هيكل موجود بالفعل. وبدون صيانة منتظمة، تبدأ المعمارية (architecture) في التشبه بمنزل صُممت كل غرفة جديدة فيه من قبل شخص مختلف لم يرَ مخطط الطابق أبداً.
الدين التقني (Technical debt) ليس فشلاً في الانضباط، بل هو نتاج طبيعي للمقايضات التي تُجرى لإطلاق منتج حقيقي. الخطر ليس في أن كودك غير مثالي، بل الخطر يكمن في تركه غير مثالي لفترة طويلة بحيث يؤدي تغيير متغير واحد إلى كسر ثلاث ميزات غير مرتبطة. ستجد نفسك خائفاً من لمس شريط البحث لأنك في المرة الأخيرة التي حاولت فيها، تعطل نظام الوسوم (tag system). قد تؤجل إضافة أداة مخطط الوجبات لأنك تعلم أن مخطط قاعدة البيانات (database schema) قد أصبح عقدة ستستغرق ساعات لفكها.
قضاء يوم في إعادة الهيكلة يشبه سداد ذلك الدين قبل أن تغمرك الفوائد. فهو يمنع المشكلات الصغيرة من التحول إلى مشكلات كبيرة. عندما تضيف "منصة مدونة الطعام" ميزتها الرئيسية التالية في نهاية المطاف، لن يضطر المطور إلى المراوغة حول كود هش. سيكتب المنطق الجديد، ويدمجه في واجهة نظيفة، ويمضي قدماً. هذا هو العائد على الاستثمار.
خطوات صغيرة، تعلم حقيقي
هناك أسطورة حول تطوير البرمجيات تقول إن التقدم يبدو كاختراقات عبقرية وجلسات برمجة ماراثونية تعيد كتابة كل شيء بين عشية وضحاها. سيخبرك معظم المطورين العاملين أن هذا خيال. التقدم الحقيقي يشبه الـ diff من بعد ظهر يوم الثلاثاء حيث أصبحت ثلاث دالات أقصر، وتمت إزالة تبعية (dependency) زائدة واحدة، وتغير اسم متغير مربك ليفهمه القارئ التالي بالفعل.
يلتقط سجل تطوير "منصة مدونة الطعام" هذا الإيقاع تماماً. بناء البرمجيات يتعلق بتحسينات صغيرة ومستمرة. أنت تتعلم من كل تحدٍ. ربما كان التحدي اليوم هو فهم سبب اعتماد وحدة (module) معينة بشكل كبير على وحدة أخرى. ربما كان إدراك أن الاختصار الذي تم اتخاذه قبل أسبوعين بدأ بالفعل يكلف وقتاً أكثر مما وفره. كل commit يجعل المشروع أفضل، حتى عندما يقوم ذلك الـ commit بحذف أكثر مما ينشئ.
يحمي هذا النهج أيضًا دافعيتك. إن عمليات إعادة الكتابة الضخمة مرهقة ومحفوفة بالمخاطر، فهي تتسبب في ظهور أخطاء برمجية جديدة أثناء حل الأخطاء القديمة. أما إعادة الهيكلة التدريجية، فتتم...