Sokkary | Code3arabi

🎬 سيناريو عملي: كيف يُستخدم Jira في مشروع برمجي حقيقي؟ في هذا السيناريو التطبيقي، سنشاهد كيف يتم استخدام Jira خطوة بخطوة داخل شركة برمجة تقوم بتطوير تطبيق جوال. 👥 الفريق Product Owner: أحمد Scrum Master: سارة المطورون: محمود، علي، مريم المصمم: يوسف المختبر (QA): نور 🧩 الخطوة 1: إنشاء المشروع في Jira يقوم أحمد (Product Owner) بفتح مشروع جديد في Jira تحت نوع Scrum . يُحدد هدف المشروع: "تطبيق جوال لحجز مواعيد الأطباء". 🗂️ الخطوة 2: كتابة المهام (Issues) يقوم Product Owner بإضافة المهام التالية: 📘 Story: تسجيل الدخول 🛠️ Task: تصميم شاشة تسجيل الدخول 🐞 Bug: مشكلة في زر الإرسال 📦 Epic: نظام إدارة الحسابات كل مهمة تحتوي على: العنوان، الوصف، الشخص المسؤول، الأولوية، الحالة (To Do, In Progress, Done...). 🌀 الخطوة 3: تخطيط Sprint يتم اختيار المهام التي سيتم تنفيذها خلال الأسبوعين القادمين. يتم سحب المهام من Backlog إلى Sprint الجديد. 👨‍💻 الخطوة 4: بدء العمل وتحديث المهام محمود يخت...

📌 ما الذي يمكن أن يفعله Jira بالضبط؟ Jira هو أداة قوية لإدارة المشاريع تُستخدم بشكل شائع في بيئات البرمجة والتطوير، وتُوفر وظائف متعددة تساعد الفرق على تنظيم العمل بكفاءة عالية. ✅ 1. إدارة المهام (Tasks Management) إنشاء مهام (Tickets) لكل جزء من أجزاء العمل مثل: إصلاح خطأ، تطوير ميزة، كتابة توثيق. تعيين المهام إلى أعضاء الفريق وتحديد الأولوية والموعد النهائي لكل مهمة. ✅ 2. تتبع الأخطاء (Bug Tracking) تسجيل الأخطاء البرمجية ومشاكل النظام. متابعة حالة الخطأ من الاكتشاف حتى الحل (Open → In Progress → Fixed). ✅ 3. إدارة مشاريع Agile (Scrum / Kanban) إنشاء Sprint Boards وجدولة سباقات (Sprints). لوحات Kanban لتتبع المهام بشكل بصري. إدارة الـ Backlog بسهولة مع تقسيم المهام حسب الأولويات. ✅ 4. تخصيص سير العمل (Workflow) تحديد خطوات سير العمل للمهمة: مثل To Do → In Progress → Code Review → Done. إمكانية إنشاء حالات مخصصة مثل "بانتظار الاختبار" أو "مرفوض". ✅ 5. تقارير الأداء (Reports & Dashboards) تقاري...

🔧 مثال عملي: كيف نستخدم Jira في مشروع برمجي حقيقي؟ في هذا المثال، سنفترض أننا نعمل على مشروع برمجي لبناء تطبيق لإدارة المهام ، ونريد استخدام Jira لتنظيم العمل وتوزيع المهام على أعضاء الفريق. 1. إنشاء مشروع في Jira ندخل إلى Jira ونختار: Create Project نختار نوع المشروع: Scrum نُسمي المشروع: "Task Management App" 2. بناء الـ Backlog نبدأ بإنشاء المهام الأساسية في المشروع: 🔹 TM-1: تصميم قاعدة البيانات (Database Design) 🔹 TM-2: إعداد مشروع ASP.NET Core 🔹 TM-3: تصميم صفحة تسجيل الدخول 🔹 TM-4: إنشاء واجهة إضافة مهمة 🔹 TM-5: ربط المهام بالمستخدمين 3. إنشاء Sprint نُنشئ Sprint جديد بإسم: "Sprint 1 - الأساسيات" نُحدد مدته: 2 أسابيع نُضيف إليه المهام: TM-1, TM-2, TM-3 4. استخدام لوحة Scrum يتم عرض المهام في لوحة Scrum ضمن الأعمدة: To Do: المهام التي لم تبدأ بعد In Progress: المهام التي يعمل عليها أحد المطورين Code Review: جاهزة للمراجعة Done: المهام المنجزة 5. تتبع التقدم وتحلي...

