Dizayn-tizimni boshqarish: versiyalar, jamoalar hissasi va joriy etish

Governance nima va u nima uchun kerak

Governance — dizayn-tizimda qarorlarni kim qabul qilishi, o‘zgarishlar unga qanday kirishi va mahsulotlar yangi versiyalarga qanday o‘tishi haqidagi qoidalar to‘plami. Ularsiz tizim tezda haqiqatdan uzoqlashadi: jamoalar komponentlarning lokal nusxalarini yaratadi, Figma va kod farqlanadi, yangilanishlar esa ogohlantirishsiz ekranlarni buzadi.

Yaxshi governance to‘rtta savolga javob beradi: egasi kim, o‘zgarishni qanday taklif qilish, versiya qanday chiqariladi va eskirganini qanday olib tashlash.

Boshqarish modellari

Har qanday modelda «yo‘q» deyishga haqli aniq ega kerak — aks holda tizim hamma narsa yig‘iladigan omborga aylanadi.

Hissa qo‘shish jarayoni

Jamoalar o‘z nusxalarini yaratish o‘rniga komponentlarni tizimga olib kelishi uchun jarayon sodda va oldindan bilinadigan bo‘lishi kerak:

1. So‘rov. Jamoa tayyor yechimni emas, muammoni tasvirlaydi: mavjud komponentlar nimani yopmaydi.
2. Dublikatni tekshirish. Mavjud komponentning varianti bilan hal qilsa bo‘ladimi.
3. Baholash. Komponent bir nechta mahsulotga kerakmi yoki bu mahsulotda qoladigan lokal holatmi.
4. Dizayn va kod. Komponent holatlar, moslashuvchanlik va accessibility bilan loyihalanadi, parallel ravishda — implementatsiya va hujjatlar.
5. Ko‘rib chiqish. Dizayn-review, kod-review, accessibility tekshiruvi.
6. Chiqarish. Changelog yozuvi bilan relizga kiradi.

Darajalar kiritish foydali: core (yadro qo‘llab-quvvatlaydi, qat’iy kafolatlar) va community yoki experimental (jamoalar olib kelgan, o‘zgarishi mumkin). Shunda hissa uzoq review’lar bilan bloklanmaydi.

Figma va kodni versiyalash

Semantik versiyalash MAJOR.MINOR.PATCH dan foydalaning:

• PATCH — API o‘zgarmagan tuzatishlar: oraliq, fokus rangi to‘g‘rilandi.
• MINOR — buzmasdan yangi narsa: yangi variant, yangi komponent, yangi xususiyat.
• MAJOR — buzuvchi o‘zgarishlar: xususiyat nomi o‘zgardi, variant olib tashlandi, tokenlar tuzilishi o‘zgardi.

Ikkala tomon uchun amaliyot:

• Kod versiyali paket sifatida nashr qilinadi, jamoalar ongli ravishda yangilanadi.
• Figma kutubxonasi har bir relizda o‘zgarishlar tavsifi bilan nashr qilinadi. Yirik o‘zgarishlar uchun branch’lar va merge’dan oldin review ishlatiladi.
• Yagona versiya raqami yoki hech bo‘lmasa Figma’ning qaysi versiyasi kodning qaysi versiyasiga mosligi jadvali.
• Tushunarli tilda changelog: nima o‘zgardi, kimga ta’sir qiladi, yangilashda nima qilish kerak.

Yozuv namunasi:

## 3.0.0
### Breaking
- Button: `type` xususiyati `variant` deb qayta nomlandi.
### Added
- Toast: `warning` varianti.
### Fixed
- Input: pleysxolder kontrasti.

Eskirish siyosati

Komponentni darhol o‘chirib bo‘lmaydi — mahsulotlar unga bog‘langan. Normal sikl:

1. E’lon. Komponent Figma va kodda deprecated deb belgilanadi (konsol yoki linterda ogohlantirish), hujjatlarda nima bilan almashtirish yoziladi.
2. O‘tish davri. Komponent ishlashda davom etadigan, oldindan e’lon qilingan muddat yoki relizlar soni.
3. Migratsiya. Qo‘llanma, imkon bo‘lsa — codemod yoki avtomatik almashtirish.
4. Keyingi MAJOR versiyada o‘chirish.

Joriy etish metrikalari

Kutubxonadagi komponentlar sonini emas, haqiqiy foydalanishni ko‘rsatadigan narsani o‘lchang:

• Qamrov: mahsulotdagi ekran yoki komponentlarning lokal nusxalardan emas, tizimdan yig‘ilgan ulushi. Kodda importlar tahlili orqali, Figma’da kutubxona analitikasi orqali hisoblanadi.
• Figma’dagi ajratilgan (detached) instanslar — komponent nimadir bilan qoniqtirmayotganining belgisi.
• Versiyadan orqada qolish: har bir mahsulot qaysi versiyada.
• Hissa tezligi: so‘rovdan relizgacha qancha vaqt o‘tadi.
• Fikr-mulohaza: jamoalar bilan muntazam so‘rovnomalar va murojaatlar tahlili.

Ko‘p uchraydigan xatolar

• Egasi yo‘q — qarorni kim balandroq gapirsa, o‘sha qabul qiladi.
• Figma va kod bog‘liqliksiz turli versiyalarda.
• Minor relizda buzuvchi o‘zgarishlar.
• O‘tish davrisiz komponentlarni o‘chirish.
• «Qancha ishlatilyapti» o‘rniga «qancha komponent yaratildi» metrikasi.