المطوّر الحكيم لا «يبدأ بالبرمجة ويتمنى». هو يمرّر المشروع الجديد عبر العصف الذهني، نقاش الفريق، النماذج الأولية، المخططات، المقترحات، ADR وMR/PR وGitOps — مع Review Bots تولّد تعليقات PR تلقائيًا حتى يصرف البشر وقتهم فيما يهم. هذا هو دليل مستوى الإنتاج. يمكن لـ FDE أن ينصب النظام؛ وشهادة Claude Architect Certification تستحق السعي إن أردت تصميمه والدفاع عنه.
1. ماذا يعني «حكيم» في مشروع جديد
الحكمة ليست مزيدًا من الاجتماعات. إنها تعلّم رخيص مبكرًا وجعل الأخطاء المكلفة متأخرة نادرة. التسلسل أدناه مرتّب بحيث يقلّل كل خطوة نصف قطر انفجار التالية:
Brainstorm → Discuss → Prototype → Diagram → Propose → ADR
→ Implement in small slices → MR/PR + Review Bot → Merge
→ GitOps promote (dev → staging → prod) → Observe → Iterate
تخطَّ الخطوات فقط بقصد (مثل إصلاح إعداد بسطر واحد). لا تتخطَّ أبدًا Review Bot + CI على أي شيء يمكن أن يصل إلى الإنتاج.
2. العصف الذهني (منفردًا أولًا، ثم منظمًا)
قبل أن تطلب وقت أحد، اقضِ 30–90 دقيقة وحدك:
- النتيجة: ما التغيير للمستخدم/العمل الذي يجب أن يكون صحيحًا عندما ننتهي؟
- القيود: الوقت، الميزانية، الامتثال، المنصات القائمة، مهارات الفريق.
- غير الأهداف: ما لن نبنيه في v1 (يحمي النطاق).
- المخاطر: البيانات، الأمن، الأداء، الارتباط بمورّد، العبء التشغيلي.
- مقاييس النجاح: زمن الاستجابة، معدل الخطأ، التبنّي، التكلفة — اختر اثنين مهمّين.
سجّل ذلك في ملاحظة قصيرة (Notion/Confluence/markdown في المستودع تحت docs/ideas/). العصف بلا أثر مكتوب مجرد حديث يتبخّر.
3. نقاشات مع الزملاء
ادعُ أصغر دائرة مفيدة: زميلًا سينفّذ معك، ومن يملك النظام المجاور، و(عند الحاجة) الأمن أو SRE. قواعد تُبقي الأمر حكيمًا:
- حدّ زمني (25–45 دقيقة). انهِ بقرارات أو أسئلة مفتوحة — لا vibes.
- الخلاف على الخيارات لا الأشخاص. افرض «الخيار A مقابل B مقابل التأجيل.»
- عيّن كاتب محضر. تصبح الملاحظة بذرة المقترح.
- لا فيتو صامت. إن شعر أحد بعدم الارتياح، اكتب القلق كخطر في الـ ADR لاحقًا.
العمل غير المتزامن يعمل أيضًا: خيط تعليقات RFC قصير غالبًا أفضل من اجتماع — لكن يجب أن يغلق أحد الحلقة.
4. النماذج الأولية (spikes بتاريخ انتهاء)
اصنع نموذجًا أوليًا عندما يكون عدم اليقين عاليًا: واجهة API جديدة، خدمة سحابية غير مألوفة، سؤال أداء، أو سلوك AI/وكيل. قواعد حكيمة:
- سمِّه spike في التذكرة؛ ضع توقفًا في التقويم (عادة 1–3 أيام).
- أبقِ الكود على فرع قابل للرمي أو مجلد
spikes/؛ لا تلمع. - اكتب ما تعلمته في 10 نقاط — خاصة ما فشل.
- قرّر: ترقية (إعادة هيكلة للمنتج)، إعادة كتابة، أو التخلي.
النماذج التي تصبح إنتاجًا بهدوء بلا ADR هي كيف ترث الفرق بنية عرضية.
5. المخططات (ما يكفي للنقاش)
لا تحتاج رواية UML. فضّل ثلاث مسودات تناسب كل منها شاشة واحدة:
| مخطط | يجيب |
|---|---|
| السياق (C4 L1) | من يتحدث مع ماذا؟ حدود الثقة؟ |
| التسلسل | المسار السعيد + مسار فشل واحد |
| النشر | أين يعمل؛ كيف تتدفق الإعدادات والأسرار |
خزّن Mermaid أو الصور بجانب المقترح (docs/architecture/). حدّث المخططات عند تغيّر ADR — الصور القديمة أسوأ من لا شيء.
6. المقترحات (RFC خفيف)
مقترح جيد من صفحة إلى ثلاث:
- المشكلة ولماذا الآن
- الخيارات المدروسة (اثنان على الأقل)
- التوصية ولماذا
- الأثر: الأمن، التكلفة، العمليات، الترحيل
- الطرح والتراجع
- أسئلة مفتوحة
اطلب مراجعة بموعد نهائي واضح. عند الموافقة (أو مع تعديلات)، حوّل القرار إلى ADR — لا تترك «مصدر الحقيقة» في الدردشة.
7. ADR — Architecture Decision Records
ADR سجل قصير غير قابل للتغيير بالعرف لقرار. القالب:
# ADR-00XX: Title Status: Proposed | Accepted | Superseded by ADR-00YY Date: YYYY-MM-DD Deciders: @alice @bob ## Context What forces are in play? ## Decision What we will do. ## Consequences Positive, negative, and follow-ups. ## Alternatives considered Option A — why not Option B — why not
أبقِ ADR في git (docs/adr/). اربطها من PRs. استبدل بدل إعادة كتابة التاريخ — ذاتك المستقبلية تحتاج الأثر.
8. MR وPR — وحدة التسليم
MR (Merge Request، GitLab) وPR (Pull Request، GitHub/Bitbucket) نفس الفكرة: مجموعة تغييرات قابلة للمراجعة. عادات حكيمة:
- صغير: يفضّل <400 سطر diff ذي معنى؛ اقسم شرائح عمودية.
- نية واحدة: ميزة أو إصلاح أو chore — لا «misc.»
- الوصف: لماذا، كيف تختبر، لقطات/سجلات، المخاطر، التراجع.
- روابط: تذكرة + ADR + مخطط تصميم.
- Draft أولًا عندما تريد تغذية راجعة مبكرة دون الإيحاء بـ «جاهز للدمج.»
- لا تفرض الدمج أبدًا حول CI أحمر أو نتائج bot عالية الخطورة دون استثناء مكتوب.
مثال قائمة تحقق لجسم PR
## Summary - … ## Test plan - [ ] Unit tests - [ ] Manual path … - [ ] Feature flag / config … ## Risk & rollback - Risk: … - Rollback: revert this PR / GitOps revert commit … ## References - ADR-00XX - Ticket ABC-123
9. استخدام Review Bot — تعليقات PR مولَّدة تلقائيًا
Review Bot مراجع آلي ينشر تعليقات مضمّنة وملخصات على كل MR/PR. لا يستبدل البشر؛ يقدّم الممل والخطير مبكرًا.
9.1 ما يجب أن يعلّق عليه البوت
- الأمن: حقن، فجوات تفويض، تسرب أسرار، افتراضيات غير آمنة
- الصحة: مسارات null، سباقات، ترحيلات مكسورة
- الاختبارات: تغطية ناقصة على فروع جديدة، إساءة snapshots
- API/العقد: تغييرات كاسرة بلا رفع إصدار
- العمليات: مهلات ناقصة، بلا idempotency، إعادة محاولات بلا حد
- الأسلوب فقط إن أفلت من formatter/linter (تجنّب الضوضاء)
9.2 كيف يبسّط حياة المطوّر
- يفتح المؤلف PR → يعمل البوت خلال ثوانٍ إلى دقائق.
- يصلح المؤلف أو يرد على خيوط البوت قبل طلب بشر.
- يقرأ المراجع البشري ملخص البوت ويركّز على التصميم ومخاطر المنتج.
- جولات «nits» أقل؛ دمج أسرع؛ حوادث ليلة الجمعة أقل من فخاخ فائتة.
9.3 خيارات إعداد نموذجية
| النهج | ملاحظات |
|---|---|
| SaaS Review Bot (مثل CodeRabbit، bots البائعين) | تفعيل سريع؛ اضبط الشدة ومرشحات المسار |
| Cursor Bugbot / مراجعة مرتبطة بـ IDE | قوي على فروقات PR في فرق تتمحور حول Cursor |
| GitHub Action مخصص + Claude / LLM | تحكم كامل؛ يحتاج prompt + سياسة + حدود تكلفة |
| خط أنابيب طبقي (lint → SAST → LLM) | أفضل وضع إنتاج — انظر دليل خط أنابيب مراجعة الكود بالذكاء الاصطناعي |
9.4 سياسة تبقي البوت مفيدًا
- تسميات الشدة: blocker / should-fix / nit — الـ nits لا يجب أن تمنع الدمج.
- تجاهل المسارات المولَّدة (
vendor/، ضوضاء lockfiles، protobuf dumps). - اطلب موافقة بشرية للمسارات الحساسة أمنيًا (
auth/،infra/، IAM). - سجّل الإيجابيات الكاذبة؛ أعد تغذيتها في قواعد التجاهل شهريًا.
- لا تجعل البوت المراجع الوحيد لخدمات حرجة للإنتاج.
9.5 مخطط GitHub Action أدنى
# .github/workflows/review-bot.yml
name: review-bot
on:
pull_request:
types: [opened, synchronize, reopened]
jobs:
review:
runs-on: ubuntu-latest
permissions:
contents: read
pull-requests: write
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0
- name: Run Review Bot
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
LLM_API_KEY: ${{ secrets.LLM_API_KEY }}
run: |
# Fetch diff, call your review CLI, post review comments via gh api
./scripts/review-bot.sh
نفّذ review-bot.sh لـ: حساب فرق PR، استدعاء نموذجك بـ system prompt صارم (الأمن + الصحة أولًا)، ونشر تعليقات عبر واجهة GitHub/GitLab. حدّ tokens وتخطَّ drafts إن كانت التكلفة مصدر قلق.
10. أفضل ممارسات GitOps لجودة مستوى الإنتاج
GitOps يعني: الحالة المرغوبة تعيش في git؛ مُوفِّق (Argo CD، Flux، إلخ) يجعل العنقود يطابق؛ الترقية دمج؛ التراجع revert.
- افصل كود التطبيق وإعداد البيئة (أو مجلدات واضحة:
apps/مقابلenvs/dev|staging|prod). - لا kubectl apply للإنتاج كمسار سعيد — كسر زجاج فقط، مع تدقيق.
- تسليم تدريجي: مزامنة تلقائية لـ dev؛ مزامنة يدوية أو ببوابة لـ prod.
- Digests للصور بدل وسوم قابلة للتغيير في بيانات الإنتاج.
- Policy as code: OPA/Kyverno للصلاحيات والمستودعات وحدود الموارد.
- التزامات موقّعة / provenance حيث يتطلبه نموذج التهديد لديك.
- راقب بعد المزامنة: فحوصات صحة، ميزانيات أخطاء، خطافات تراجع تلقائي عند الجاهزية.
جودة الكود ليست فقط «دوال نظيفة.» إنها أيضًا كيف يدخل التغيير الإنتاج. GitOps يجعل ذلك المسار قابلاً للمراجعة وعكسيًا وقابلًا للتكرار.
11. بوابات جودة شاملة (مُحسَّنة للإنتاج)
Local: pre-commit (fmt, lint, secrets) + unit tests PR open: CI (build, test, SAST) + Review Bot comments PR merge: human approve + branch protection + required checks Main: build immutable artifact (image digest) GitOps: update env repo / overlay → sync → verify Prod: SLOs + alerts + runbook linked from ADR/PR
12. دور FDE — من ينصب هذا النظام
Forward Deployed Engineer مثالي لتثبيت نظام المطوّر الحكيم داخل فريق حقيقي:
- قوالب المستودع:
docs/adr/، قالب PR، CODEOWNERS، حماية الفروع - Review Bot + أسرار + ضوابط تكلفة
- فحوصات CI مطلوبة وحمايات البيئة
- تطبيقات GitOps (dev/staging/prod) ووثائق الترقية
- تدريب أسبوعين: أول ADR، أول PR مضبوط بالبوت، أول تمرين تراجع GitOps
تقويم إرشادي لتمكين يقوده FDE على مستودع منتج واحد: 1–2 أسبوع للهيكل وسياسة البوت؛ +1–2 أسبوع لمسار ترقية GitOps وتراجع تجريبي. تغيير الثقافة أطول — قِس زمن الدمج والعيوب الهاربة، لا تثبيت الأدوات.
13. Claude Architect Certification — تستحق السعي
إن صمّمت أنظمة يشارك فيها بشر ووكلاء ذكاء اصطناعي في كتابة الكود، فـClaude Architect Certification تستحق السعي. تشير إلى أنك تستطيع:
- هندسة تسليم بمساعدة الذكاء الاصطناعي دون اعتبار النموذج معصومًا
- تحديد سياسات مراجعة وحواجز وتقييم لسير عمل وكيل
- إيصال المقايضات (زمن الاستجابة، التكلفة، الخصوصية، الدقة) لأصحاب المصلحة
- تدريب الفرق على ADR وانضباط PR وبوابات الإنتاج بجانب أدوات الذكاء الاصطناعي
اربط الشهادة بتسليم حقيقي: انصب Review Bot، اكتب ثلاثة ADR، ونفّذ تمرين تراجع GitOps. الورق بلا ممارسة لا يجعلك حكيمًا؛ الممارسة ولغة مشتركة تفعلان.
14. أنماط مضادة (كيف يبدو غير الحكيم)
- PR عملاق مع «WIP please approve ASAP»
- بنية تُقرَّر في Slack فقط، لا في ADR
- نموذج أولي يُدمَج كإنتاج بلا اختبارات
- تعطيل Review Bot لأنه «يزعج»
- إصلاح ساخن للإنتاج خارج GitOps بلا خطة تراجع
- بشر يكررون nits المُنسِّق التي التقطها البوت أصلًا
15. قائمة بدء قابلة للنسخ لمشروع جديد
- أنشئ
docs/ideas/وdocs/architecture/وdocs/adr/ - أضف قالب PR/MR + CODEOWNERS
- فعّل pre-commit + فحوصات CI مطلوبة
- ثبّت Review Bot؛ اضبط مرشحات المسار والشدات
- اكتب ADR-0001: «We use GitOps for deploy»
- عرّف البيئات وقواعد الترقية
- جدول يوم لعبة تراجع لـ 30 دقيقة
- احجز وقت FDE لتدريب الشهر الأول؛ فكّر بـ Claude Architect Certification للقادة
16. ختام
يعامل المطوّر الحكيم المشروع الجديد كتسلسل من آثار التعلّم — ملاحظات ومخططات ومقترحات وADR — ثم يسلّم عبر MR/PR صغيرة يراقبها Review Bot ويرقّيها GitOps. هكذا تُحسَّن جودة الكود لمستوى الإنتاج دون حرق الفريق في nits لا تنتهي. دع FDE يضع القضبان؛ دع المعماريين المعتمدين يُبقون النظام صادقًا بينما يسرّع الذكاء الاصطناعي سرعة كتابة الكود.
نُشر بواسطة Workstation.