SDLC - أدوات تتبع المشروع (Project Tracking Tools) 🔹 أدوات تتبع المشاريع هي جزء مهم في دورة حياة تطوير البرمجيات، حيث تساعد الفرق على التخطيط، التتبع، التعاون، والتسليم بفعالية. 1. أهمية أدوات التتبع تُوفر رؤية واضحة لتقدم المشروع. تُساعد في توزيع المهام بوضوح بين أفراد الفريق. تُقلل من الفوضى وسوء التفاهم. تُساعد على الالتزام بالمواعيد النهائية. 2. أشهر أدوات تتبع المشروع 🛠️ Jira أداة قوية تُستخدم بشكل واسع في بيئات Agile وScrum. تُستخدم لتتبع الـ Epics، Stories، Tasks، Bugs. تُوفر لوحات Kanban و Sprint Boards. 📋 Trello أداة مرئية تعتمد على أسلوب Kanban. مثالية للفرق الصغيرة أو المشاريع البسيطة. واجهة سهلة وسريعة الإعداد. 🧩 Azure DevOps Boards جزء من نظام Azure DevOps الكامل. يدعم Agile و Scrum و Kanban. متكامل مع Git وCI/CD pipelines. 📌 ClickUp / Asana / Monday أدوات تتبع متعددة الاستخدامات. توفر تقارير وإشعارات وتنبيهات متقدمة. 3. كيف تختار الأداة المناسبة؟ حسب حجم الفريق وتعقيد المشروع. ...

SDLC - مفاهيم التكامل والتسليم المستمر (CI/CD) 🔹 CI/CD هو اختصار لمفهومين أساسيين في دورة حياة التطوير الحديثة: CI (Continuous Integration) و CD (Continuous Delivery/Deployment) . 1. ما هو Continuous Integration (CI)؟ يعني دمج الكود الجديد من المطورين في المستودع الرئيسي (repository) بشكل مستمر. يتم التحقق تلقائيًا من الكود عن طريق اختبارات Unit Tests. يهدف إلى اكتشاف الأخطاء مبكرًا وتقليل مشاكل الدمج. أدوات CI الشائعة: Jenkins GitHub Actions CircleCI GitLab CI 2. ما هو Continuous Delivery (CD)؟ يعني نشر الكود تلقائيًا إلى بيئة اختبار أو تشغيل بمجرد اجتيازه جميع الاختبارات. يتطلب موافقة بشرية لنشره إلى الإنتاج. يحافظ على جاهزية الكود للنشر في أي وقت. 3. ما هو Continuous Deployment؟ الخطوة التالية بعد CD. يتم نشر الكود إلى بيئة الإنتاج تلقائيًا بدون تدخل بشري. 4. فوائد CI/CD تسليم أسرع للكود. تقليل الأخطاء البرمجية. تحسين جودة المنتج. زيادة ثقة الفريق في الكود الجديد. 5. تحديات CI/CD يتطلب إعدا...

SDLC - دمج DevOps (خصوصًا في Agile) 🔹 DevOps هو مزيج من "Development" و "Operations"، ويهدف إلى دمج فرق التطوير والتشغيل لتحسين سرعة وجودة تسليم البرمجيات. في بيئات Agile، يُعتبر DevOps شريكًا طبيعيًا لتحقيق التكرار السريع والاستجابة للتغييرات. 1. لماذا DevOps مهم في SDLC؟ تقليل الوقت بين كتابة الكود وتشغيله في البيئة الحية. تحسين جودة النشر وتقليل الأخطاء. دعم النشر المستمر (Continuous Delivery). تعزيز التعاون بين فرق التطوير وفرق البنية التحتية. 2. كيف يندمج DevOps مع Agile؟ Agile تركز على سرعة التطوير. DevOps تضمن تسليم الكود بسرعة وجودة إلى المستخدم. كلاهما يشجع على التحسين المستمر والتعاون الفعّال. 3. ممارسات DevOps الأساسية التكامل المستمر (CI): دمج الكود من المطورين باستمرار والتحقق منه آليًا. التسليم المستمر (CD): نشر الكود تلقائيًا بعد اجتياز الاختبارات. الرصد والمراقبة (Monitoring): مراقبة النظام في الوقت الحقيقي بعد النشر. البنية التحتية ككود (IaC): إدارة بيئة التشغيل باستخدام كود. 4. أ...

