#014 — Risk Analysis | تحليل المخاطر

في المشاريع البرمجية، ليست المشكلة فقط فيما حدث بالفعل، بل أيضًا فيما قد يحدث لاحقًا.
وهنا يأتي دور Risk Analysis.
الخطر أو Risk هو حدث غير مؤكد قد يقع مستقبلًا ويؤثر على المشروع أو النظام، بينما الـ Issue هي مشكلة حدثت بالفعل وتحتاج إلى معالجة.

بمعنى أبسط:

Risk = قد يحدث
Issue = حدث بالفعل

لذلك لا تنتظر أن يتحول الخطر إلى مشكلة حتى تبدأ التعامل معه.
عند تحليل أي Risk، نركز على عاملين أساسيين:

Probability — ما احتمال حدوثه؟
Impact — إذا حدث، ما حجم تأثيره؟

ومن هنا تأتي المعادلة:

Risk Level = Probability × Impact

فليس كل خطر يستحق نفس مستوى الاهتمام.
خطر احتماله منخفض وتأثيره بسيط ليس مثل خطر احتماله مرتفع وتأثيره كارثي.
ولهذا نستخدم Risk Matrix لترتيب الأولويات وتحديد ما الذي يحتاج تدخلًا عاجلًا، وما الذي يحتاج خطة، وما الذي تكفي متابعته.
والمخاطر لا تظهر فقط في الكود.

قد تكون:
Technical Risks — مخاطر تقنية
Security Risks — مخاطر أمنية
Schedule Risks — مخاطر زمنية
Cost Risks — مخاطر تكلفة
Operational Risks — مخاطر تشغيلية
Business / External Risks — مخاطر أعمال أو جهات خارجية

وأحد أفضل الأسئلة لاكتشاف المخاطر هو:

What if? — ماذا لو؟
ماذا لو تعطلت بوابة الدفع؟
ماذا لو فقدنا البيانات؟
ماذا لو تأخر المشروع؟
ماذا لو تغيرت المتطلبات؟
ماذا لو لم يتحمل النظام عدد المستخدمين؟
ماذا لو توقفت خدمة خارجية يعتمد عليها النظام؟

هذه الأسئلة لا تعني التشاؤم، بل تعني أنك تحاول اكتشاف نقاط الضعف قبل أن تفاجئك.
بعد تحديد المخاطر، لدينا أربع استراتيجيات أساسية للتعامل معها:

Avoid — تجنب الخطر.
Mitigate — قلل احتماله أو تأثيره.
Transfer — انقل جزءًا من مسؤوليته إلى طرف آخر.
Accept — اقبله مع الاستعداد للتعامل معه إذا حدث.

مثال بسيط:

إذا كان لدينا نظام دفع إلكتروني، فقد يكون أحد المخاطر هو:
توقف Payment Gateway.
وهنا قد تكون الاستجابة:

Retry Mechanism
Alternative Provider
User Notification

وقد يكون خطر آخر:
Duplicate Payment

فنحتاج مثلًا إلى:
Idempotency
Transaction Validation
Unique Order ID

وهنا نلاحظ شيئًا مهمًا:
التفكير في المخاطر قبل البرمجة قد يغيّر تصميم النظام نفسه.
لذلك تحليل المخاطر ليس مستندًا نكتبه وننساه.
بل هو عملية مستمرة:

Identify → Analyze → Prioritize → Respond → Monitor

والهدف ليس منع كل مشكلة في العالم.
الهدف هو ألا تصل المشكلة إليك وأنت تقول:
"لم نفكر في هذا الاحتمال."
القاعدة التي أعود إليها دائمًا:

Early Risk Detection → Better Decisions → Safer Project

وسؤال للنقاش:

لديك تطبيق بنكي يعتمد على خدمة خارجية لإرسال OTP.
إذا توقفت هذه الخدمة لمدة ساعتين، ما المخاطر التي ستحدث؟ وما خطتك للتعامل معها؟
المنشور القادم:

#015 — Requirements Prioritization
عندما تكون كل المتطلبات مهمة... كيف نحدد ماذا نبني أولًا؟

م. طارق العمري
Software Engineer | Backend Developer

#SoftwareEngineering #RiskAnalysis #RiskManagement #RiskMatrix #SystemAnalysis #RequirementsEngineering #SoftwareArchitecture #CyberSecurity #ProjectManagement #BusinessAnalysis #SystemDesign #SoftwareDevelopment #BackendDevelopment #SoftwareEngineer #هندسة_البرمجيات #تحليل_المخاطر #إدارة_المخاطر #تطوير_البرمجيات

#015 — Software Design | تصميم البرمجيات

بعد أن نفهم المشكلة، نجمع المتطلبات، نحلل العمليات، ونحدد المخاطر… يأتي سؤال مهم جدًا:
كيف سنحوّل كل هذا الفهم إلى نظام يمكن بناؤه فعليًا؟
هنا تبدأ مرحلة Software Design — تصميم البرمجيات.
التحليل يخبرنا:
WHAT? — ماذا يجب أن يفعل النظام؟
أما التصميم فيجيب:
HOW? — كيف سنبني النظام ليحقق ذلك؟
ولهذا فالتسلسل الطبيعي ليس:
Requirements → Code

