Bu bug deyil, bu featurdur — mahiyyəti, mənşəyi və fərqləri

"Bu bug deyil, bu featurdur" nə deməkdir

"Bu bug deyil, bu featurdur" — tərtibatçı və ya menecerin proqramın gözlənilməz davranışının səhv deyil, qəsdən olduğunu bildirdiyi ifadə. Klassik halda bu zarafatdır: hamı başa düşür ki, davranış səhvdir, lakin gərginliyi azaltmaq üçün onu "feature" adlandırırlar. Lakin real layihələrdə ifadə ciddi şəkildə də işlədilir — davranış həqiqətən spesifikasiyaya uyğun olduqda, lakin istifadəçinin gözləntilərinə cavab vermədikdə.

Bugla feature arasındakı fərq çox vaxt subyektivdir. Kodu yazan tərtibatçı üçün müəyyən davranış məntiqli görünə bilər. İstifadəçi üçün — gözlənilməz və səhv. Qavrayışın subyektivliyi — ifadənin bu qədər davamlı olmasının əsas səbəbidir. O, söhbəti "kim günahkardır" müstəvisindən "belə nəzərdə tutulub" müstəvisinə keçirməyə imkan verir. UX Collective-ə görə, istifadəçilər tərəfindən bildirilən bugların 40%-i əslində UX problemləridir, kod səhvləri deyil.

Agile komandalarında ifadə tez-tez demo zamanı müdafiə mexanizmi kimi istifadə olunur. Tərtibatçı gözlənilməz davranışı göstərir, product owner qaşqabağını tökür və müqəddəs "bu bug deyil, bu featurdur" səslənir. Komandada inam ifadənin zarafat, yoxsa problemi gizlətmək cəhdi kimi qəbul ediləcəyini müəyyən edir. Sağlam komandada belə bir zarafat atmosferi boşaldır, toksik komandada isə münaqişəyə səbəb olur.

Kult ifadənin yaranma tarixi

İfadənin ilk məlum istifadəsi 1976-cı ildə DECUS (Digital Equipment Corporation User Society) bülletenlərindən birində qeydə alınmışdır. İstifadəçi RUNOFF mətn prosessorunun boş sətirləri səhv emal etdiyindən şikayətlənirdi. Tərtibatçının cavabı: "Bu bug deyil, bu featurdur — paraqraflar belə emal olunur". O vaxtdan bəri ifadə real keyfiyyətindən asılı olmayaraq, "olduğu kimi" yazılmış kodun müdafiəsinin simvoluna çevrildi.

İfadənin populyarlaşmasına Jargon File — 1990-cı illərdə "The New Hacker's Dictionary" kitabının əsasını təşkil edən haker jarqonu lüğəti kömək etdi. Jargon File-da "feature" məqaləsi birbaşa düzəldilməsinin mümkünsüzlüyü və ya istəməməsi səbəbindən feature çevrilmiş buglara istinad edir. Nümunə: erkən terminallarda Caps Lock düyməsinin göstəricisi yox idi — bu, "kor yazma" üçün feature çevrilmiş bir bug idi.

2000-ci illərdə ifadə internet memləri vasitəsilə kütləvi mədəniyyətə keçdi. "It's not a bug, it's a feature" yazısı olan pişik şəkli forumlara və sosial şəbəkələrə yayıldı. Oyun sənayesində ifadə xüsusilə tez-tez istifadə olunur: geympleyə mane olmayan qlitchlər atmosfer üçün "feature" elan edilir. Mədəni fenomen IT-dən çox kənara çıxdı — ifadə səhvi bəhanə edən hər hansı kontekstdə eşidilə bilər.

Bəhanə psixologiyası: niyə belə deyirlər

İfadənin psixoloji əsası koqnitiv dissonansdır. Tərtibatçı kod yazmağa saatlar sərf edib və nəticənin səhv olduğunu etiraf etmək öz işini dəyərdən salmaq deməkdir. "Bu bug deyil, bu featurdur" ifadəsi dissonansı azaldır: səhv qəsdən qərara çevrilir, tərtibatçı isə günahkardan ideyanın müəllifinə dönür. Bu, özünə hörməti qoruyan psixikanın müdafiə mexanizmidir.

İkinci səbəb — yenidən işləmə qorxusu. Bug etiraf edilərsə, koda yenidən baxış, test və deploy-dan keçmək lazımdır. "Feature" düzəliş tələb etmir — tapşırıq bağlanır, yük azalır. Microsoft Research-ə görə, tərtibatçılar 23% hallarda yenidən işləmədən qaçmaq üçün şüurlu şəkildə bugların şiddətini aşağı göstərirlər. İfadə belə bir aşağı göstərmənin yumşaq formasıdır.

Üçüncü səbəb — korporativ mədəniyyət. Bəzi şirkətlərdə buglar tərtibatçının KPI-sında nəzərə alınır, kod baxışında bug aşkarlanması müəllifin səhvi sayılır. Belə bir mühitdə "bu bug deyil, bu featurdur" ifadəsi karyera üçün mənfi nəticələrdən qaçmaq üsuludur. Sağlam səhv mədəniyyəti (blameless culture) bu səbəbi aradan qaldırır: buglar cəzalandırılmırsa, onları etiraf etmək daha asandır.