SDLC - إدارة المخاطر (Risk Management) 🔹 إدارة المخاطر هي عملية تحديد وتقييم والتعامل مع المخاطر التي قد تؤثر على نجاح المشروع البرمجي. تعتبر من أهم الأنشطة في SDLC لضمان تنفيذ المشروع في الوقت المحدد وضمن الميزانية. 1. ما هي المخاطر في المشاريع البرمجية؟ تأخّر في التسليم. تجاوز الميزانية. تغير في متطلبات العميل. مشاكل في جودة المنتج. اعتماد على تقنيات أو أفراد محددين. 2. مراحل إدارة المخاطر تحديد المخاطر (Risk Identification): اكتشاف جميع التهديدات المحتملة للمشروع. تحليل المخاطر (Risk Analysis): تقييم مدى تأثير واحتمالية حدوث كل خطر. وضع خطة للمخاطر (Risk Planning): تحديد الإجراءات التي يمكن اتخاذها للتعامل مع كل خطر. المتابعة والتحكم (Monitoring): مراقبة المخاطر بشكل دوري والتحديث عند الحاجة. 3. تصنيف المخاطر مخاطر فنية: مثل تعقيد النظام أو الأداء. مخاطر إدارية: مثل سوء التواصل أو ضعف القيادة. مخاطر زمنية: مثل التأخر في التسليم. مخاطر مالية: مثل تجاوز الميزانية. 4. أدوات شائعة لإدارة المخاطر Jira Ris...

SDLC - التوثيق (Documentation) 🔹 التوثيق هو عنصر أساسي في دورة حياة تطوير البرمجيات (SDLC)، ويُستخدم لتوثيق جميع مراحل المشروع، من التحليل وحتى الصيانة. 1. أهمية التوثيق يضمن الفهم المشترك بين جميع أعضاء الفريق. يُسهل صيانة النظام لاحقًا. يساعد في تدريب المطورين الجدد. يقلل من الاعتماد على الأشخاص (knowledge dependency). 2. أنواع التوثيق في SDLC توثيق المتطلبات (Requirements Documentation): يشمل المتطلبات الوظيفية وغير الوظيفية. المخططات التقنية (Technical Specs): تشرح البنية التقنية، قواعد البيانات، واجهات API، إلخ. توثيق الكود (Code Documentation): يشمل التعليقات، واستخدام أدوات مثل XML Docs أو Doxygen. توثيق المستخدم (User Manuals): يساعد المستخدم النهائي في استخدام النظام. وثائق الاختبار (Test Plans): تحدد كيف سيتم اختبار النظام. 3. أدوات التوثيق الشائعة Microsoft Word / Google Docs Confluence Markdown + GitHub Wiki Notion 4. نصائح مهمة اكتب التوثيق أثناء التطوير، وليس بعده فقط. اجعله بسيطًا وواضحًا...

✅ Software Testing – اختبار البرمجيات بالتفصيل ✳️ أولاً: ما هو اختبار البرمجيات؟ اختبار البرمجيات هو عملية التحقق من إن البرنامج: شغال زي ما المفروض بيحقق المتطلبات خالي من الأخطاء قدر الإمكان سهل الاستخدام وآمن الهدف الأساسي = ضمان الجودة (Quality Assurance) 🧭 نوعين أساسيين: النوع المعنى ✅ Verification بنتأكد إننا بنبني البرنامج "بالطريقة الصح" (تقييم العملية) ✅ Validation بنتأكد إننا بنبني "البرنامج الصح" (تقييم المنتج النهائي) 🧪 أنواع الاختبارات الرئيسية: 1. 🧱 Unit Testing – اختبار الوحدات بيختبر وحدة صغيرة جدًا (Class / Method) مثال: دالة Add(x, y) → هل بترجع ناتج صحيح؟ 🔧 أدوات في C#: xUnit – NUnit – MSTest 2. 🧩 Integration Testing – اختبار التكامل نختبر ربط الأجزاء ببعضها: API ↔ Database Frontend ↔ Backend مثال: بعد إضافة منتج → هل فعلاً اتحفظ في قاعدة البيانات؟ 3. 🧰 System Testing – اختبار النظام ككل نختبر كل النظام من منظور المستخدم النهائي هل كل المزايا شغالة بشكل متكامل...

