تكرار الكود أرخص من التجريدات الخاطئة
يعشق المطورون مبدأ DRY.
أنت تريد تجنب تكرار نفسك. تريد كوداً أنيقاً وقابلاً لإعادة الاستخدام.
لكن هذا الهدف غالباً ما يؤدي إلى فخ: التجريد المبكر (premature abstraction).
تكرار الكود يبدو أمراً خاطئاً. ومع ذلك، فإن التكرار غالباً ما يكون أرخص من التجريد السيئ.
نحن نحاول بناء أنظمة برمجية نموذجية (modular) مثالية. نبحث عن الأنماط ونستخلص المنطق لإدارة التعقيد.
التجريدات المصممة جيداً تساعد البرمجيات على التوسع (scale).
لكن العديد من التجريدات تُبنى في وقت مبكر جداً. إذا لم تفهم المشكلة تماماً، فسيصبح التجريد الخاص بك عبئاً.
التجريد الخاطئ يسبب عدة مشكلات:
- الإفراط في الهندسة (Over-engineering): بناء حلول معقدة لمشكلات بسيطة.
- الصلابة (Rigidity): يصبح الكود الخاص بك صعب التغيير لأنه يحاول التنبؤ بمستقبل لن يحدث أبداً.
- غموض الغرض (Obscured Intent): يختبئ منطق العمل (Business logic) تحت طبقات من الواجهات العامة (generic interfaces)، مما يجعل عملية تصحيح الأخطاء (debugging) صعبة.
- الاقتران الوثيق (Tight Coupling): تصبح أجزاء من نظامك مرتبطة ارتباطاً وثيقاً بالتجريد نفسه.
التكلفة عالية. ستقضي وقتك في محاربة بنيتك البرمجية الخاصة بدلاً من حل مشكلات المستخدمين. هذا يبطئ فريقك ويجعل عملية إعادة هيكلة الكود (refactoring) صعبة.
أنا لا أقول لك أن تقوم بنسخ ولصق كل شيء. أنا أقترح نهجاً براغماتياً.
استخدم التكرار المدروس كأداة. استخدمه في المجالات التي تتغير فيها المتطلبات بسرعة أو حيث تواجه حالة من عدم اليقين.
انتظر حتى ترى النمط بوضوح قبل أن تبني التجريد.