كيف أنظّم عمل فريق الواجهات بين مشاريع مختلفة؟
الموضوعات: القيادة · الفرق · الواجهات
أقود فريق واجهات من ثمانية مهندسين ضمن بيئة فيها نحو 30 مستودعًا. بعضها يستخدم React، وبعضها Next.js أو TanStack Start أو Astro. وحتى داخل التقنية نفسها، تختلف الإصدارات وطريقة جلب البيانات وبناء المشروع.
كان من السهل أن أكتب خطة لتوحيد كل شيء. وكان من السهل أيضًا أن تستهلك الخطة شهورًا من دون أن تحل المشكلة التي يواجهها الفريق يوميًا.
ما يعطّل المهندس فعلًا هو أن يفتح مشروعًا ولا يعرف كيف يشغّله، أو أين يجد تعريفات الأنواع، أو ما الفحوصات المطلوبة قبل الدمج، أو من يراجع التغيير. لذلك بدأت بتوضيح هذه الخطوات قبل التفكير في توحيد المكتبات.
أعرف سبب الاختلاف قبل أن أزيله
أول ما أحتاجه هو خريطة بسيطة للمستودعات النشطة: التقنية، وإصدار بيئة التشغيل، وأوامر التطوير والاختبار، وطريقة النشر، والمالك، ومدى تكرار التغيير.
الخريطة تفرق بين نوعين من الاختلاف. الأول مقصود: مشروع يحتاج إلى طريقة بناء أو بيئة معينة لسبب موجود حتى الآن. والثاني مجرد أثر قديم: إعداد بقي لأن أحدًا لم يحتج إلى تغييره.
لا أتعامل مع النوعين بالطريقة نفسها. الاختلاف المقصود أوثقه وأتركه. أما الاختلاف الذي يسبب أعطالًا أو يبطئ كل مساهمة جديدة، فأضعه ضمن عمل التحسين.
المستودع النشط يستحق وقتًا أكبر من مستودع مستقر لا يتغير إلا نادرًا. ترقية الأخير قد تجعل قائمة الإصدارات أجمل، لكنها لا تجعل الفريق أسرع. أفضّل إنفاق الوقت حيث سيظهر أثره في العمل التالي.
أوحّد خطوات بدء العمل
يمكن أن تختلف بنية الكود بين المشاريع، وتبقى خطوات بدء العمل معروفة. لذلك بدأنا بتوحيد الأوامر:
- أمر واضح لتشغيل المشروع؛
- أمر للفحص والتنسيق؛
- أمر للاختبارات؛
- وطريقة معروفة لبناء نسخة الإنتاج.
عندما ينتقل مهندس إلى مستودع جديد، يجب أن يعرف أين يجد أمر التشغيل في package.json. قد تكون الأدوات مختلفة في الداخل، لكن نقطة البداية معروفة.
أطبق الفكرة نفسها على README. لا أريد وثيقة طويلة تصف تاريخ المشروع. أريد أن أعرف المتطلبات، وطريقة التشغيل، والمتغيرات التي يحتاجها محليًا، ومن يملك المشروع، وما الذي يجب اختباره قبل الدمج.
هذه التفاصيل تبدو صغيرة. لكنها تتكرر عبر عشرات المستودعات، ولذلك يعود وقتها إلى الفريق كل أسبوع.
أضع معيارًا واحدًا للمراجعة
لا يمكنني فرض الأسلوب نفسه على Astro قديم وتطبيق Next.js جديد. ويمكنني، مع ذلك، أن أطلب المستوى نفسه من التفكير.
في المراجعة أهتم بهذه الأسئلة:
- هل تغير سلوك المستخدم المقصود فقط؟
- ماذا يحدث عند فشل الطلب أو وصول بيانات ناقصة؟
- هل تعمل الشاشة بلوحة المفاتيح؟
- هل أُخذ حجم البيانات في الحسبان؟
- هل يمكن التراجع عن التغيير بأمان؟
هذه الأسئلة تنتقل بين المستودعات. أما النقاش حول تفضيل صياغة صغيرة في React، فأتركه لأداة التنسيق أو لاتفاق المشروع نفسه.
وأطلب من المراجع أن يشرح السبب. عبارة «نحن لا نكتبها هكذا» لا تساعد مهندسًا يعمل في أكثر من stack. تعليق مثل «هذا الطلب قد يعيد بيانات أقدم بعد تغيير المرشّح» يشرح الخطر، ويظل مفيدًا مهما تغيرت المكتبة.
لا أحتكر المراجعة
في البداية قد يكون قائد الفريق هو الشخص الذي يعرف أغلب السياق. إذا مر كل pull request عبره، يتحول سريعًا إلى طابور انتظار. لذلك أوزّع مسؤولية المراجعة على الفريق.
لكل مستودع نشط مسؤول أساسي، ومعه شخص آخر يستطيع مراجعته وإطلاقه. التغيير الصغير والقابل للعكس لا يحتاج إلى موافقتي. أما القرار الذي يغير عقد بيانات أو بنية مشتركة، فنكتبه باختصار قبل تنفيذ جزء كبير منه.
أراجع ما يحتاج إلى رؤية أوسع: تغيير يمتد بين مستودعات، أو قرار سيصبح مرجعًا لمشاريع جديدة، أو مسار عالي المخاطر. وأترك بقية العمل للفريق مع معيار واضح.
هذا لا يقلل الجودة. العكس هو الصحيح؛ لأن المعرفة لا تبقى عند شخص واحد، ولأن المهندسين يتعلمون الحكم على التغيير لا انتظار حكم جاهز.
أشجّع تبادل المراجعات بين المشاريع
في المستودع الموحّد (monorepo)، يسهل على المهندسين الاطلاع على كود المشاريع المجاورة. داخل polyrepo قد يعمل شخص شهورًا في جزء واحد ولا يرى ما تغير حوله. لذلك أشجع المراجعات خارج نطاق المسؤوليات المعتاد، خصوصًا عندما يظهر نمط يمكن أن يفيد مشروعًا آخر.
لا أوزع المراجعات عشوائيًا. أختار مراجعة يستطيع منها المهندس تعلّم جزء مجاور لعمله، أو يستطيع أن يضيف إليها خبرة لا يملكها صاحب التغيير. أحيانًا تكون مراجعة واحدة كهذه أنفع من جلسة طويلة لشرح المعمارية.
كما أسجل القرارات التي تتكرر. إذا شرحنا سببًا معماريًا ثلاث مرات في pull requests مختلفة، فمكانه لم يعد تعليقًا؛ يصبح ملاحظة قصيرة يستطيع الفريق الرجوع إليها، وتستطيع أدوات البرمجة بالذكاء الاصطناعي قراءتها أيضًا.
أضع أساسًا واضحًا للمشاريع الجديدة
لا أعيد كتابة كل قديم. لكن الأعمال الجديدة تحتاج إلى نقطة بداية واضحة: تقنيات معتمدة للمشاريع الجديدة، وإعداد معروف، وقواعد وصول للبيانات، وطريقة اختبار ونشر. يمكن الخروج عن هذا المسار، بشرط أن يوجد سبب يساوي كلفة الاستثناء.
هذه القاعدة تمنع مشكلة أبسط من الترحيل: أن نضيف اليوم مستودعًا سيحتاج الفريق إلى إصلاحه غدًا.
أما المستودعات القديمة، فأربط تحسينها بعمل حقيقي. إذا احتاجت ميزة إلى ترقية React أو تغيير طبقة البيانات، أضيف التحديث إلى خطة تطوير الميزة وأصدرهما معًا. مشروع «تحديث كل شيء» من دون حاجة منتج واضحة غالبًا يبدأ بحماس ثم يتوقف في المنتصف.
أين تدخل أدوات الذكاء الاصطناعي؟
أستخدم Codex وClaude وCursor وأدوات أخرى كل يوم، لكن وجودها لا يحل اختلاف المستودعات تلقائيًا. الوكيل الذي لا يعرف أوامر المشروع وحدوده سيكرر أخطاء المهندس الجديد، لكن بسرعة أكبر.
لهذا نعطيه السياق نفسه الذي يحتاجه الفريق: تعليمات قريبة من المستودع، ومهارات مخصصة لقرارات التصميم المتكررة، وحدود واضحة لما يمكنه تغييره، وأوامر فحص لا تختلف كل مرة.
نربط بعض هذه الخطوات بأدوات MCP واختبارات شاملة (E2E)، حتى يتمكّن الوكيل من التحقق من صحة الكود وفق معايير الفريق. أراجع النتيجة كما أراجع عمل أي مهندس: هل فهم المشكلة؟ هل غيّر أكثر مما طلبنا؟ وهل يثبت الاختبار السلوك الحقيقي؟
كيف أعرف أن الوضع تحسن؟
لا أحسب نسبة المستودعات التي تستخدم الأداة نفسها. المقياس العملي هو: كم يحتاج مهندس حتى ينجز تغييرًا صغيرًا وآمنًا داخل مستودع لا يعرفه؟
إذا وجد أمر التشغيل، وفهم من يراجع، وعرف الفحوصات المطلوبة، وأرسل أول طلب دمج من دون مساعدة مطوّلة، فالبنية تخدمه. وإذا بقي عالقًا رغم أن كل المستودعات تستخدم React نفسه، فالتوحيد لم يحل شيئًا مهمًا.
يتطلب تنظيم العمل متابعة مستمرة: نوحّد الخطوات المتكررة، ونوثّق أسباب الاختلاف بين المشاريع، ونعالج الفروق التي تعطل الفريق أو تستهلك وقته.