🗂️ Kanban – كانبان ✅ تعريف Kanban: Kanban هي طريقة مرنة لإدارة العمل تركّز على "تدفق المهام"، يعني بدل ما نقسم الوقت إلى فترات (زي Sprints في Scrum)، إحنا بنشتغل على المهام واحدة ورا التانية، ونركّز على إن الشغل يمشي بسلاسة من البداية للنهاية. تخيل لوحة فيها أعمدة "To Do → In Progress → Done"، وكل مهمة بتتنقل من عمود للتاني حسب المرحلة اللي وصلت لها. 📋 الفكرة الأساسية في Kanban: التركيز على العمل الجاري (Work In Progress – WIP) متابعة سير المهام بشكل بصري تحديد الحد الأقصى للمهام اللي بتكون تحت التنفيذ في نفس الوقت 🧱 مكونات لوحة Kanban الأساسية: العمود معناه 📌 To Do المهام اللي لسه ما اشتغلناش عليها 🛠️ In Progress المهام اللي جاري تنفيذها حاليًا ✅ Done المهام اللي خلصت تمامًا 📝 ممكن تضيف أعمدة زيادة حسب احتياج الفريق، مثل: Waiting for Review Testing Blocked 📊 المبدأ الأساسي في Kanban: "ابدأ من حيث أنت، وركّز على تحسين التدفق (Flow)" يعني: مش لازم تعيد هيكلة الفريق أو تغيّر أسلوبك كليً...

🧩 Scrum – منهجية سكرم بالتفصيل ✅ أولًا: إيه هو Scrum؟ Scrum هو إطار عمل (Framework) من ضمن عائلة Agile بيخلّي تطوير البرمجيات مرن – سريع – تفاعلي وبيقسم الشغل إلى وحدات صغيرة اسمها Sprints (كل Sprint مدتها من 1 إلى 4 أسابيع). زي ماتش كورة فيه مدرب، كابتن، لاعبين، ومراحل تدريب بين كل ماتش والتاني 🏟️ 👥 أدوار Scrum الأساسية: الدور مهمته 👤 Product Owner صوت العميل – بيحدد إيه اللي يتعمل وإمتى 🧑‍💼 Scrum Master يسهل الشغل – يزيل العوائق – يضمن التزام الفريق بـ Scrum 👨‍💻 Development Team الفريق اللي بينفذ فعليًا (مبرمجين، مصممين، مختبرين...) 📦 أهم مصطلحات Scrum: 📝 1. Product Backlog قائمة بكل المتطلبات والميزات اللي العميل عايزها بيجهزها الـ Product Owner ومرتبة حسب الأولوية 🎯 2. Sprint مدة زمنية ثابتة (مثلاً أسبوعين)، فيها الفريق يشتغل على مجموعة من المهام المختارة من الـ Backlog في آخر Sprint، لازم يكون فيه شيء شغال فعليًا 🔧 3. Sprint Backlog قائمة المهام اللي هيشتغل عليها الفريق داخل Sprint واحدة 📈 4. Increment النتيجة الشغالة اللي...

