Software Engineering: فكر قبل ما تكتب الكود

لو بتتعلم البرمجة أو شغال Software Engineer، ممكن تكون المشكلة مش في قدرتك على كتابة الكود، لكن في إنك بتتعامل مع الكود كأنه هو الشغلانة كلها.
الـ Software Engineer الشاطر مش بيبدأ بسؤال: "هستخدم Microservices ولا Monolith؟" أو "هستخدم Kafka ولا RabbitMQ؟"
بيبدأ بسؤال أبسط وأهم: إحنا بنحل إيه أصلًا؟
لأن اختيار التقنية أو الـ Architecture لازم يكون نتيجة لفهم المشكلة، مش الهدف نفسه.

متبدأش بالـ Technology.. ابدأ بالمشكلة​

من الأخطاء الشائعة إن المطور يشوف تقنية جديدة منتشرة ويبدأ يفكر إزاي يستخدمها، بدل ما يسأل الأول إذا كانت المشكلة أصلًا محتاجة التقنية دي.
مثلًا، مش معنى إن Microservices منتشرة إن كل System لازم يتحول إلى Microservices.
ممكن يكون عندك Modular Monolith متصمم بشكل جيد، ويكون أبسط وأسهل في التطوير والصيانة من عشرات الـ Microservices.

وده بيخلينا نسأل قبل أي قرار Architecture:

• إيه المشكلة اللي بنحاول نحلها؟
• إيه القيود الموجودة في الـ System؟
• هل الـ Architecture الحالية فعلًا بتسبب مشكلة؟
• إيه الـ Trade-offs لكل اختيار؟
• هل الـ Complexity الجديدة تستاهل الفائدة؟

الـ Architecture الأفضل مش هي الأحدث، لكنها الأنسب للمشكلة.

---

لما الـ Trend يتحول إلى مشكلة​

في بداية الـ Career، ممكن المطور ينجذب لتقنيات معينة لأنها جديدة أو مطلوبة في السوق.
وده حصل في حالات كتير مع Microservices.
لو الفريق قرر تحويل System موجود إلى Microservices لمجرد إن التقنية Trend أو لأنها هتكون إضافة قوية للـ CV، ممكن النتيجة تكون عكس المتوقع.

بدل ما تحل مشكلة، ممكن تضيف:

• Message Queues.
• Services أكتر محتاجة Monitoring.
• Network Communication.
• Distributed Transactions.
• مشاكل في Debugging.
• Failure Scenarios جديدة.
• Complexity أكبر في Deployment وOperations.

وفي النهاية تلاقي إن الـ System بقى أعقد، من غير ما تكون اتحلت مشكلة حقيقية.
عشان كده، استخدام Technology لمجرد إنها مشهورة مش قرار هندسي كفاية.

---

الـ Integration Engineering بيحتاج تفكير مختلف​

لما تستخدم خدمة زي InstaPay، التجربة بالنسبة للمستخدم بسيطة جدًا: تختار الحساب، تدخل المبلغ، وتضغط تحويل.
لكن خلف العملية دي فيه عدد كبير من الأنظمة اللي لازم تتواصل مع بعض بشكل صحيح.

ممكن يكون عندك:

• بنك أو مؤسسة مالية.
• أنظمة معالجة Transactions.
• APIs.
• Notifications.
• Authentication.
• Logging وMonitoring.
• أنظمة للتعامل مع حالات الفشل.

هنا قيمة الـ Engineer مش مجرد إنه يعرف يعمل API.
المهم إنه يفهم إزاي الأنظمة دي تتعامل مع بعضها، وإيه اللي يحصل لو جزء منها فشل.

مثلًا:
ماذا يحدث لو الـ Request وصل لنظام، لكن الـ Response لم يرجع؟

هل العملية اتنفذت؟ هل نعيد الطلب؟ هل ممكن تتكرر العملية؟ إزاي نضمن إن النظام يقدر يتعامل مع الفشل بدون ما يسبب مشكلة أكبر؟

دي أسئلة مرتبطة بمفاهيم مهمة مثل:

• Resilience.
• Coupling.
• Failure Scenarios.
• Idempotency.
• Observability.
• Distributed Systems.

وده يوضح الفرق بين تنفيذ Function وبين تصميم System يقدر يعيش في الواقع.

---

الـ AI ممكن يكتب الكود.. لكن مش دايمًا يفهم المشكلة​

