الجامعة تقيّمك على ما تعرفه، فيحصل الكود المعقّد على علامة جيّدة. أمّا الزبائن فيقيّمونك على شيء واحد: هل يحلّ المنتج مشكلتهم، وبسرعة؟
من هذه الفجوة يولد التعقيد الزائد. والحلّ أن تبني أبسط شيء يعمل، وأن تضيف التعقيد فقط حين يحتاجه مستخدمون حقيقيون.
أرى نظامَي التقييم عن قرب. أنهيت الماستر في الذكاء الاصطناعي في جوان 2026 وأنا أبني منتجات للمؤسسات في نفس الوقت، والاثنان يكافئان عادات شبه متعاكسة.
ما هو التعقيد الزائد في البرمجة؟
التعقيد الزائد هو بناء برنامج أعقد ممّا تحتاجه المشكلة. أي إضافة طبقات وأدوات وميزات لمستخدمين ومشاكل غير موجودة بعد.
فكّر في امتحان الرياضيات. الأستاذ يمنح العلامات على إظهار كل خطوة، فتحصل الأجوبة الطويلة على علامة جيّدة.
لكنّ الزبون ليس أستاذًا. يريد الجواب فقط، وكل خطوة زائدة وقت ينتظره.
التعقيد الزائد يجعل المنتج أبطأ في البناء، وأصعب في التعديل، وأغلى في التشغيل. والزبون لا يرى شيئًا من ذلك.
لماذا تكافئ الجامعة التعقيد؟
لأنّ مشروع الجامعة له مهمّة مختلفة. يجب أن يثبت أنّك فهمت النظرية.
تصميم قاعدة بيانات مفصّل، وخوارزمية ذكية، وعدّة طبقات في البنية، كلّها تُظهر المعرفة. واللجنة ترى الجهد، فيكسب الجهد علامات.
وهذا ليس خطأ. الأسس التي تتعلّمها في الجامعة حقيقية، وستحتاجها. المشكلة في العادة: أن تحمل فكرة "المعقّد يعني الجيّد" إلى مشروع تجاري لا أحد فيه يقيّم التعقيد.
كيف يبدو التعقيد الزائد في شركة ناشئة؟
نفس الأنماط تتكرّر:
- خدمات مصغّرة لخمسة مستخدمين. تقسيم التطبيق إلى خدمات صغيرة كثيرة قبل تجربة تطبيق واحد بسيط.
- التخزين المؤقّت قبل وجود الزوّار. التخزين المؤقّت يعني الاحتفاظ بنسخ جاهزة من البيانات لتُحمَّل الصفحات أسرع. وهو يحلّ مشكلة سرعة لا تملكها بعد.
- كود لميزات غير موجودة. "أطر عمل" مرنة لاحتياجات مستقبلية لم يؤكّدها أحد.
- أدوات جديدة من مقال الأسبوع الماضي. كل واحدة تضيف شيئًا يجب تعلّمه وتحديثه وإصلاحه.
كل اختيار يبدو ذكيًا وحده. ومجتمعةً، تحوّل منتجًا من شهرين إلى منتج من عشرة أشهر.
هل تستعمل الشركة الناشئة الخدمات المصغّرة أم المونوليث؟
ابدأ بالمونوليث.
المونوليث تطبيق واحد يجمع كل أجزاء منتجك. أمّا الخدمات المصغّرة فتقسّم المنتج إلى تطبيقات صغيرة كثيرة تتواصل عبر الشبكة.
الخدمات المصغّرة تساعد الفرق الكبيرة جدًا. أمّا في الشركة الناشئة فتضاعف العمل: خوادم أكثر، واتصالات أكثر قد تتعطّل، وأماكن أكثر تبحث فيها حين ينكسر شيء.
كتب خبير البرمجيات مارتن فاولر أنّ أغلب قصص النجاح مع الخدمات المصغّرة بدأت بمونوليث كبر أكثر من اللازم ثم قُسّم. وأضاف أنّ الأنظمة التي بُنيت خدماتٍ مصغّرة من البداية انتهت في أغلب الحالات بمشاكل جدّية (فاولر، 2015).
ابنِ تطبيقًا واحدًا نظيفًا أوّلًا. وقسّمه لاحقًا، فقط إذا أجبرك النموّ على ذلك.
ما هو مبدأ YAGNI، وكيف يساعدك؟
YAGNI اختصار لـ "You Aren't Gonna Need It"، أي "لن تحتاجه". هي قاعدة من Extreme Programming، وهو أسلوب عمل تستعمله فرق برمجة كثيرة: لا تبنِ شيئًا الآن لأنّك تظنّ أنّك ستحتاجه لاحقًا (فاولر، 2015).
قبل بناء أيّ شيء، اطرح ثلاثة أسئلة:
- هل يحتاج مستخدم حقيقي هذا اليوم؟ لا "قد يحتاج"، بل اليوم.
- هل يحلّ مشكلة تجارية أو يجلب مالًا؟
- ما الذي يتعطّل إذا أجّلناه؟ إذا كان الجواب "لا شيء"، فأجّله.
إذا فشلت ميزة في الأسئلة الثلاثة، ضعها في قائمة لاحقًا. لن تخسر شيئًا، لأنّك تستطيع دائمًا بناءها حين تصبح الحاجة حقيقية.
مشروع التخرّج مقابل واقع السوق: ما الفرق؟
| مشروع التخرّج | واقع السوق | |
|---|---|---|
| من يقيّمه | لجنة | زبائن يدفعون |
| ما يكسب النقاط | إظهار المعرفة | حلّ المشكلة بسرعة |
| التعقيد | علامة على الجهد | تكلفة يدفعها الزبون |
| المدّة | أشهر من التخطيط | أسابيع حتى النسخة الأولى |
| النجاح | علامة جيّدة | زبائن يعودون |
العمود الأيمن هو الطريقة التي قد تفشل بها دون أن تلاحظ لسنتين، ثم تكتشف أنّ لا أحد أراد ما بنيته.
متى يستحقّ التعقيد العناء؟
البساطة لا تعني الإهمال. بعض أجزاء المنتج تستحقّ عناية كاملة من اليوم الأوّل:
- الأمان. الخادم يتحقّق من الأسعار والصلاحيات، لا المتصفّح أبدًا.
- النسخ الاحتياطية. يومية، وتلقائية، ومُختبرة.
- السجلّات المالية. لا تُعدَّل أبدًا، بل تُصحَّح بقيود جديدة. أشرح السبب في لا تعدّل سجلًّا ماليًا أبدًا.
- نموذج البيانات. طريقة تخزين المعلومات صعبة التغيير لاحقًا.
ضع جهدك الهندسي هناك، وأبقِ كل ما عدا ذلك بسيطًا. أشرح كيف يبدو المنتج البسيط الجيّد في الحدّ الأدنى القابل للتطبيق ليس الحدّ الأدنى من الجهد.
لماذا يهمّ هذا في الجزائر؟
كثير من الخرّيجين الجزائريين يحوّلون مشروع نهاية الدراسة (PFE) إلى أوّل شركة ناشئة لهم. وهذه بداية جيّدة: الفكرة مدروسة، والطالب يعرف موضوعه.
لكنّ مشروع نهاية الدراسة بُني للجنة. وتحويله إلى منتج يعني حذف ما أبهر اللجنة، والاحتفاظ بما يساعد الزبون.
والزبون الجزائري يحكم بسرعة أيضًا. أغلبهم سيجرّب منتجك على هاتف متوسّط، باتصال ينقطع. والتطبيق البسيط الذي يُحمَّل بسرعة يتفوّق على التطبيق الذكي الذي يتجمّد.
أشرح كيف تُبقي التكاليف منخفضة في لماذا تموت التطبيقات المكلفة قبل إطلاقها. وما الذي يتغيّر بين العرض والمنتج الحقيقي في النموذج الأوّلي مقابل نسخة الإنتاج.
ما الأخطاء التي يرتكبها المؤسّسون الجدد؟
- التصميم لملايين المستخدمين قبل أن يكون لديك عشرة. ابنِ للمستخدمين الذين لديك.
- اختيار الأدوات لتبدو ذكيًا. اختر أدوات تستطيع إصلاحها في الثانية ليلًا.
- بناء ميزات "لوقت لاحق". طبّق مبدأ YAGNI.
- تجاوز الأمان والنسخ الاحتياطية لتوفير الوقت. اجمع البساطة والأمان معًا.
- قياس التقدّم بكمّية الكود المكتوب. قسه بالزبائن الذين يعودون.
ماذا تفعل هذا الأسبوع؟
- اليوم: اكتب قائمة بكل أجزاء نظامك. وعلّم تلك التي لا يحتاجها أيّ مستخدم حالي.
- هذا الأسبوع: لكل ميزة في خطّتك، اطرح أسئلة YAGNI الثلاثة.
- هذا الأسبوع: إذا كان تطبيقك مقسّمًا إلى خدمات كثيرة بمستخدمين قليلين، ففكّر في دمجه في تطبيق واحد.
- قبل الإطلاق: تأكّد من النسخ الاحتياطية، وتحقّق الخادم، وسلامة السجلّات المالية.
- كل أسبوع بعدها: أضف التعقيد فقط حين تطلبه مشكلة مستخدم حقيقي.