التكلفة الخفية للإفراط في الهندسة: عندما يذهب الكود النظيف بعيداً جداً

على الأرجح لا تحتاج إلى هذا التجريد

ينضم مطور إلى مشروع جديد. يفتح الكود ويجد: AbstractBaseRepositoryInterface، و RepositoryFactory، و RepositoryFactoryFactory، وثلاث طبقات من الـ middleware، ونظام أحداث مخصص يغلّف نظام الأحداث المدمج في Laravel، ومحرك تحقق مدفوع بالإعدادات استغرق بناؤه شهرين ويتحقق من نموذج واحد فقط.

كل جزء كتبه مطور ذكي يحل مشكلة قد يواجهها يومًا ما.

هذا هو الإفراط في الهندسة، وهو أحد أكثر المشاكل تكلفة في تطوير البرمجيات — ليس بسبب تكلفة البناء الأولية، بل بسبب عبء الصيانة المستمر الذي يخلقه.

أمثلة واقعية على الإفراط في الهندسة

1. نمط Repository مع Eloquent

هذا هو المثال الأكثر شيوعًا في عالم Laravel:

// The "enterprise" approach
interface UserRepositoryInterface
{
    public function findById(int $id): ?User;
    public function findByEmail(string $email): ?User;
    public function create(array $data): User;
    public function update(int $id, array $data): User;
    public function delete(int $id): bool;
    public function paginate(int $perPage): LengthAwarePaginator;
}

class EloquentUserRepository implements UserRepositoryInterface
{
    public function findById(int $id): ?User
    {
        return User::find($id);  // That's it. That's the whole method.
    }

    public function findByEmail(string $email): ?User
    {
        return User::where('email', $email)->first();
    }

    // ... 50 more one-liner wrapper methods
}

// versus: just use Eloquent directly
$user = User::find($id);
$user = User::where('email', $email)->first();

المبرر: "ماذا لو احتجنا إلى التبديل من Eloquent إلى ORM آخر؟"

الواقع: لن تفعل ذلك. وحتى لو فعلت، فإن واجهة الـ repository لن تنقذك لأن أنماط استعلام Eloquent مختلفة جذريًا عن SQL الخام أو Doctrine. ستعيد كتابة كل شيء على أي حال.

2. خدمات عامة لمشاكل محددة

// Over-engineered: a configurable notification pipeline
class NotificationPipeline
{
    private array $channels = [];
    private array $filters = [];
    private array $transformers = [];
    private ?RetryStrategy $retryStrategy = null;
    private ?RateLimiter $rateLimiter = null;

    public function addChannel(NotificationChannel $channel): self { /* ... */ }
    public function addFilter(NotificationFilter $filter): self { /* ... */ }
    public function addTransformer(MessageTransformer $transformer): self { /* ... */ }
    public function setRetryStrategy(RetryStrategy $strategy): self { /* ... */ }
    public function setRateLimiter(RateLimiter $limiter): self { /* ... */ }
    public function dispatch(Notification $notification): NotificationResult { /* ... */ }
}

// What the app actually needs:
Mail::to($user)->send(new OrderConfirmation($order));

3. الخدمات المصغرة المبكرة

التطبيق المتجانس (monolith) يعالج 100 طلب في الدقيقة. يقرر الفريق تقسيمه إلى 12 خدمة مصغرة "من أجل قابلية التوسع". الآن يحتاجون إلى: اكتشاف الخدمات، وبوابات API، وتتبع موزع، وقوائم انتظار للرسائل بين الخدمات، ومعالجة الاتساق النهائي، ومجموعة Kubernetes.

التطبيق لا يزال يعالج 100 طلب في الدقيقة.

علامات تدل على أنك تفرط في الهندسة

تكتب كودًا لمتطلبات مستقبلية افتراضية — "قد نحتاج هذا يومًا ما"
تجريدك لديه تطبيق واحد فقط — واجهة بفئة واحدة خلفها هي مجرد ضريبة واجهات
أعضاء الفريق الجدد يحتاجون "جولة تعريفية بالمعمارية" قبل أن يتمكنوا من إضافة ميزة بسيطة
إضافة ميزة تتطلب تعديل 8 ملفات أو أكثر عندما يكون المنطق بسيطًا
تقضي وقتًا في البنية التحتية أكثر من الميزة نفسها
إعادة الهيكلة وفق مبدأ DRY ربطت أشياء غير مرتبطة — شيئان يبدوان متشابهين اليوم قد يتباعدان غدًا

قاعدة الثلاثة

إرشاد مفيد للتجريد:

المرة الأولى: فقط اكتب الكود
المرة الثانية: لاحظ التكرار، لكن قاوم رغبة التجريد. النسخ واللصق مقبول.
المرة الثالثة: الآن لديك ثلاثة أمثلة ملموسة. يمكنك رؤية النمط الحقيقي وإنشاء تجريد ذي معنى.

// First and second time: just write the validation
$request->validate(['email' => 'required|email|unique:users']);
$request->validate(['email' => 'required|email|unique:admins']);

// Third time: NOW extract it (if the pattern is genuinely the same)
// But honestly, this is Laravel — the above is already clean enough.

متى يكون التعقيد مبررًا

ليس كل كود معقد يعني إفراطًا في الهندسة. أحيانًا تحتاج فعلًا إلى التجريد:

بوابات دفع متعددة — نمط الاستراتيجية مبرر مع 3 مزودين أو أكثر
عزل بيانات المستأجرين المتعددين — التعقيد يخدم متطلب أمني حقيقي
الامتثال التنظيمي — سجلات تدقيق HIPAA/GDPR تبرر أنماط Event Sourcing
عنق زجاجة مُثبَت في الأداء — طبقات التخزين المؤقت مبررة عندما تقيس المشكلة فعليًا