مع انتشار أدوات الـ AI في البرمجة، كتابة الكود بقت أسرع بشكل واضح.
لكن السرعة في إنتاج الكود مش معناها إن النتيجة أصبحت أفضل.
ممكن تطلب من AI يعمل Refactoring لكود Legacy، ويطلعلك كود شكله أنظف وأسهل في القراءة، لكنه في نفس الوقت يسبب مشكلة في الأداء.
مثلًا، إضافة Loop داخل Loop ممكن تغير التعقيد الزمني من:
O(n²) إلى: O(n³)
الكود ممكن يشتغل بشكل صحيح على Dataset صغيرة، لكن مع زيادة الـ Scale، عدد الـ Operations ممكن يزيد بشكل ضخم.
وده واحد من أهم الأشياء اللي لازم الـ Developer يفهمها:
الكود الصحيح وظيفيًا مش بالضرورة يكون الحل الصحيح هندسيًا.

---

استخدم AI كـ Tutor مش كـ Copy/Paste Machine​

خصوصًا لو أنت Junior Developer، حاول تستفيد من AI في فهم الكود، مش مجرد نسخه.
بدل ما تقول له: "اكتبلي الحل."

اسأله أسئلة تخليك تفهم القرار نفسه:

• ليه اخترت الـ Algorithm دي؟
• إيه الـ Time Complexity للحل؟
• إمتى الحل ده يكون غير مناسب؟
• إيه الـ Trade-offs؟
• ماذا يحدث لو حجم البيانات زاد؟
• هل فيه Alternative أبسط؟
• إيه الـ Failure Scenarios المحتملة؟
• إزاي أختبر الحل؟

الطريقة دي بتخليك تتعلم طريقة التفكير، مش مجرد طريقة كتابة الكود.

---

إيه الفرق بين Developer بيكتب كود وSoftware Engineer؟​

الفرق مش إن Software Engineer يعرف كود أكتر بالضرورة.
الفرق الأكبر في طريقة التفكير.

المطور ممكن يركز على: "إزاي أنفذ الـ Feature دي؟"

بينما الـ Software Engineer بيسأل كمان:

"ليه بنعملها؟"​

"هل ده أفضل تصميم؟"​

"إيه اللي هيحصل لما عدد المستخدمين يزيد؟"​

"ماذا يحدث لو Service وقعت؟"​

"هل الحل ده سهل الصيانة؟"​

"هل الـ Complexity اللي ضفتها تستاهل؟"​

"إيه الـ Trade-offs؟"​

وده مش معناه إنك لازم تستخدم Architecture معقدة أو تحفظ عشرات Design Patterns.
بالعكس، أحيانًا أفضل قرار هندسي هو أبسط حل يحقق المطلوب بشكل جيد.

---

ركز على فهم المشكلة مش سرعة كتابة الكود​

الـ AI هيخلي كتابة الكود أسرع، والأدوات هتتطور أكتر، وكتير من المهام اللي كانت بتحتاج وقت طويل هتبقى أسهل.
لكن ده بيخلي مهارات تانية أهم، مثل:

• تحليل المشكلة.
• اختيار الـ Architecture المناسبة.
• فهم الـ Trade-offs.
• التفكير في الـ Scale.
• فهم الـ Failure Scenarios.
• تقييم الـ Performance.
• تصميم الأنظمة.
• مراجعة الكود الناتج عن AI.

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

---

الحلقة الكاملة​

الموضوع ده اتناقش بتفصيل أكبر مع محمود سيف في حلقة جديدة من كلام في البرمجة، خصوصًا موضوع الـ Software Engineering، الـ Architecture، الـ Integration Engineering وتأثير AI على طريقة كتابة البرمجيات.

يمكن مشاهدة الحلقة كاملة على YouTube:

الأسئلة الشائعة​

------------

هل Software Engineer لازم يستخدم Microservices؟​

لا. Microservices مجرد Architecture لها استخدامات ومميزات وتكاليف. الاختيار الصحيح يعتمد على المشكلة وحجم الـ System واحتياجاته، وليس على كون التقنية منتشرة.

هل AI يمكن أن يحل محل Software Engineer؟​

AI يمكنه المساعدة في كتابة الكود والاختبارات واقتراح الحلول، لكن تقييم الـ Trade-offs وفهم متطلبات النظام والتعامل مع حالات الفشل والقيود ما زالت تحتاج إلى تفكير هندسي.

هل استخدام AI في البرمجة مفيد للمبتدئين؟​

نعم، إذا تم استخدامه للتعلم والفهم. الأفضل أن تطلب من AI شرح سبب اختيار الحل وتحليل الـ Complexity والبدائل، بدل الاعتماد عليه في نسخ الحلول فقط.

لماذا قد يكون Modular Monolith أفضل من Microservices؟​

لأنه قد يوفر تنظيمًا جيدًا للكود مع Complexity أقل في الاتصال بين الخدمات والـ Deployment والـ Monitoring. لو النظام لا يحتاج فعلًا إلى توزيع الخدمات، فقد يكون Modular Monolith أبسط وأكثر ملاءمة.