Bu bug emas, bu featur — mohiyati, kelib chiqishi va farqlari

"Bu bug emas, bu featur" nimani anglatadi

"Bu bug emas, bu featur" — ishlab chiquvchi yoki menejer dasturning kutilmagan xatti-harakati xato emas, balki ataylab qilinganligini bildiruvchi ibora. Klassik holatda bu hazil: hamma xatti-harakat xato ekanligini tushunadi, lekin keskinlikni kamaytirish uchun uni "featur" deb ataydi. Biroq real loyihalarda ibora jiddiy ham qo'llaniladi — xatti-harakat haqiqatan spetsifikatsiyaga mos kelganda, lekin foydalanuvchi kutganiga javob bermaganda.

Bug va featur o'rtasidagi farq ko'pincha subyektivdir. Kodni yozgan ishlab chiquvchi uchun ma'lum bir xatti-harakat mantiqiy ko'rinishi mumkin. Foydalanuvchi uchun — kutilmagan va xato. Idrokning subyektivligi — iboraning bunchalik bardoshli bo'lishining asosiy sababi. U suhbatni "kim aybdor" tekisligidan "shunday mo'ljallangan" tekisligiga o'tkazishga imkon beradi. UX Collective ma'lumotlariga ko'ra, foydalanuvchilar tomonidan xabar qilingan buglarning 40 foizi aslida UX muammolari, kod xatolari emas.

Agile jamoalarida ibora ko'pincha demo vaqtida himoya mexanizmi sifatida ishlatiladi. Ishlab chiquvchi kutilmagan xatti-harakatni ko'rsatadi, product owner qoshini tiradi va muqaddas "bu bug emas, bu featur" eshitiladi. Jamoada ishonch iboraning hazilmi yoki muammoni yashirish urinishimi sifatida qabul qilinishini belgilaydi. Sog'lom jamoada bunday hazil muhitni bo'shatadi, toksik jamoada esa nizoga sabab bo'ladi.

Kult iboraning paydo bo'lish tarixi

Iboraning birinchi ma'lum ishlatilishi 1976-yilda DECUS (Digital Equipment Corporation User Society) byulletenlaridan birida qayd etilgan. Foydalanuvchi RUNOFF matn protsessori bo'sh qatorlarni noto'g'ri qayta ishlayotganidan shikoyat qilgan. Ishlab chiquvchining javobi: "Bu bug emas, bu featur — paragraflar shunday qayta ishlanadi". O'shandan beri ibora haqiqiy sifatidan qat'i nazar, "qanday bo'lsa, shunday" yozilgan kodni himoya qilish ramziga aylandi.

Iboraning ommalashishiga Jargon File — 1990-yillarda "The New Hacker's Dictionary" kitobining asosini tashkil etgan haker jargoni lug'ati yordam berdi. Jargon File-dagi "feature" maqolasi to'g'ridan-to'g'ri tuzatishning imkonsizligi yoki istamasligi tufayli featurga aylangan buglarga ishora qiladi. Misol: dastlabki terminallarda Caps Lock tugmasi ko'rsatkichga ega emas edi — bu "ko'r-ko'rona yozish" uchun featurga aylangan bug edi.

2000-yillarda ibora internet memlari orqali ommaviy madaniyatga o'tdi. "It's not a bug, it's a feature" yozuvi bilan mushuk rasmi forumlar va ijtimoiy tarmoqlarga tarqaldi. O'yin sanoatida ibora ayniqsa tez-tez ishlatiladi: o'yinga xalaqit bermaydigan glitchlar atmosfera uchun "featur" deb e'lon qilinadi. Madaniy fenomen IT-dan ancha nariga chiqdi — iborani xatoni oqlaydigan har qanday kontekstda eshitish mumkin.

Bahona psixologiyasi: nega bunday deyishadi

Iboraning psixologik asosi — kognitiv dissonans. Ishlab chiquvchi kod yozishga soatlab vaqt sarflagan va natija xato ekanligini tan olish o'z ishini qadrsizlantirish demakdir. "Bu bug emas, bu featur" iborasi dissonansni kamaytiradi: xato ataylab qilingan qarorga aylanadi, ishlab chiquvchi esa aybdordan g'oya muallifiga aylanadi. Bu o'z-o'zini hurmatni saqlaydigan psixikaning himoya mexanizmi.

Ikkinchi sabab — qayta ishlash qo'rquvi. Agar bug tan olinsa, kodni qayta ko'rib chiqish, test va deploy-dan o'tish kerak bo'ladi. "Featur" tuzatishni talab qilmaydi — topshiriq yopiladi, yuk kamayadi. Microsoft Research ma'lumotlariga ko'ra, ishlab chiquvchilar 23% hollarda qayta ishlashdan qochish uchun buglarning jiddiyligini ataylab pasaytiradilar. Ibora bunday pasaytirishning yumshoq shaklidir.

Uchinchi sabab — korporativ madaniyat. Ba'zi kompaniyalarda buglar ishlab chiquvchining KPI-sida hisobga olinadi va kodni ko'rib chiqishda bug topilishi muallifning xatosi deb hisoblanadi. Bunday muhitda "bu bug emas, bu featur" iborasi karera uchun salbiy oqibatlardan qochish usulidir. Sog'lom xato madaniyati (blameless culture) bu sababni bartaraf qiladi: agar buglar jazolanmasa, ularni tan olish osonroq.

Bug va featur o'rtasidagi chegara qayerdan o'tadi

