Software Engineering Process

#SDLC: اختار دورة تناسب المخاطرةSDLC: match the lifecycle to the risk

كتابة الكود جزء من شغل أوسع: نفهم الاحتياج، ونصمم، وننفذ، ونتحقق، وننشر، ونشغّل ونحسن. دي SDLC. المشكلة مش اختيار اسم منهج مشهور؛ المشكلة إزاي نكتشف الفرضيات الغلط بدري ونوصل قيمة يمكن تشغيلها.

ممكن تجمع iterative وincremental، وتشتغل Agile مع متطلبات اعتماد رسمية. اعمل feedback gates مناسبة للمخاطرة بدل افتراض إن كل التغييرات محتاجة نفس الإجراءات.

#Agile manifesto بكلام عمليThe Agile manifesto in practical terms

Agile مش معناه مفيش خطة أو docs. قيمه الأربعة بتوجّه الاختيار وقت التعارض:

1. خلّي الناس تتكلم وتحل المشكلة؛ الأداة والـ workflow يساعدوهم.
2. اختبر قيمة software شغّال؛ الوثيقة بتشرح وتدعم، لكنها مش دليل إن الحل نافع.
3. اشتغل مع العميل على فهم احتياجه مع الوقت؛ العقد مش بديل للحوار.
4. عدّل الخطة لما تتعلم؛ التخطيط مستمر بدل التمسك بتوقع قديم.

عملياً: slice صغيرة، وdemo، وfeedback، وقياس نتيجة، وبعدها قرار. Technical excellence وtesting بيسهّلوا التغيير الآمن. كثرة الاجتماعات أو تغيير الأولويات يومياً مش دليل Agile. المرجع: Agile manifesto.

#Scrum: المسؤوليات والـ events والـ artifactsScrum accountabilities, events and artifacts

Scrum بيدي cadence للفحص والتكيّف حوالين هدف. Scrum Team فيه Product Owner مسؤول عن تعظيم القيمة وترتيب Product Backlog، وScrum Master مسؤول عن فعالية Scrum وإزالة معوقات تطبيقه، وDevelopers مسؤولين عن خطة الشغل والجودة والـ Increment. مفيش دور رسمي اسمه project manager في Scrum، حتى لو المؤسسة عندها الدور ده.

Refinement نشاط مستمر مش event رسمي إضافي. Review مش release gate؛ تقدر تسلّم Increment مستوفي DoD قبل نهاية Sprint. ماتحوّلش Daily لتقرير للمدير. المرجع: Scrum Guide 2020.

#Scrum و Kanban و Ready و DoneScrum, Kanban, Ready and Done

لو الفريق بيبدأ شغل أكتر من اللي بيخلصه، board لوحدها مش هتحل المشكلة. Kanban بيخلّي الـ workflow والسياسات واضحة ويضبط WIP، بحيث الشغل الجديد يتسحب لما فيه capacity.

Definition of Ready: اتفاق فريق اختياري، مش عنصر رسمي في Scrum. مثال: الهدف واضح، وأمثلة acceptance criteria موجودة، والـ dependencies معروفة. ماتخليهوش handoff gate يمنع التعلم.

Definition of Done: معيار جودة مشترك للـ Increment: tests مناسبة، وreview، وsecurity checks حسب المخاطر، وdocs وobservability وdeployment readiness. Acceptance criteria تخص سلوك item محدد؛ DoD يشمل جودة كل الشغل.

Cycle time من بداية الشغل لنهايته، وlead time ممكن يبدأ من الطلب حسب تعريف الفريق. Throughput عدد العناصر المكتملة في فترة، وwork item age عمر العنصر اللي لسه شغّال. Little's Law: متوسط WIP = معدل throughput × متوسط cycle time في نظام مستقر وبنفس الحدود والوحدات؛ مش وعد بموعد عنصر بعينه.

#Requirements و user stories و acceptance criteriaRequirements, user stories and acceptance criteria

قبل ما تختار endpoint أو database، اسأل مين محتاج إيه وليه. Functional requirement بيحدد سلوك زي إلغاء order. Quality attribute بيحدد جودة قابلة للقياس زي latency أو availability أو accessibility؛ كلمة «سريع» لوحدها مش requirement قابلة للتحقق.

User story بتركز على المستخدم والقيمة: «كعميل، عايز ألغي order قبل الشحن، علشان ماستناش منتج مش محتاجه». مش كل مهمة محتاجة القالب ده؛ spike أو platform upgrade ممكن يتكتبوا بشكل مباشر. اقسم الشغل لشرائح قيمة صغيرة، مش database Sprint وبعدها UI Sprint.

Story: Customer cancels an order before dispatch.
(1) Given a paid order that has not been dispatched
    When its owner cancels it
    Then the order is cancelled and one refund request is recorded
