“Ishlaydi — tegma” — bu nima, tamoyilning mohiyati va xatarlar

“Ishlaydi — tegma” tamoyili nima?

“Ishlaydi — tegma” tamoyili (ingl. “If it ain't broke, don't fix it”) — bu dasturchilarni yetarli asoslarsiz ishlayotgan kodga o'zgartirish kiritishdan ogohlantiruvchi empirik qoidadir. Tamoyilning asosida oddiy statistika yotadi: nuqsonlarning katta qismi aynan mavjud kodni o'zgartirish jarayonida yuzaga keladi.

Tamoyil dogma emas — bu noaniqlik sharoitida qaror qabul qilishga yordam beruvchi evristikadir. Kod bazasi qanchalik murakkab va chalkash bo'lsa, “begunoh” o'zgarish hech kim kutmagan narsani buzishi ehtimoli shunchalik yuqori.

Tadqiqotga ko'ra, Microsoft korporatsiyasi (2024), ishlab chiqarishdagi barcha kritik hodisalarning taxminan 60% i yaxshi niyat bilan qilingan, ammo real yuk sharoitida yetarlicha sinovdan o'tmagan so'nggi kod o'zgarishlari bilan bog'liq.

Tamoyilning tarixi va kelib chiqishi

Ibora “If it ain't broke, don't fix it” XX asr o'rtalaridagi Amerika muhandislik madaniyatiga borib taqaladi. Eng dastlabki hujjatlashtirilgan foydalanish AQSh Senatining Moliya qo'mitasida ishlagan va ortiqcha tartibga solishga qarshi chiqqan Bert Lansga (1977) tegishli.

Dasturlashga tamoyil apparat muhandisligidan kelgan, bu yerda ishlayotgan mikrosxemani yangisiga almashtirish oldindan aytib bo'lmaydigan oqibatlarga olib kelishi mumkin edi. Dasturiy ta'minot kontekstida bu tamoyil tizimlarning murakkabligi oshishi va legasi kodning paydo bo'lishi bilan ayniqsa keng tarqaldi.

Qizig'i shundaki, dasturlashda tamoyilning teskari tomoni ham bor — “ishlaydi, lekin tegmaslik yaxshiroq” ko'pincha refaktoringdan bosh tortish uchun bahona bo'ladi, bu uzoq muddatda texnik qarzning kritik darajada to'planishiga olib keladi. Thoughtworks konsalting kompaniyasining (2023) ma'lumotlariga ko'ra, loyihalarning taxminan 40% i o'zgarishlarga nisbatan haddan tashqari konservatizm tufayli jiddiy muammolarga duch keladi.

Tamoyilni qachon qo'llash kerak

“Ishlaydi — tegma” tamoyili ayniqsa xato narxi o'zgarishlarning potentsial foydasidan yuqori bo'lgan muayyan vaziyatlarda dolzarbdir.

Testsiz legasi loyihalar

Legasi kodda testlar bilan qoplanmagan, har bir o'zgarish rus ruleti o'yinidir. Agar dasturchi o'zgarish qo'shni modullarni buzganligini tekshira olmasa, eng yaxshi strategiya ishlayotgan kodga tegmaslikdir. Istisno — faqat kritik xatolar yoki xavfsizlik talablari.

Kritik tizimlar

To'xtab qolish mumkin bo'lmagan yoki xato narxi juda katta bo'lgan tizimlarda — tibbiy dasturiy ta'minot, avionika, moliyaviy tranzaksiyalar — “ishlaydi — tegma” tamoyili de-fakto standartdir. Har bir o'zgarish ko'p bosqichli kelishish va sinovdan o'tkaziladi.

Qattiq muddatlar

Agar chiqarish ertaga bo'lsa va kod ishlayotgan bo'lsa — uning arxitekturasini yaxshilashga urinmang. Faqat chiqarish funksionalligiga bevosita ta'sir qiladigan narsani o'zgartiring. Refaktoringni keyingi sprintga qoldiring (lekin uni unutmang).

Tamoyilga rioya qilishning xatarlari

Tamoyilga “ishlaydi — tegma” ko'r-ko'rona rioya qilish cheksiz refaktoringdan kam xatarli emas. Keling, asosiy xavflarni ko'rib chiqaylik.

Texnik qarzning to'planishi

Agar har bir dasturchi bu tamoyilga amal qilsa, kod bazasi tezda eskirgan yechimlar, “qo'ltiq tayoqchalari” va optimal bo'lmagan algoritmlardan iborat “qatlamli tort”ga aylanadi. Ertami-kechmi texnik qarz chidab bo'lmas holga keladi — har bir o'zgarish haftalar lab tahlil talab qiladi.

