لا يبدأ المطور الحكيم مشروعًا جديدًا عن طريق فتح طلب سحب ضخم. إنهم يتحركون من خلال تبادل الأفكار، ومناقشة زملاء الفريق، والنماذج الأولية، والرسوم البيانية، والمقترحات، وADRs، وMRs/PRs، وGitOps - مع روبوت مراجعة عند كل تغيير - وعندما يتطلب الحجم ذلك، فإن البنية متعددة الوكلاء لـ Workstation لتجميع فريق تطوير رائع يشحن العمل على مستوى الإنتاج بسرعة.
1. ماذا تعني كلمة "حكيم" في مشروع جديد
الحكمة رخيصة التعلم مبكراً، والأخطاء باهظة الثمن نادرة متأخرة. تم ترتيب التسلسل أدناه بحيث تعمل كل خطوة على تقليص نصف قطر الانفجار للخطوة التالية:
Brainstorm → Discuss with workmates → Prototype → Diagram → Propose → ADR
→ Implement in small slices → MR/PR + Review Bot → Merge
→ GitOps promote (dev → staging → prod) → Observe → Iterate
Optional scale-up:
Workstation multi-agent crew (Planner / Builders / Reviewers / Ops)
with human gates on risky actions
2. العصف الذهني
قبل أن تقضي وقت الآخرين، اقضِ ما بين 30 إلى 90 دقيقة بمفردك:
- حصيلة - ما الذي يجب أن يكون صحيحًا بالنسبة للعمل عندما ننتهي؟
- قيود - الوقت، والامتثال، والمنصات، والمهارات، والميزانية.
- غير الأهداف - ما لن يتضمنه الإصدار 1 صراحةً.
- المخاطر - البيانات، الأمان، الأداء، القفل، تحميل العمليات.
- مقاييس النجاح - اختر اثنين (على سبيل المثال، زمن الوصول + الاعتماد، أو التكلفة + معدل الخطأ).
اكتبها تحت docs/ideas/. العواصف الذهنية غير المكتوبة تتبخر.
3. المناقشات مع زملاء العمل
قم بدعوة أصغر دائرة مفيدة: منفذ نظير، ومالك نظام مجاور، والأمن/SRE عندما تستدعي المخاطر ذلك.
- الإطار الزمني (25-45 دقيقة). اختتم بالقرارات أو الأسئلة المفتوحة.
- خيارات القوة: أ مقابل ب مقابل التأجيل - ليست اتفاقية غامضة.
- تعيين كاتب. المذكرة بذور الاقتراح.
- تعامل مع الانزعاج باعتباره مخاطر على التفاعلات الدوائية البديلة - لا يوجد حق النقض الصامت.
تعد طلبات RFC غير المتزامنة جيدة إذا قام شخص ما بإغلاق الحلقة.
4. النماذج الأولية
ارتفاع عندما يكون عدم اليقين مرتفعا. القواعد الحكيمة:
- قم بتسميتها على شكل ارتفاع. اضبط توقفًا تقويميًا (من 1 إلى 3 أيام نموذجيًا).
- يبقيه على فرع رمي أو
spikes/- لا تلميع. - اكتب عشر نقاط عما تعلمته (وخاصة حالات الفشل).
- قرر: قم بالترويج، أو إعادة الكتابة، أو التخلي - لا "تصبح أبدًا حثًا بهدوء".
5. المخططات
عادةً ما تكون ثلاثة رسومات تخطيطية كافية:
| رسم بياني | الإجابات |
|---|---|
| السياق (C4 L1) | من يتحدث إلى ماذا؟ حدود الثقة؟ |
| تسلسل | طريق سعيد + طريق فشل واحد |
| النشر | حيث يتم تشغيله؛ تدفق التكوين والأسرار |
قم بتخزين Mermaid أو SVG بجوار الاقتراح. قم بالتحديث عند تغيير ADRs.
6. المقترحات
اجعل طلب التعليقات قصيرًا (1-3 صفحات): المشكلة، والخيارات (صفحتان على الأقل)، والتوصية، والتأثير (الأمان/التكلفة/العمليات)، والطرح والتراجع، والأسئلة المفتوحة. عند الموافقة، قم بتحويل القرار إلى ADR.
7. ADR — سجلات قرارات الهندسة المعمارية
# ADR-00XX: Title Status: Proposed | Accepted | Superseded by ADR-00YY Date: YYYY-MM-DD Deciders: @alice @bob ## Context ## Decision ## Consequences ## Alternatives considered
احتفظ بـ ADRs في git (docs/adr/). ربطهم من العلاقات العامة. استبدال التاريخ بدلاً من إعادة كتابته.
8. MR وPR – وحدة التسليم
السيد (طلب الدمج) و العلاقات العامة (طلب السحب) هما نفس الفكرة: مجموعة تغيير قابلة للمراجعة.
- صغير (يفضل أقل من 400 سطر من الفروق ذات المغزى)؛ نية واحدة لكل تغيير.
- الوصف: لماذا، كيفية الاختبار، المخاطر، التراجع.
- الروابط: تذكرة + ADR + رسم بياني.
- قم بالصياغة مبكرًا للحصول على التعليقات؛ لا تقم أبدًا بالدمج القسري حول CI الأحمر أو نتائج الروبوت عالية الخطورة دون استثناء مكتوب.
## Summary ## Test plan - [ ] Unit / contract tests - [ ] Manual path … ## Risk & rollback ## References (ADR, ticket)
9. روبوت المراجعة — تعليقات تلقائية تحمي الإنتاج
روبوت المراجعة هو مراجع أول آلي. لا يحل محل البشر. فهو يحمّل الأشياء المملة والخطرة في المقدمة، لذا يقضي المطورون وقتًا في التصميم ومخاطر المنتج.
9.1 ما ينبغي التعليق عليه
- الأمان: الحقن، فجوات المصادقة، التسرب السري، الإعدادات الافتراضية غير الآمنة
- الصحة: المسارات الفارغة، والأجناس، والهجرات المكسورة
- الاختبارات: التغطية مفقودة على الفروع الجديدة
- واجهة برمجة التطبيقات/العقود: كسر التغييرات دون زيادة في الإصدار
- العمليات: المهلات المفقودة، وإعادة المحاولة غير المحدودة، والكتابة غير العاجزة
9.2 كيف تبسط حياة المطور
- يفتح المؤلف تعليقات PR → bot في دقائق.
- يقوم المؤلف بإصلاحات أو ردود قبل أن يسأل البشر.
- يقرأ الإنسان ملخص الروبوت + ويركز على الهندسة المعمارية ونصف قطر الانفجار.
- عدد أقل من جولات الصئبان؛ عدد أقل من البنادق التي نجت في الإنتاج.
9.3 السياسة التي تجعل الروبوت مفيدًا
- الخطورة: مانع / يجب الإصلاح / nit - يجب ألا يمنع القمل الدمج.
- تجاهل المسارات التي تم إنشاؤها؛ ضبط الإيجابيات الكاذبة شهريا.
- تتطلب موافقة الإنسان على
auth/,infra/و IAM ومسارات المال. - لا تدع الروبوت يكون المراجع الوحيد لخدمات الإنتاج الحرجة.
روبوتات Wire SaaS (مثل CodeRabbit)، أو Cursor Bugbot، أو Action + LLM المخصص عبر فرق العلاقات العامة. طبقة الوبر → SAST → LLM لأقوى وضعية.
10. أفضل ممارسات GitOps لجودة الإنتاج
الحالة المرغوبة تعيش في git. يقوم المُصالح (Argo CD، Flux، وما إلى ذلك) بمطابقة المجموعة. الترويج عبارة عن دمج؛ التراجع هو العودة.
- رمز التطبيق المنفصل وتكوين env (أو مسح
envs/dev|staging|prodتراكبات). - لا مخصص
kubectl applyللحث على أنه المسار السعيد - كسر الزجاج فقط، ومراجعته. - التسليم التدريجي: مزامنة تلقائية لبيئات أقل؛ مزامنة مسورة لهمز.
- يتم هضم الصور عبر العلامات القابلة للتغيير في المنتج.
- السياسة كرمز (OPA/Kyverno) للامتيازات والسجلات.
- المراقبة بعد المزامنة؛ ممارسة العودة.
لا تقتصر جودة التعليمات البرمجية على الوظائف النظيفة فحسب، بل إنها كذلك أيضًا كيف يدخل التغيير إلى الإنتاج.
11. بنية محطات العمل متعددة الوكلاء — بناء فرق تطوير رائعة
لا يزال المطور الحكيم يحتاج إلى النفوذ. تتيح لك البنية متعددة الوكلاء لمحطة العمل (حزم محطات عمل Agentic AI وOpenClaw for Business حيث تحتاج إلى أطقم وكلاء مجسدة أو متخصصة) بناء فريق التطوير تلقائيًا حول ملخص عمل - وليس مخططًا تنظيميًا ثابتًا.
11.1 حلقة التكوين
- مختصر - نتائج أصحاب المصلحة، والقيود، واتفاقيات مستوى الخدمة.
- يؤلف - تحديد الأدوار حسب المهارات (المخطط، المنشئ، المراجع، العمليات، الامتثال).
- بوتستراب - وقت تشغيل الوكيل + أدوات MCP + الذاكرة + مسار التدقيق.
- ينفذ — يسحب الوكلاء العمل، وينفذونه وفقًا للمواصفات/AC، ويراجعون كل خطوة بشكل مصغر.
- المراجعة حتى التنظيف - روبوت المراجعة + وكلاء المراجعين + البوابات البشرية.
- سفينة — يقوم GitOps بالترويج للبيئة المهمة.
11.2 خريطة الدور (الإنسان + الوكيل)
| دور | الوكيل يفعل | لا يزال الإنسان يمتلك |
|---|---|---|
| مخطط | الملاحم والقصص AC من المواصفات | الأولوية وتخفيضات النطاق |
| بناة | التنفيذ الموازي والاختبارات | حكم المجال على الحواف الصلبة |
| المراجعين | الامتثال للمواصفات، ومراجعة فرز الروبوتات | الهندسة المعمارية وتوقيع المنتج |
| العمليات | مزامنة GitOps، ومراقبة SLO، واستعادة المسودة | بدء التشغيل المباشر وأمر الحادث |
| بوابة هيتل | تصعيد عمليات الكتابة/الإنفاق المحفوفة بالمخاطر | الموافقة أو الرفض |
11.3 لماذا يؤدي ذلك إلى بناء فرق رائعة؟
- التخصص — لكل وكيل وظيفة واحدة؛ ترتفع الجودة عندما لا يتم طمس الأدوار.
- الإنتاجية دون فوضى - منشئون متوازيون خلف روبوت واحد للمواصفات والمراجعة.
- الذاكرة المشتركة للقرارات — ADRs + Spec + PR History تصبح ذاكرة الفريق طويلة المدى.
- نفس البوابات مثل البشر — CI، وReview Bot، وCODEOWNERS، وGitOps — لا يتجاوز الوكلاء انضباط الإنتاج.
- سرعة الأعمال - ساعات لتكوين طاقم قادر بدلاً من أسابيع لتوظيف كل ارتفاع.
11.4 كيف يتم توصيله إلى المسار الحكيم
العصف الذهني والمناقشة لا يزال يحدث مع البشر. النماذج الأولية والرسوم البيانية لا تزال تحدث. يتسارع الطاقم متعدد الوكلاء صياغة المقترحات، وسقالات ADR، وشرائح التنفيذ، ومراجعة فرز الروبوتات، والترويج لـ GitOps - بينما يحتفظ البشر بالحكم على النتائج والمخاطر. هذا هو نموذج محطة العمل: محطات عمل وكيلة وحزم OpenClaw مهيأة لسير العمل لديك، وليس نافذة دردشة تتظاهر بأنها فريق.
12. بوابات الجودة الشاملة
Local: pre-commit (fmt, lint, secrets) + unit tests PR open: CI + Review Bot comments PR merge: human approve + branch protection + required checks Main: immutable artifact (image digest) GitOps: update env overlay → sync → verify Agents: Planner/Builder/Reviewer/Ops stay inside the same gates Prod: SLOs + alerts + runbook linked from ADR/PR
13. قائمة مرجعية للمبتدئين
- يخلق
docs/ideas/,docs/architecture/,docs/adr/ - إضافة قالب PR/MR + CODEOWNERS + حماية الفرع
- تمكين الالتزام المسبق + عمليات التحقق المطلوبة من CI
- تثبيت روبوت المراجعة؛ ضبط مرشحات المسار وشدته
- اكتب ADR-0001: "نحن نستخدم GitOps للنشر"
- حدد قواعد الترويج للبيئة ويوم لعبة التراجع
- في حالة توسيع نطاق التسليم: الوقوف في محطة العمل بطاقم متعدد الوكلاء (المخطط/المنشئون/المراجعون/العمليات) مع بوابات HITL
14. الأنماط المضادة
- العلاقات العامة العملاقة "WIP يرجى الموافقة".
- الهندسة المعمارية فقط في Slack - وليس في ADR أبدًا
- تم دمج النموذج الأولي كمنتج بدون أي اختبارات
- تعطيل روبوت المراجعة لأنه يتذمر
- الوكلاء لديهم حق الوصول للكتابة وليس لديهم بوابة بشرية
- إصلاح عاجل للحث خارج GitOps بدون خطة إرجاع
15. الإغلاق
يتعامل المطور الحكيم مع المشروع الجديد على أنه سلسلة من أدوات التعلم - الملاحظات والرسوم البيانية والمقترحات والتفاعلات التفاعلية - ثم يسلمها من خلال MRs/PRs الصغيرة التي يشاهدها روبوت المراجعة ويتم الترويج لها بواسطة GitOps. تعمل البنية متعددة الوكلاء لمحطة العمل على توسيع تلك الحكمة إلى فريق تطوير كامل: وكلاء متخصصون، ومواصفات مشتركة، والحكم البشري حيثما يكون ذلك مهمًا، وبوابات على مستوى الإنتاج على كل مسار للعيش. هذه هي الطريقة التي تظل بها جودة التعليمات البرمجية محسنة للإنتاج بينما لا يزال العمل يتحرك بسرعة.
نشرت من قبل محطة العمل.