🌀 Agile Model – نموذج أجايل ✅ تعريف: Agile مش مجرد نموذج، هو فكر ومنهجية مرنة لتطوير البرمجيات. بعكس Waterfall اللي ماشي خط مستقيم، Agile بيقسم المشروع لأجزاء صغيرة اسمها Sprints ، وكل Sprint بتكون دورة حياة كاملة صغيرة (تخطيط → تصميم → برمجة → اختبار → تسليم). العميل دايمًا بيشوف شغل حقيقي كل أسبوعين أو شهر. 🧱 مبادئ أجايل (من "البيان الأجايل - Agile Manifesto"): الأفراد والتفاعل أهم من الأدوات والعمليات البرمجيات الشغالة أهم من التوثيق الضخم تعاون العميل أهم من التفاوض بالعقود الاستجابة للتغيير أهم من الالتزام بالخطة 🔁 دورة Sprint واحدة: الخطوة التفاصيل 📝 التخطيط (Planning) نختار المهام اللي هنعملها في الـ Sprint الجاي 🧠 التصميم (Design) تصميم سريع للجزء اللي هنعمله 💻 البرمجة (Coding) نكتب الكود للوظيفة المطلوبة 🧪 الاختبار (Testing) نختبر الوظيفة دي فقط 🚀 التسليم (Delivery) نعرضها للعميل وياخد Feedback 📈 التحسين (Retrospective) نراجع Sprint ونحسّن أسلوبنا 📆 ما هو Sprint؟ دورة قصيرة (عادة 1 – 4 أسابيع...

🏞️ Waterfall Model – نموذج الشلال "كل مرحلة بتنزل وتكمل اللي قبلها… ومفيش رجوع لفوق بسهولة." ✅ تعريف: هو نموذج تقليدي لتطوير البرمجيات بيعتمد على تنفيذ المراحل واحدة وراء التانية بشكل خطي . يعني المرحلة التالية تبدأ فقط بعد انتهاء اللي قبلها بنسبة 100%. شبه شلال الميه… بينزل من فوق لتحت وما بيرجعش. 🧱 مراحل Waterfall Model بتفصيل كامل: 1. Requirement Gathering & Analysis – جمع وتحليل المتطلبات 🔍 في المرحلة دي: بنقعد مع العميل أو المستخدمين بنجمع المتطلبات المطلوبة للنظام بنحللها ونفهم كل جزئية 📄 ناتج المرحلة: وثيقة اسمها SRS (Software Requirements Specification) 📌 ملاحظات: المتطلبات لازم تكون "كاملة وثابتة" أي تعديل بعد كده صعب ومكلف 2. System Design – التصميم 🧠 بنستخدم المتطلبات اللي جمعناها علشان نعمل: تصميم قاعدة البيانات تصميم الواجهات (UI) بنية النظام الداخلية (Architecture) 🛠️ ممكن نستخدم أدوات زي: ERD UML Diagrams Wireframes 📄 ناتج المرحلة: ملفات تصميم + مخططات 📌 ملاحظات: التصميم هن...

✳️ نماذج وآليات العمل في تطوير البرمجيات (Development Methodologies) ✅ أولًا: ليه بنحتاج "آلية عمل" أو "منهجية"؟ المشروع البرمجي مش بس كود… ده تعاون بين: العميل المبرمجين المصممين المختبرين (QA) علشان نضمن إن الشغل منظم والناس كلها ماشية على نفس الطريق، بنمشي حسب "نموذج شغل" (Software Development Methodology). 📊 أشهر النماذج: هنبدأ دلوقتي بشرحين اتنين من أشهرهم: 1. Waterfall Model – الشلال 🌊 الفكرة: ده أقدم نموذج، وبيعتمد على التتابع الصارم للمراحل. كل مرحلة لازم تخلص تمامًا قبل ما نبدأ اللي بعدها. 🔁 المراحل: التخطيط تحليل المتطلبات التصميم البرمجة الاختبار النشر الصيانة ✅ مميزاته: واضح ومنظم جدًا سهل في التوثيق والمتابعة مناسب للمشاريع الصغيرة أو اللي المتطلبات فيها ثابتة ❌ عيوبه: ماينفعش تغير بسهولة في المتطلبات بعد البداية العميل مش بيشوف حاجة شغالة إلا بعد ما المشروع يخلص صعب الرجوع خطوة لورا (زي الشلال فعلاً!) 2. Agile – أجايل 🌀 الفكرة: بدل ما نمشي المشروع كله مرة واح...

✅ 7. Maintenance – مرحلة الصيانة 🎯 الهدف من المرحلة دي: بعد ما النظام اتنشر وبدأ المستخدمين يستعملوه، الطبيعي إنه تظهر: أخطاء ما كانتش واضحة قبل كده اقتراحات جديدة تغييرات في السوق أو في شغل العميل فبنبدأ نعمل صيانة وتحديثات بشكل مستمر. 📌 أنواع الصيانة: النوع الوصف 🔧 Corrective Maintenance تصليح أخطاء ظهرت بعد النشر 🛠️ Adaptive Maintenance تعديل النظام علشان يواكب تغييرات (مثلاً تحديثات في نظام التشغيل أو تغيير في القوانين) 🚀 Perfective Maintenance تحسين الأداء أو إضافة مزايا جديدة حسب طلب العميل 🔒 Preventive Maintenance تحسين الكود أو البنية التحتية لمنع مشاكل مستقبلية 🧠 إيه المهم تفهمه هنا؟ الشغل ما بيخلصش بعد النشر، الصيانة جزء مهم جدًا العميل دايمًا بيلاحظ حاجات بعد ما يستخدم النظام لازم يكون عندك نظام للتعامل مع طلبات التعديل أو الشكاوى متابعة الأداء والأمان بشكل دوري مهمة جدًا 🧾 أمثلة عملية: في تطبيق البيع أونلاين: فيه عميل بيقول إن الطلب ما بيوصلش إيميل التأكيد؟ → محتاج تصلّح مشكلة الإيميل ظهرت فكرة جدي...

✅ 6. Deployment – مرحلة النشر 🎯 الهدف من المرحلة دي: نرفع المشروع على بيئة حقيقية (Production) علشان المستخدمين يقدروا يبدأوا يستخدموه فعليًا. خلاص، البرنامج طلع للنور 🎉 📌 خطوات مرحلة النشر: إعداد بيئة التشغيل (Production Environment): سيرفرات جاهزة قواعد البيانات مفعّلة إعدادات الأمان والنسخ الاحتياطي متوفرة رفع الملفات: نسخ الكود أو الحزمة الجاهزة (Build) إلى السيرفر إعداد قواعد البيانات وربطها بالتطبيق التأكد من التشغيل: تجربة سريعة لكل الوظائف الأساسية بعد النشر التأكد من عدم وجود مشاكل في الاتصال أو البيانات مراقبة النظام (Monitoring): بنستخدم أدوات تتابع الأداء (مثل: Application Insights, ELK, أو NewRelic) لو في أخطاء أو بطء – نتصرف بسرعة إعلام المستخدمين أو العملاء: ممكن تبعت إيميل أو تنشر إعلان إن التطبيق أصبح متاح للاستخدام 📦 أنواع النشر (Deployment Types): النوع الوصف Full Deployment نشر كل النظام مرة واحدة Phased Deployment نشر النظام على مراحل، مثلاً محافظة واحدة أو قسم واحد Pilot Deployment تجر...

✅ 5. Testing – مرحلة الاختبار 🎯 الهدف من المرحلة دي: نتأكد إن الكود اللي كتبناه بيشتغل زي ما المفروض، من غير أخطاء، وبيحقق المتطلبات اللي العميل طلبها. 📌 إيه اللي بيحصل في المرحلة دي؟ اختبار الوظائف (Functional Testing): هل النظام بيقوم بالوظائف المطلوبة فعلاً؟ مثلًا: هل المستخدم يقدر يسجل؟ يضيف منتج؟ يدفع؟ اختبار الأداء (Performance Testing): هل النظام سريع؟ بيقدر يتحمل عدد كبير من المستخدمين في نفس الوقت؟ اختبار الأمان (Security Testing): هل في حماية من الاختراق؟ هل البيانات مشفرة؟ هل في صلاحيات واضحة (Admin / User)؟ اختبار القبول (User Acceptance Testing – UAT): بنعرض النظام على العميل علشان يجربه لو قال OK، يبقى جاهز للنشر اختبار التوافق (Compatibility Testing): هل الموقع شغال على كل الأجهزة والمتصفحات؟ هل التطبيق شغال على Android و iOS؟ 🧪 أنواع الاختبارات: النوع وصف سريع Unit Testing اختبار وحدة صغيرة زي دالة أو كلاس Integration Testing اختبار ربط الأجزاء مع بعض System Testing اختبار النظام كك...

✅ 4. Implementation – البرمجة وكتابة الكود 🎯 الهدف من المرحلة دي: نبدأ نحول كل اللي خططناه وصممناه إلى كود شغال فعلًا. يعني من الورق والرسومات... إلى تطبيق فعلي بيشتغل قدامنا. 📌 إيه اللي بيحصل في المرحلة دي؟ اختيار لغة البرمجة والتقنيات المناسبة: مثلًا: C# + ASP.NET Core (Backend) Blazor / Angular / React (Frontend) SQL Server أو أي قاعدة بيانات تقسيم المهام بين المبرمجين: واحد يشتغل على Login واحد على قاعدة البيانات واحد على صفحة المنتجات كتابة الكود حسب التصميم السابق: اتباع الطبقات (Layers) استخدام أسماء المتغيرات بوضوح كتابة أكواد نظيفة وقابلة للصيانة الالتزام بمعايير الكود (Coding Standards): استخدام تعليقات واضحة ما تكررش الكود خلي الكود مقروء لأي حد استخدام أنظمة التحكم في الإصدارات (مثل Git): علشان تقدر تتابع التعديلات وتشتغل ضمن فريق منظم 🧠 إيه المهم تفهمه هنا؟ لازم تبدأ البرمجة بعد ما تكون المتطلبات واضحة والتصميم جاهز البرمجة مش مجرد كود شغال، لازم يكون منظم – واضح – قابل للتعديل ...

✅ 3. Design – مرحلة التصميم 🎯 الهدف من المرحلة دي: نحول المتطلبات اللي جمعناها في المرحلة اللي فاتت، إلى تصميم فعلي للنظام — يعني نبدأ نرسم خريطة المشروع، ونحدد شكله من جوه ومن برّه. 📌 التصميم بيكون على مستويين: 🧱 1. High-Level Design (التصميم العام) يعني الهيكل العام للنظام (نظرة من فوق): يتكوّن من كام جزء؟ هيشتغل من خلال أي طبقات (Layers)؟ هنعمل قاعدة بيانات؟ فيه API؟ ولا تطبيق واحد؟ 💡 مثال: فيه Frontend – Backend – Database – Auth Service – Payment Gateway ⚙️ 2. Low-Level Design (التصميم التفصيلي) بندخل في تفاصيل أكتر: كل كلاس (Class) هيعمل إيه؟ الجداول في قاعدة البيانات هتكون إزاي؟ شكل الشاشات وواجهات المستخدم (UI Mockups) 📄 أدوات بتساعد في مرحلة التصميم: UML diagrams (زي Class Diagram وSequence Diagram) ERD – Entity Relationship Diagram (لرسم قاعدة البيانات) Wireframes / Mockups (لرسم شكل الصفحات للمستخدم) 🧠 إيه اللي المفروض تعرفه من المرحلة دي؟ تفهم الفرق بين التصميم العام والتفصيلي تعرف ترسم مخطط يوضح علاقة الك...

✅ 2. Requirements Analysis – تحليل المتطلبات 🎯 الهدف من المرحلة دي: نفهم بالظبط العميل أو المستخدم محتاج إيه من النظام. مش بس "إيه عايز يعمله" لكن كمان "عايزه يشتغل إزاي؟" 📌 إيه اللي بيحصل في المرحلة دي؟ جمع المتطلبات (Requirements Gathering): بنقعد مع العميل أو أصحاب المشروع ونسألهم: إيه اللي محتاجينه بالظبط؟ النظام ده هيشتغل فين؟ لمين؟ إيه المشاكل اللي النظام هيحلها؟ تصنيف المتطلبات: بنقسم المتطلبات إلى نوعين: ✅ وظيفية (Functional Requirements): دي الحاجات اللي المفروض النظام يعملها، زي: المستخدم يسجل دخول – يضيف منتج – يشتري – يدفع ⚙️ غير وظيفية (Non-Functional Requirements): دي حاجات مش واضحة في السلوك، بس مهمة زي: السرعة – الأمان – الأداء – عدد المستخدمين المتوقع توثيق المتطلبات (Documentation): كل المتطلبات بنكتبها في مستند رسمي، غالبًا اسمه: SRS - Software Requirements Specification موافقة العميل: لازم العميل يراجع المستند ده ويوافق عليه، عشان نكمل شغلنا بناءً عليه، ومايحصلش مشاكل بعدين. 🧠 المفروض تفهم إيه ...