وہ ڈیزائن سسٹم جو پہلا سال گزار جاتے ہیں

سسٹم کوڈ سے نہیں، انتظام سے مرتے ہیں

ناکامی کا انداز جانا پہچانا ہے: زوردار آغاز، ساٹھ کمپوننٹس، شاندار اندرونی ڈیمو — اور اٹھارہ مہینے بعد بٹن کی چار مختلف قسمیں لائبریری سے باہر موجود ہیں اور پروڈکٹ ٹیمیں خاموشی سے اپنی الگ شاخ بنا چکی ہیں۔ اس میں سے تقریباً کچھ بھی تکنیکی مسئلہ نہیں۔ اصل بات یہ ہے کہ اس سوال کا جواب کسی کے ذمے نہیں تھا کہ "مجھے ایسی چیز چاہیے جو سسٹم میں نہیں، تو جمعرات کو میں کیا کروں؟" سسٹم کو ایک نامزد مالک چاہیے جس کے پاس واقعی وقت ہو، شراکت کا لکھا ہوا راستہ چاہیے، اور جواب کے وقت کا وعدہ چاہیے — 48 گھنٹے میں ہاں، ناں، یا کوئی متبادل حل۔ یہ کھڑکی چُوکی تو ٹیمیں اپنا الگ ورژن بنا لیں گی، اور ٹھیک کریں گی، کیونکہ ان کے سر پر ڈیڈ لائن ہے۔ یہ بھی شائع کریں کہ سسٹم کیا نہیں سنبھالے گا۔ جو سسٹم ہر مسئلہ حل کرنے کا دعویٰ کرے، ہر مسئلے کا الزام اسی پر آتا ہے، اور "یکبارگی مارکیٹنگ لے آؤٹ دائرۂ کار سے باہر ہیں" کسی بھی lint قاعدے سے زیادہ الگ شاخیں روکتا ہے۔

tokens کی ایک نہیں، تین تہیں

ہموار یعنی ایک تہہ والے token سیٹ دوسری تھیم کے آس پاس ہی جواب دے جاتے ہیں۔ تین تہیں استعمال کریں۔ Primitives خام قدریں ہیں جن سے کوئی مطلب وابستہ نہیں: blue-600، space-4، ایک سادہ hex۔ Semantic tokens ان خام قدروں کو مقصد سے جوڑتے ہیں: colour-action-primary، colour-surface-raised، colour-text-muted۔ Component tokens ان مقاصد کو مخصوص حصوں سے جوڑتے ہیں: button-primary-background۔ پروڈکٹ کوڈ میں صرف semantic اور component tokens کا حوالہ آنا چاہیے — جس لمحے کوئی کمپوننٹ براہِ راست blue-600 درآمد کرتا ہے، ڈارک موڈ پورے کوڈ بیس میں ڈھونڈو اور بدلو کا کام بن جاتا ہے۔ فائدہ ٹھوس ہے: ڈارک تھیم شامل کرنے کا مطلب صرف ایک semantic تہہ، یعنی تقریباً 40 قدروں کی، دوبارہ تعریف ہے، نہ کہ 600 استعمالات کا جائزہ۔ ناموں کو سادہ رکھیں اور جہاں ممکن ہو مشین سے بنوائیں، انہیں ایک ہی ماخذ سے CSS custom properties اور ڈیزائن ٹول کے متغیرات میں sync کریں، اور دونوں کو کبھی الگ الگ ہاتھ سے سنبھالی جانے والی فہرستوں میں بٹنے نہ دیں۔

دو استعمال کا اصول

تجرید دوسرے حقیقی استعمال پر کریں، پہلے پر نہیں اور تیسرے پر بھی نہیں۔ پہلے استعمال پر آپ اندازہ لگا رہے ہوتے ہیں کہ کون سے حصے بدلتے ہیں، اور غلط اندازہ ایسا کمپوننٹ بنا دیتا ہے جس میں گیارہ props ہوں اور جو اُس markup سے بھی مشکل ہو جس کی اس نے جگہ لی۔ تیسرے استعمال تک تین ٹیمیں ناموافق قسمیں لانچ کر چکی ہوتی ہیں اور یکجا کرنا ایک پوری منتقلی بن جاتا ہے۔ دو حقیقی استعمال وہ مقام ہے جہاں تبدیلی کا محور نظر آ جاتا ہے مگر بدلنے کی لاگت اب بھی کم ہے۔ "حقیقی" کا مطلب ہے مختلف لوگوں نے مختلف مقاصد کے لیے پروڈکشن میں لانچ کیا ہو — ایک ہی صفحے پر دو بار استعمال ہونے والا کارڈ ایک ہی استعمال ہے۔ اس کا نتیجہ: کچھ چیزوں کی تجرید کبھی نہیں کرنی چاہیے۔ ایک بار استعمال ہونے والا لے آؤٹ، کوئی خاکہ، کسی مخصوص صفحے کی اینیمیشن۔ کاپی پیسٹ غلط تجرید سے سستا ہے، اور دہرایا ہوا بلاک ہٹانا مشترکہ بلاک کو سلجھانے سے کہیں آسان ہے۔

اپنانے کو آسان ترین راستہ بنائیں

اپنانا کبھی حکم سے حاصل نہیں ہوتا؛ یہ اس سے ہوتا ہے کہ لائبریری کام کرنے کا تیز ترین راستہ ہو۔ اس کا مطلب ہے ایک ہی کمانڈ سے انسٹالیشن، ایک چلتی ہوئی مثال جو کاپی کی جا سکے، اور ایسے props جو لوگوں کے پہلے سے موجود سوچنے کے انداز سے میل کھائیں۔ اسے ایمان داری سے ناپیں — ایک اسکرپٹ جو ہر ریپازٹری میں لائبریری کے imports بمقابلہ خام عناصر گنے، آپ کو کوریج کا عدد دیتی ہے، اور ٹیم کے حساب سے کوریج بتاتی ہے کہ سسٹم کہاں ناکام ہو رہا ہے۔ یہ عدد شائع کریں۔ پھر خلا کو قابلِ رسائی سے پُر کریں: اگر لائبریری کا select کی بورڈ سے چلنے والا، اسکرین ریڈر کے لیے لیبل شدہ اور درست فوکس ٹریپ کے ساتھ ہے تو اسے دوبارہ بنانا ایک ایسا ہفتہ ہے جو کوئی خرچ نہیں کرنا چاہتا۔ یہی اصل حفاظتی خندق ہے۔ آخر میں، ورژننگ سوچ سمجھ کر کریں، breaking changes کے ساتھ codemods بھیجیں، اور کسی ٹیم کو کبھی اپ گریڈ اور اپنا روڈ میپ مکمل کرنے میں سے ایک چننے پر مجبور نہ کریں۔