Aniq chegara faqat Acceptance Criteria (qabul mezonlari) mavjud bo'lgandagina bor. Xatti-harakat AC ning hech bir bandiga mos kelmasa — bu bug. Xatti-harakat AC ga mos kelsa, lekin foydalanuvchiga yoqmasa — bu UX muammosi, bug emas. AC bo'lmasa — har qanday xatti-harakatni featur deb e'lon qilish mumkin va bu iboraning bardoshligining asosiy sababidir.

Amaliy qoida: bug — dastur spetsifikatsiyaga ko'ra qilmasligi kerak bo'lgan narsani qilganda yoki qilishi kerak bo'lgan narsani qilmaganda. Featur — dastur mo'ljallangan narsani qilganda, hatto natija foydalanuvchini hayratda qoldirsa ham. Bahsli holatlar: undefined behavior (til natijani aniqlamaydi), race conditions (barqaror bo'lmagan namoyon bo'ladi), ekstremal qiymatlar (ma'lumotlarning 99% uchun ishlaydi).

Farqlash uchun qaror matritsasidan foydalaning:

• Xatti-harakat spetsifikatsiyada tasvirlangan va to'g'ri amalga oshirilgan — featur, hatto yoqmasa ham
• Xatti-harakat tasvirlangan, lekin noto'g'ri amalga oshirilgan — bug, tuzatishni talab qiladi
• Xatti-harakat tasvirlanmagan, lekin talablardan mantiqan kelib chiqadi — hujjatlashtirilmagan featur, spetsifikatsiyaga qo'shilishi kerak
• Xatti-harakat tasvirlanmagan va mantiqsiz — bug, talablarni aniqlashtirishni talab qiladi

Eng xavfli holat — spetsifikatsiya bo'lmaganda va ishlab chiquvchi featur nima ekanligiga o'zi qaror qilganda. Bunday loyihalarda har qanday xato "featur" deb e'lon qilinishi mumkin, bu esa kodni butun jamoa uchun oldindan aytib bo'lmaydigan qiladi. Har bir topshiriq uchun aniq Acceptance Criteria — chegarani ob'ektiv chizishning yagona yo'lidir.

Jamoada tushunchalarni almashtirish nimasi bilan xavfli

Birinchi xavf — sifatning xiralashishi. Agar har bir bug featur deb e'lon qilinishi mumkin bo'lsa, jamoaning sifatli kod yozish uchun rag'bati qolmaydi. Xatolar tuzatilmaydi, texnik qarz o'sadi, foydalanuvchilar "g'alati xatti-harakatga" o'rganadilar. Ertami-kechmi raqobatchi oldindan aytib bo'ladigan mahsulot chiqaradi va foydalanuvchilar ketadi.

Ikkinchi xavf — jamoada nizolar. QA muhandisi bug topadi, ishlab chiquvchi "bu featur" deydi. Ob'ektiv mezonlar (Acceptance Criteria) bo'lmasa, bahs shaxsiy tekislikka o'tadi: "sen yomon test qilasan" vs "sen yomon dasturlaysan". PractiTest State of Testing 2023 ga ko'ra, "bug vs featur" bahslari QA va ishlab chiquvchilar o'rtasidagi ishqalanishning uchta asosiy sababidan biridir.

Uchinchi xavf — huquqiy risklar. Tartibga solinadigan sohalarda (tibbiyot, moliya, aviatsiya) "bug" va "featur" tushunchalari huquqiy ahamiyatga ega. Tibbiy dasturiy ta'minotda xatti-harakat featur deb e'lon qilinsa, lekin bu dozani noto'g'ri hisoblashga olib kelsa — bu hazil emas, tartibga soluvchi talablarning buzilishidir. Safety-critical tizimlar tushunchalarni almashtirishni kechirmaydi, shuning uchun ularda har doim formal verification qo'llaniladi.

Bug va featur o'rtasidagi chalkashlikning oldini olish

Asosiy vosita — har bir topshiriqda aniq Acceptance Criteria (AC). AC ishlab chiqish boshlanishidan oldin yoziladi: "X kiritilganda tizim Y ni berishi kerak". Xatti-harakat tasvirlanmagan bo'lsa — bu sukut bo'yicha bug, hatto ishlab chiquvchi boshqacha fikrda bo'lsa ham. AC o'lchanadigan va tekshiriladigan bo'lishi kerak: "tugma yashil" — yomon, "HEX #00FF00" — yaxshi.

Ikkinchi vosita — jamoada Definition of Done (DoD). "Topshiriq bajarildi" nimani anglatishining aniq ta'rifi: kod yozilgan, testlar yozilgan, testlar o'tgan, kod ko'rib chiqilgan, stagingga joylashtirilgan, QA tomonidan sinovdan o'tgan. DoD ning barcha bandlari bajarilgan bo'lsa, lekin foydalanuvchi shikoyat qilsa — bu bug emas, balki backlogga yangi featur sifatida tushadigan missed requirement.

Uchinchi vosita — blameless post-mortem madaniyati. Bug featur deb e'lon qilinib, ishlab chiqarishga chiqarilgan bo'lsa — aybdor qidirmay, sabablarni tahlil qilamiz. Nega ishlab chiquvchi bu featur deb qaror qildi? Nega QA o'tkazib yubordi? Nega AC to'liq emas edi? Bu savollarga javoblar jarayonni yaxshilaydi, odamlarni jazolamaydi. Tizimli yaxshilanishlar "bu bug emas, bu featur" iborasini taqiqlashdan ko'ra samaraliroq ishlaydi.