(2) Given an order already dispatched
    When its owner requests cancellation
    Then cancellation is rejected without a refund request
(3) Quality target for this example:
    p95 cancellation API latency below 300 ms at 100 requests/second
    measured in a production-like load test, excluding refund settlement

أكد الفهم بأمثلة مع product والـ QA والـ stakeholders؛ صيغة Given/When/Then مش شرط تستخدم أداة BDD. اكتشف التعارض بين المتطلبات قبل التنفيذ.

#Estimation: حجم وعدم يقين، مش وعدEstimation: size and uncertainty, not a promise

الناس محتاجة forecasts علشان تخطط، لكن رقم دقيق قبل فهم الشغل بيخبي uncertainty. Story points مقياس نسبي متفق عليه للحجم والتعقيد وعدم اليقين، مش ساعات. T-shirt sizes زي S وM وL مناسبة للتقسيم المبكر.

1. حدد baseline item الفريق فاهمه، وناقش assumptions والـ dependencies.
2. في planning poker كل واحد يختار لوحده، وتتكشف التقديرات مع بعض؛ اختلافها فرصة لفهم حاجة ناقصة.
3. قسّم الكبير، واعمل timeboxed spike لسؤال تقني محدد.
4. قدم range مع مستوى ثقة وافتراضات، وحدث forecast مع البيانات الفعلية.

ماتحوّلش points لساعات أو تقارن velocity بين فرق. Calendar time فيه انتظار وreview واعتمادات. استخدم throughput وcycle-time distributions وتاريخ فريقك لعمل forecast احتمالي، مع توضيح إن الماضي مش ضمان، خصوصاً لو طبيعة الشغل اتغيرت.

#Design docs و ADRs: اكتب ليه اخترتDesign documents and ADRs: record the reasoning

قرار تقني مؤثر محتاج review قبل ما يبقى آلاف السطور. Design doc بيشرح المشكلة والمتطلبات والبدائل والـ data flow والمخاطر وخطة rollout. ADR مختصر بيسجل قرار واحد وسياقه وتبعاته، علشان اللي ييجي بعدك مايعيدش نفس النقاش من غير دليل جديد.

Design doc
Problem and desired outcome:
Scope and non-goals:
Functional requirements and measurable quality attributes:
Options considered and trade-offs:
Proposed interfaces, data ownership and failure behavior:
Security, observability and operating cost:
Migration, rollout, rollback and validation:
Open questions, owner and review date:

ADR-007: Record invoice notifications in a transactional outbox
Status: Accepted
Context: A crash between database commit and send can lose a notification.
Decision: Commit the notification record with the invoice transaction.
Alternatives: Direct send; distributed transaction.
Consequences: Eventual delivery, duplicate handling and dispatcher operations.
Revisit when: Delivery requirements or transaction boundaries change.

ابدأ بأصغر doc يناسب حجم القرار. اربط القرار بالـ PR والـ diagrams والقياس، واذكر ليه البدائل اترفضت. لو القرار اتغير، ADR جديد يعمل supersede للقديم بدل مسح التاريخ. ماتكتبش implementation details مكررة من الكود ومش هتفضل متحدثة.

#Code review: feedback قابل للتنفيذCode review as actionable feedback

Review بيكشف مخاطر وبيشارك معرفة، لكنه مش بديل للـ automated checks أو design review. PR صغير بهدف واضح أسهل يتراجع كويس. الكاتب يشرح المشكلة والسلوك الجديد والـ validation والمخاطر، ويعمل self-review قبل الطلب.

1. افهم المتطلب والحدود الأول، وشوف التغيير من منظور المستخدم.
2. راجع correctness والـ failure paths والـ security والـ data compatibility والـ tests.
3. افصل blocker حقيقي عن suggestion وعن nit؛ استخدم formatter للقواعد الميكانيكية.
4. اكتب سبب قابل للفحص: «الـ retry هنا ممكن يكرر الدفع؛ نستخدم نفس idempotency key؟».
5. اتفقوا على الحل وسجّلوا القرار، وبعدين راجع الـ diff النهائي وشغّل الـ checks المطلوبة.

لو النقاش طال، مكالمة قصيرة وبعدها تلخيص مكتوب. ماتقيّمش الشخص من الكود، وماتفرضش taste على إنه correctness. الـ review latency جزء من flow؛ خصصوا وقت لتفريغ الطابور بدل بدء شغل جديد طول الوقت.

#Technical debt: خليه ظاهر وقابل للمفاضلةMake technical debt visible and actionable

Technical debt تكلفة مستقبلية سببها اختيار تصميم أو تنفيذ بيسرّع حاجة دلوقتي أو معرفة ناقصة. مش كل كود مش عاجبك يبقى debt. فيه debt متعمد بحساب، أو shortcut متهور، أو debt اكتشفناه بعد ما فهمنا المجال أكتر. أنواع عملية: تصميم، وtests، وdependencies، وoperability، وdocs.