Qo'ldan boy berilgan optimallashtirish

Ba'zan xavfli ko'rinadigan o'zgarish aslida unumdorlik yoki xavfsizlikni sezilarli darajada yaxshilaydi. “Ishlaydi — tegma” tamoyili o'lchanadigan foyda keltiradigan — server xarajatlarini kamaytirish, sahifa yuklanishini tezlashtirish, xavfsizlikni oshirish — o'zgarishlarni bloklamasligi kerak.

Kompetensiyalarning yo'qolishi

Jamoa yillar davomida kodning ma'lum qismlariga tegmasa, ular qanday tuzilganligini tushunishni yo'qotadi. Asosiy dasturchi ketadi — va kod qo'llab-quvvatlash imkoniyati bo'lmagan legasiga aylanadi. Tamoyil loyihaning uzoq muddatli qo'llab-quvvatlanishini hisobga olgan holda qo'llanilishi kerak.

Oltin o'rta: fanatizmsiz refaktoring

Optimal strategiya — tamoyilga ko'r-ko'rona emas, balki kontekstni hisobga olgan holda ongli ravishda amal qilishdir. Refaktoring kerak, ammo xavfsiz bo'lishi kerak.

Skaut qoidasi

Skaut qoidasi dasturlashda: “Kodni topganingdan tozaroq qoldir”. Agar dasturchi modulga o'zgarish kiritsa, uning tuzilishini yaxshilashi kerak, lekin oqilona chegaralarda. Hammasini boshidan yozmaslik, hech bo'lmaganda o'qib bo'lmaydigan o'zgaruvchilarni qayta nomlash va sharhlar qo'shish.

Testlar himoyasi ostida refaktoring

Testlar — “ishlaydi — tegma” tamoyilini xavfsiz qo'llashning yagona yo'lidir. Agar kod testlar bilan qoplangan bo'lsa, har bir refaktoring bashorat qilinadigan bo'ladi: dasturchi kodni o'zgartiradi, testlarni ishga tushiradi va hech narsa buzilmaganligini ko'radi. Testsiz — tegma. Testlar bilan — dadil refaktor qil.

// Misol: test qamrovi ostida xavfsiz refaktoring
class PriceCalculator {
    fun calculatePrice(basePrice: Double, discount: Double): Double {
        // Eski, ammo ishlayotgan kod
        return basePrice - (basePrice * discount / 100.0)
    }
}

// Regressiyadan himoya qiluvchi test
class PriceCalculatorTest {
    fun testCalculatePrice() {
        val calc = PriceCalculator()
        assertEquals(90.0, calc.calculatePrice(100.0, 10.0))
    }
}

Bu misol to'g'ri yondashuvni ko'rsatadi: avval test, keyin refaktoring. Test o'tsa — o'zgarish xavfsiz. “Ishlaydi — tegma” tamoyili “testlar ostida ishlaydi — dadil refaktor qil”ga aylanadi.

Amaliyotdan real misollar

Haqiqiy stsenariylarni ko'rib chiqaylik, ularda “ishlaydi — tegma” tamoyili ham qutqaruvchi, ham halokatli bo'lgan.

Qutqaruvchi holat: Y2K ga o'xshash muammo

Dasturchi aniqladiki, sanalarni qayta ishlash kodida YYYY o'rniga DD/MM/YY formati ishlatilgan. Kod 2000 yildan 2025 yilgacha to'g'ri ishlagan. “Tuzatish” istagiga qaramay — kodni o'z holicha qoldirdi, faqat sharh yozish bilan cheklandi. 2026 yilda kompaniya tizimni yangiladi va yangi yechim asrlarni to'g'ri qayta ishlaydigan bo'ldi. Muddati oldidan o'zgartirish ishlayotgan mantiqni buzgan bo'lar edi.

Halokatli holat: “Yaxshilash” tufayli ma'lumot yo'qolishi

Muhandis qaror qildi eski, ammo ishlayotgan ma'lumot import kodini “yaxshilash” uchun uni zamonaviy kutubxona bilan almashtirsin. U eski kutubxona hujjatlashtirilmagan maxsus chekka holatni qayta ishlashini hisobga olmadi. Chiqarishdan so'ng — ommaviy ma'lumot yo'qolishi. “Ishlaydi — tegma” tamoyili buzildi va xato narxi jamoaning ikki haftalik tiklash ishi bo'ldi.