بل:
Requirements → Design → Code
في مرحلة التصميم نبدأ بتحديد مكونات النظام، مسؤولية كل مكوّن، طريقة انتقال البيانات، كيفية التواصل بين الأجزاء، نقاط اتخاذ القرار، والقيود التقنية والأمنية والأدائية التي يجب مراعاتها.
وهنا يظهر مفهومان مهمان:

HLD — High-Level Design ينظر إلى الصورة الكبيرة: Architecture، Services، Database، External Systems، وكيف تتواصل المكونات.

بينما LLD — Low-Level Design يدخل إلى التفاصيل: Classes، Methods، Interfaces، Data Structures، Validation، وError Handling.

لكن التصميم الجيد لا يعني إضافة أكبر عدد ممكن من الطبقات والأنماط والمكونات.
بل يعني أن تعطي كل جزء مسؤولية واضحة.
فبدل أن يكون لدينا Component واحد مسؤول عن Login وOrders وPayments وNotifications وكل شيء آخر، نفصل المسؤوليات بطريقة تجعل النظام أوضح وأسهل في التغيير والاختبار.
وهنا تظهر قاعدة مهمة:

High Cohesion + Low Coupling

أي أن الأشياء المرتبطة منطقيًا تبقى معًا، وفي الوقت نفسه نقلل الاعتماد غير الضروري بين المكونات.

مثال:
لدينا Requirement تقول:
"يجب أن يستطيع العميل إنشاء طلب ودفع قيمته إلكترونيًا."
قد تتحول في التصميم إلى:

Client App → Order Controller → Order Service → Payment Service → Payment Gateway → Database → Notification Service

متطلب واحد فقط، لكنه يحتاج عدة مكونات تتعاون لتحقيق الهدف.
لكن السؤال الأهم:
كيف أعرف أن تصميمي جيد؟

التصميم الجيد عادةً يكون قابلًا للصيانة Maintainable، وقابلًا للتوسع Scalable، وقابلًا للاختبار Testable، وآمنًا Secure، وفعّالًا Performant، وبسيطًا بالقدر المناسب Simple.
لأن التصميم الجيد لا يحل مشكلة اليوم فقط؛ بل يجعل تغيير النظام غدًا أسهل وأقل تكلفة.

وفي المقابل، هناك أخطاء تصميمية شائعة يجب الحذر منها مثل: Overengineering، Tight Coupling، God Class، Premature Optimization، Ignoring Failure Cases، وDesigning Without Requirements.

لذلك:
Good Design ≠ More Complexity
بل:
Good Design = Right Complexity

لا تجعل الكود هو المكان الذي تكتشف فيه تصميم النظام للمرة الأولى.
Think → Design → Then Code
ويمكن تلخيص الرحلة هكذا:
Clear Requirements + Good Design = Cleaner Code

سؤال للنقاش:
لو كنت تصمم متجرًا إلكترونيًا، هل ستضع Orders وPayments وNotifications داخل Service واحدة، أم ستفصل مسؤولياتها؟ ولماذا؟

المنشور القادم:

#016 — Software Architecture
ما الفرق بين التصميم والمعمارية؟ وكيف نحدد الشكل العام للنظام؟

م. طارق العمري
Software Engineer | Backend Developer

#SoftwareEngineering #SoftwareDesign #SystemDesign #HighLevelDesign #LowLevelDesign #HLD #LLD #SeparationOfConcerns #CleanArchitecture #SoftwareArchitecture #SystemAnalysis #RequirementsEngineering #BackendDevelopment #SoftwareDevelopment #SoftwareEngineer #هندسة_البرمجيات #تصميم_البرمجيات #معمارية_البرمجيات #تطوير_البرمجيات

أول تغذية راجعة وتقييم من أحد الطلاب الذي قمت بتدريسهم مقرر التسويق بالمحتوى

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

2 -السلبيات:
في البداية كنت ماأتأقلم مع محاضراتك لكن بعدين تأقلمت وفهمت المقرر.

3 -الإقتراحات:
اقترح أن تفعل بشكل مختلف هو ان تكون تخلي الطلاب يشرحون بعض الأشياء على مفهومهم .
الشيء اللي اقترح لو انه طولنا فيه بالمقرر هو تصميم الإعلانات والمحتويات البصرية.

4 -اهم شيء خرجت فيه من التجربة:
اعتقد انه اهم شيء هو المواصله والتعلم المستمر.


"واخيراً شكراً لجهودك معنا وتفهمك لنا وكان مقرر ممتاز اخذناه معك"

عرض تقديمي شرح كيفية عمل نظام ذكي لادارة شكاوى العملاء عن طريق سير عمل N8N