Debt item: Duplicate invoice status mapping
Evidence: Three recent changes required edits in four places.
Impact: Inconsistent paid status and additional review effort.
Principal: Centralize mapping behind one adapter and characterize behavior.
Interest: Repeated changes and reconciliation incidents.
Owner: Invoicing team
Priority trigger: Before adding another invoice provider
Success measure: One mapping boundary and verified contract examples

اربط الدين بتكلفة تغيير أو خطر فعلي، وحط owner ووقت مراجعة. سدده جنب feature محتاجاه أو في شغل مخصص متفق عليه. قارن تكلفة الإصلاح بالعائد؛ rewrite كامل ممكن يضيف مخاطرة أكتر من الدين. ماينفعش وعد «هننضفه بعدين» من غير سجل وأولوية.

#Trunk-based development و feature flagsTrunk-based development and feature flags

الفروع الطويلة بتأخر integration وتكبّر conflicts. Trunk-based development بيعتمد على دمج تغييرات صغيرة بشكل متكرر في trunk، مع CI سريع وtrunk قابل للنشر. مش شرط كل الناس تعمل push مباشر؛ short-lived branches وPR review ينفعوا.

// (1) Evaluate a server-controlled flag for this request/cohort.
bool enabled = featureFlags.IsEnabled("new-invoice-view", userId);
var view = enabled
    ? await newInvoices.GetAsync(id, ct)
    : await currentInvoices.GetAsync(id, ct); // (2)

Deploy نقل النسخة للبيئة؛ release إتاحتها للمستخدمين. flag يفصل الاتنين ويسمح بcanary وkill switch. حط owner وتاريخ إزالة وdefault آمن، وماتستخدمش flag بديل لـ authorization. كثرة التركيبات بتزود عبء الاختبار؛ شيل الفروع القديمة بعد الاستقرار.

#DORA metrics: قياس النظام اللي بيسلّمDORA metrics measure the delivery system

عدد commits أو story points للفرد مش مقياس قيمة. DORA بتقيس سرعة وسلامة delivery على مستوى application أو service، وتساعدك تعرف الاختناق. الأربع مقاييس التاريخية لسه مشهورة في الأسئلة؛ النموذج الحالي خمسة، بإضافة deployment rework rate.

MTTR اسم قديم وأوسع وممكن يكون ملتبس؛ حدّد التعريف بدل خلط كل الأعطال مع deployment failures. اجمع metrics بنفس الحدود، وابص على distributions والاتجاه مع الوقت. ماتحوّلهاش لمسابقة فرق أو فرد، وماتطلبش deploys شكلية لزيادة الرقم. استخدمها مع reliability ورضا المستخدم ونتيجة المنتج. المرجع: تعريفات DORA الحالية.

#Incidents و stakeholders و docs عايشةIncidents, stakeholder alignment and living documentation

أثناء incident، الهدف الأول تقليل أثر المستخدم واستعادة الخدمة. حدد severity، وincident commander للتنسيق، وناس للتحقيق والتنفيذ، وcommunication owner. سجّل timeline وقرارات، وابعث updates منتظمة: الأثر المعروف، والتخفيف، ووقت التحديث الجاي؛ ماتخمنش ETA.

1. Detect وtriage: اتأكد من الأثر ووسّع المساعدة بدري.
2. Mitigate: rollback أو flag أو تقليل حمل لو آمن؛ استعادة الخدمة ممكن تسبق فهم السبب كله.
3. Recover وverify: افحص user journeys والداتا، مش health endpoint بس.
4. Postmortem: الأثر والـ timeline والعوامل المساهمة وفجوات الاكتشاف وما نجح، وبعدها إجراءات بowner وموعد وقياس.

Blameless معناه نفهم ليه القرار كان منطقي بالمعلومات المتاحة وقتها، ونصلّح ظروف النظام؛ مش معناه مفيش مسؤولية أو متابعة. «مهندس ضغط الزر الغلط» مش تحليل كافي.

مع product والـ stakeholders: اسأل عن النتيجة المطلوبة، واعرض اختيارات بتكلفة ومخاطرة، واتفق على scope وquality وحدود قرار واضحة. لو deadline ثابت، تفاوض على scope وrollout؛ ماتخبيش الخطر لحد آخر يوم.

Docs تفضل مفيدة لما ليها owner وقارئ وسؤال بتجاوب عليه. احفظ runbooks والـ ADRs مع الكود، وحدّثها في نفس PR اللي غيّر السلوك. ولّد API reference من العقد، واختبر snippets والروابط في CI، وجرّب runbook دورياً. ماتكتبش نفس source of truth في ثلاث أماكن.