فلسفة الكود
ضد الطبقات الزائدة
١٢ أكتوبر ٢٠٢٦ · 5 دقائق قراءة
الطبقة كأنها وعد
فكرة الطبقات أصيلة: اعزل الـ HTTP عن العمل، والعمل عن التخزين. لكن المشكلة مش في الطبقات اللي بتخدم حاجة حقيقية، المشكلة في طبقة سُمّيت باسم حاجة مفيش وراها إلا سطر بس:
class OrderService:
def place(self, data): # بيمرر للريبو فقط
return self.repo.create(
data
)
دي مش طبقة، دي جسر فراغ — بتضيف اسمًا وواجهة على مكالمة واحدة من غير أي قرار. وقارئ الكود دلوقتي محتاج يدور ثلاث مستويات عشان يوصل لأمر بسيط.
الإشارة الأكيدة لطبقة زائدة
مش في عددها، في نسبة العمل الحقيقي اللي كل طبقة بتقدّمه. اطرح على نفسك السؤال: «لو شلت الطبقة دي ووصّلت اللي قبلها باللي بعدها مباشرة، خسرت إيه؟»
- لو الإجابة «اسم أو تنظيم» — الطبقة زائدة.
- لو الإجابة «فصل حقيقي للنقل عن المنطق، أو إمكانية تبادل، أو نقطة واحدة لتغيير السياسة فعلًا» — استبقِها وحافظ على مكانها.
اللي حصل عندي
في مشروع جمع بيانات ودخل «كل شيء» فيه سبع طبقات: handler بيدي للفانكشن، و service بيدي للـ repo، والعكس. واشتغلنا على خطأ عشوائي أول ما ظهر، ولما حد سأل «السطر ده راح لمين؟» أخذنا أسبوعين نجرّي ورا الوهم — مش لأن الكود غامض، لكن لأن كل طبقة كانت واجهة ممكنة لتغيير السلوك.
متى الطبقات تكون فعلًا ضرورية
الطبقة بتستاهل اسمها لما يكون عليها قرار منطقي بيغيّر السلوك:
- تعرّف عقدًا ثابتًا بين وحدتين بتتغيرا بسرعات مختلفة (النقل مقابل العمل).
- نقطة واحدة تفرض سياسة (مثلاً: كل استعلام للتخزين يمرّ بخطة كاش واحدة).
- تسمح بتبادل التطبيق (مثلاً: swap لتنفيذ تبعية أغراض الاختبار).
دي حاجات بتتبان فجأة، مش بتتزيّن واحدة واحدة. القاعدة عندي بقت: لو مبحتش الطبقة فعلًا، متعملهاش. وأي طبقة من غير قرارها مبقتش طبقة، بقت مجرد مكان يضيع فيه سطر.