Bugla feature arasında sərhəd haradan keçir

Aydın sərhəd yalnız Acceptance Criteria (qəbul meyarları) olduqda mövcuddur. Davranış AC-nin heç bir bəndinə uyğun deyilsə — bu bugdır. Davranış AC-yə uyğundursa, lakin istifadəçiyə xoş gəlmirsə — bu UX problemidir, bug deyil. AC yoxdursa — istənilən davranış feature elan edilə bilər və bu, ifadənin davamlılığının əsas səbəbidir.

Praktik qayda: bug — proqram spesifikasiyaya görə etməməli olduğu şeyi etdikdə və ya etməli olduğu şeyi etmədikdə. Feature — proqram nəzərdə tutulanı etdikdə, hətta nəticə istifadəçini təəccübləndirsə belə. Mübahisəli hallar: undefined behavior (dil nəticəni müəyyən etmir), race conditions (qeyri-sabit təzahür edir), ekstremal dəyərlər (məlumatların 99%-i üçün işləyir).

Ayırd etmək üçün qərar matrisindən istifadə edin:

• Davranış spesifikasiyada təsvir edilmiş və düzgün tətbiq edilmişdir — feature, hətta bəyənməsəniz belə
• Davranış təsvir edilmiş, lakin səhv tətbiq edilmişdir — bug, düzəliş tələb edir
• Davranış təsvir edilməmiş, lakin tələblərdən məntiqi olaraq irəli gəlir — sənədləşdirilməmiş feature, spesifikasiyaya əlavə edilməlidir
• Davranış təsvir edilməmiş və məntiqsizdir — bug, tələblərin dəqiqləşdirilməsi tələb edir

Ən təhlükəli hal — spesifikasiya olmadıqda və tərtibatçı nəyin feature olduğuna özü qərar verdikdə. Belə layihələrdə istənilən səhv "feature" elan edilə bilər, bu da kodu bütün komanda üçün proqnozlaşdırılmaz edir. Hər tapşırıq üçün aydın Acceptance Criteria — sərhədi obyektiv çəkməyin yeganə yoludur.

Komandada anlayışların əvəzlənməsi nə üçün təhlükəlidir

Birinci təhlükə — keyfiyyətin bulanıqlaşması. Hər bug feature elan edilə bilirsə, komandanın keyfiyyətli kod yazmaq üçün stimulu qalmır. Səhvlər düzəldilmir, texniki borc artır, istifadəçilər "qəribə davranışa" öyrəşirlər. Gec-tez rəqib proqnozlaşdırıla bilən məhsul buraxır və istifadəçilər gedir.

İkinci təhlükə — komandada münaqişələr. QA mühəndisi bug tapır, tərtibatçı "bu featurdur" deyir. Obyektiv meyarlar (Acceptance Criteria) yoxdursa, mübahisə şəxsi müstəviyə keçir: "sən pis test edirsən" vs "sən pis proqramlaşdırırsan". PractiTest State of Testing 2023-ə görə, "bug vs feature" mübahisələri QA ilə tərtibatçılar arasında sürtünmənin üç əsas səbəbindən biridir.

Üçüncü təhlükə — hüquqi risklər. Tənzimlənən sənayelərdə (tibb, maliyyə, aviasiya) "bug" və "feature" anlayışları hüquqi çəkiyə malikdir. Tibbi proqramda davranış feature elan edilərsə, lakin bu dozanın səhv hesablanmasına gətirib çıxararsa — bu zarafat deyil, tənzimləyici tələblərin pozulmasıdır. Safety-critical sistemlər anlayışların əvəzlənməsini bağışlamır, buna görə də onlarda həmişə formal verification tətbiq olunur.

Bugla feature arasında qarışıqlığın qarşısını necə almaq

Əsas alət — hər tapşırıqda aydın Acceptance Criteria (AC). AC inkişaf başlamazdan əvvəl yazılır: "X daxil edildikdə sistem Y verməlidir". Davranış təsvir edilməyibsə — bu, tərtibatçı başqa cür düşünsə belə, default olaraq bugdır. AC ölçülə bilən və yoxlanıla bilən olmalıdır: "düymə yaşıl" — pis, "HEX #00FF00" — yaxşı.

İkinci alət — komandada Definition of Done (DoD). "Tapşırıq yerinə yetirildi"nin nə demək olduğunun aydın təsviri: kod yazılıb, testlər yazılıb, testlər keçir, kod baxışı keçib, staging-ə yerləşdirilib, QA tərəfindən test edilib. DoD-nin bütün bəndləri yerinə yetirilibsə, lakin istifadəçi şikayət edirsə — bu bug deyil, geri çatdırılma ehtiyatına yeni feature kimi daxil olan missed requirement-dir.

Üçüncü alət — blameless post-mortem mədəniyyəti. Bug feature elan edilib və istehsala buraxılıbsa — günahkar axtarmır, səbəbləri təhlil edirik. Niyə tərtibatçı bunun feature olduğuna qərar verdi? Niyə QA buraxdı? Niyə AC natamam idi? Bu sualların cavabları prosesi təkmilləşdirir, insanları cəzalandırmır. Sistem təkmilləşdirmələri "bu bug deyil, bu featurdur" ifadəsinin qadağan edilməsindən daha effektiv işləyir.