بناء نظام تصميم يصمد لسنوات

معظم أنظمة التصميم لا تموت فجأة، بل تتآكل ببطء حتى يتجاهلها الفريق ويعود إلى النسخ واللصق. لا أحد يعلن وفاتها، لكن الجميع يعرف أن الملف الرسمي لم يعد يعكس المنتج الحقيقي.

العدد ليس المقياس

نظام بأربعين مكوّناً مستخدماً أفضل من نظام بمئتين نصفها مهجور. نبدأ صغيراً بما يغطي ثمانين بالمئة من الحالات الفعلية، ثم نضيف عند الحاجة الحقيقية لا المتوقّعة. المكوّن الذي بُني تحسّباً لحالة لم تأتِ هو دَين لا أصل.

المؤشر الذي نتابعه ليس عدد المكوّنات بل نسبة الاستخدام: كم شاشة بُنيت من النظام دون عناصر مرتجلة؟ إن انخفضت هذه النسبة فالنظام يفقد صلته بالمنتج.

التحديث جزء من التصميم

النظام الذي لا توجد طريقة واضحة لتحديثه سيتفرّع إلى نسخ غير رسمية خلال أشهر. نحدّد مساراً للاقتراح والمراجعة والإصدار منذ البداية، ونوثّقه داخل النظام نفسه لا في ملف منفصل يُنسى.

والمسار يجب أن يكون سريعاً. إذا استغرقت إضافة حالة جديدة لمكوّن أسبوعين من الموافقات، سيبني المطوّر حلاً محلياً في عشر دقائق ولن يعود.

• ابدأ بما يغطي أغلب الحالات، لا بما قد تحتاجه لاحقاً

• تابع نسبة الاستخدام لا عدد المكوّنات

• اجعل مسار التحديث أسرع من الالتفاف حوله

• وثّق القرار لا الشكل فقط: لماذا هذا المكوّن بهذه الطريقة

التوثيق الذي يُقرأ

التوثيق الطويل لا يُقرأ. ما يُقرأ هو مثال قصير بجانب المكوّن يوضّح متى يُستخدم ومتى لا يُستخدم. جملتان في المكان الصحيح أفضل من صفحة في مكان بعيد.

والأهم توثيق حالات الاستثناء: ماذا يفعل الفريق حين لا يوجد مكوّن مناسب؟ غياب هذه الإجابة هو ما يولّد الارتجال.

«النظام يخدم المنتج، لا العكس. حين يتعارض الاثنان، المنتج هو الذي يفوز، ثم نحدّث النظام ليستوعب الحالة الجديدة.»

من يملك النظام

النظام بلا مالك يصبح مسؤولية الجميع، أي مسؤولية لا أحد. خصّص شخصاً واحداً على الأقل بوقت مخصّص، ولو بنسبة يوم واحد أسبوعياً. هذه النسبة الصغيرة هي الفرق بين نظام حيّ وأرشيف.