Tezroq frontend ishlab chiqish uchun o‘z-o‘zini tahlil qilish

Kontekst

Men kichik dasturchi bo‘lganimda, kodni ko‘rib chiqish imkoniga ega bo‘lgan muhitda dasturlashni boshlaganimdan baxtiyor edim. Avvaliga ko‘rib chiqish mezonlari nimaligini ham yaxshi bilmasdim. Funksionallik to‘g‘ri ishlasa, ishlab chiqish yakunlangan deb o‘ylardim va dastlab ko‘rib chiqishlarda ko‘tarilgan masalalar arzimasdek tuyulardi.

Ko‘pincha funksionallikka bevosita bog‘liq bo‘lmagan sohalar, masalan, importlar tartibi yoki o‘zgaruvchi nomlari haqida savollar olardim.

• "Bu state qiymati haqiqatan ham kerakmi?"

• "Siz buni watch yordamida bajargansiz, lekin event yordamida bajarish ma’qulroq emasmi?"

• "Bu komponentning mas’uliyatlari haddan tashqari ko‘p emasmi?"

• "null, undefined va bo‘sh massivlar to‘g‘ri qayta ishlanyaptimi?"

Dastlab har bir bandni birma-bir tuzatish zerikarli bo‘lishi mumkin edi. Biroq jamoaviy ishlab chiqishda qatnashib, xizmatlarni production muhitida ishlatganimdan so‘ng, nuqtayi nazarim asta-sekin o‘zgardi. "Funksionallik hozir to‘g‘ri ishlayaptimi?" degan savol bilan cheklanmay, o‘zimdan: "Agar bu kodni yana boshqa birov o‘zgartirishi kerak bo‘lsa, uni oson tushuna oladimi?" deb so‘ray boshladim.

Production muhitida "keyinroq muammo yuz bersa, uni boshqa dasturchi tuzatadi" degan fikr bilan ishlash qiyin. Hatto jamoa bo‘lib ishlab chiqilganda ham, men yozgan kodni boshqa birov o‘zgartirishi kerak bo‘lishi mumkin, men esa bir necha oy o‘tib o‘sha kodga yana duch kelishim mumkin.

Bu tajribalarni takrorlaganim sari, ishlab chiqish jarayonida ilgari kodni ko‘rib chiqish paytida tekshirgan ayrim bandlarni tabiiy ravishda tekshira boshladim.

Albatta, amaliyotda har bir kod qismini batafsil ko‘rib chiqish hamon qiyin. Bu, ayniqsa, ishlab chiqish jadvali tig‘iz bo‘lganda yaqqol seziladi. Shuning uchun men «o‘z kodini ko‘rib chiqish» deganda to‘liq tahlildan ko‘ra, minimal tekshiruv jarayoniga yaqinroq narsani nazarda tutaman: tez ishlab chiqish jarayonida e’tibordan chetda qolishi oson bo‘lgan masalarga yana bir bor nazar tashlash.

1. O‘z kodini ko‘rib chiqish nima uchun zarur

Tez ishlab chiqayotganda, funksiyani amalga oshirib, uning to‘g‘ri ishlashini tasdiqlagach, keyingi vazifaga o‘tib ketish oson. Faqat ishlab chiqish tezligi nuqtayi nazaridan bu samarali yondashuv bo‘lishi mumkin. Biroq qanchalik tez ishlab chiqsangiz, kodga xolis nigoh bilan qarash imkoniyatlari shunchalik kamayadi. Kod yozayotganda butun kontekstni tushunganingiz sababli, keraksiz kod yoki noaniq tuzilmalarni tabiiy ravishda e’tibordan chetda qoldirish oson.

2. Funksionallik ishlagani uchun ko‘rib chiqish yakunlanmaydi

Ekran odatdagidek ko‘rinsa va tugmani bosish kutilgan natijani bersa, ishlab chiqish yakunlangandek tuyulishi mumkin. Biroq real xizmatlar faqat odatiy holatlardan (Happy Path) iborat emas. Hatto bitta API so‘rovini ko‘rib chiqayotganda ham, turli ssenariylarni hisobga olish kerak.

• Oddiy javob → Ma’lumotlarni ko‘rsatish

• API xatosi → Xatoni qayta ishlash

• Javob ma’lumotlari yo‘q → Bo‘sh holat

• undefined / null → Ma’lumot mavjudligini tekshirish va uni xavfsiz qayta ishlash

• Takroriy bosishlar → Takroriy so‘rovlar yoki nomuvofiq state holatining oldini olish

O‘zini o‘zi ko‘rib chiqishda shunchaki "To‘g‘ri ishlayaptimi?" deb so‘rash bilan cheklanmaslik kerak. Shuningdek, "G‘ayritabiiy holatlarda ham ekran butunligicha qoladimi?" degan savolni ham tekshirish lozim.

3. Birinchi ko‘rib chiqish: Keraksiz kodni aniqlash

Birinchi navbatda qaraladigan narsa hayratlanarli darajada oddiy: "Bu kod haqiqatan ham kerakmi?"

① Ishlatilmayotgan o‘zgaruvchilar va importlar

Test qilish uchun qoldirilgan console.log() bayonotlari, endi ishlatilmayotgan o‘zgaruvchilar yoki import qilingan, ammo foydalanilmayotgan modullar bor-yo‘qligini tekshiring. Buni ESLint kabi statik tahlil vositalari yordamida avtomatlashtirish ma’qul.

② Takroriy kod

Agar bir xil API chaqiruvlari va xatoni qayta ishlash bir nechta ekranda takrorlansa, ularni umumiy qilish kerak yoki kerak emasligini ko‘rib chiqing. Biroq kodni ko‘r-ko‘rona birlashtirish har doim ham to‘g‘ri javob emas. Qarorni "Agar bu kod umumiy qilinsa, uni saqlash haqiqatan ham osonlashadimi?" degan savolga asoslanib qabul qiling.

③ Haddan tashqari ko‘p state qiymatlari

// ❌ AS-IS
const dataList = ref([]);
const isEmpty = ref(false);
const hasData = ref(false);
// ⭕ TO-BE
const dataList = ref([]);
const isEmpty = computed(() => dataList.value.length === 0);한 상태값

Yuqorida ko‘rsatilganidek, avvalo isEmpty yoki hasData kabi, faqat dataList asosida hisoblash mumkin bo‘lgan qiymatlarni alohida state (ref) sifatida boshqarish haqiqatan ham kerakmi-yo‘qmi, deb o‘ylab ko‘rishingiz mumkin.

Agar state’ni alohida boshqarsangiz, har safar ma’lumot yangilanganda isEmpty yoki hasData qiymatini ham ma’lumot bilan birga qo‘lda yangilashingiz kerak bo‘ladi. Agar state’ni yangilash mantiqining hatto bitta qismi ham qoldirib ketilsa, haqiqiy ma’lumot mavjud bo‘lsa-da, ekranda "Ma’lumot yo‘q" ko‘rsatiladigan xato yuzaga kelishi mumkin. Asl ma’lumotga bog‘liq holda ishlashi uchun computed’dan foydalanish orqali state qiymatlarini qo‘lda sinxronlashtirish zaruratini kamaytirish va dasturchilar state’ni yangilashni unutib qo‘yish ehtimolini pasaytirish mumkin.

4. Ikkinchi ko‘rib chiqish: Komponent mas’uliyatlarini tekshirish

Dastlab oddiy bo‘lgan komponent ham ishlab chiqish davomida ko‘plab mas’uliyatlarni o‘z zimmasiga olishi mumkin: foydalanuvchini qidirish, autentifikatsiya, formani tekshirish, modallar va sahifalash shular jumlasidandir.

Katta komponentni ko‘rganda, uni funksiyalar bo‘yicha sohalarga ajrating va bu sohalarni mustaqil ravishda ajratish mumkinmi-yo‘qmi, ko‘rib chiqing. Biroq kod uzun bo‘lgani uchungina uni tartibsiz ravishda bo‘lib tashlash fayllar bo‘ylab navigatsiya qilish xarajatini oshiradi. Muhimi, uni "kichik qilish" emas, balki "mas’uliyatlarini aniq belgilash"dir.

Props va Emits: Ota komponent juda ko‘p state’ni bevosita boshqaryaptimi va event nomiga qarab uning nima qilishini tushunish mumkinmi, tekshiring.

5. Uchinchi ko‘rib chiqish: State va istisno holatlarni tekshirish

Shaxsan men buni o‘z kodini ko‘rib chiqishning eng muhim qismi deb hisoblayman. Ekranlar odatiy holatlarga qaraganda istisno holatlarda buzilish ehtimoli ancha yuqori.

① Yuklanish va xato holatlari

Ma’lumot yuklanayotganda foydalanuvchi fikr-mulohaza olyaptimi? (Takroriy bosishlarning oldini olish)

API ishlamay qolganda ekran qanday boshqariladi? (Foydalanuvchi bo‘sh ekranda qotib qolmaydimi?)

Bir loyiha uchun kodni ko‘rib chiqayotganimda, autentifikatsiya jarayonida ma’lum bir xato yuz berganda istisnoni qayta ishlash mavjud emasligini aniqlagandim. Natijada butun ekran oq rangga aylanib, foydalanuvchi davom eta olmasdi. Autentifikatsiyaning odatiy oqimida muammo bo‘lmagani uchun, faqat odatiy holatlar tekshirilganida bu xatoni payqash oson bo‘lmasdi. Shu tajribadan keyin API chaqiruvlari kodini ko‘rganimda, faqat muvaffaqiyatli natijani tekshiribgina qolmay, "Agar bu yerda xato yuz bersa, foydalanuvchi qaysi ekranni ko‘radi?" deb ham so‘rayman.

② Bo‘sh va Null / Undefined holatlar

Ma’lumot bo‘sh massiv ([]) bo‘lgan holat (Empty State) API ishlamay qolgan holatdan farq qiladi. Shuningdek, user.profile.name kabi murojaatlarda profile mavjud bo‘lmasligi ehtimolini hisobga olmasangiz, runtime xatosi yuzaga kelib, ekranning to‘g‘ri ko‘rsatilishiga xalaqit berishi mumkin.

6. To‘rtinchi ko‘rib chiqish: Asinxron operatsiyalar va API chaqiruvlarini tekshirish

Takroriy chaqiruvlar: Sahifaga kirilganda, watch ishga tushganda yoki foydalanuvchi hodisasi yuz berganda bir xil API keraksiz ravishda chaqirilayotgan- chaqirilmayotganini tekshiring.

Asinxron ishlov berish tartibi (Race Condition): Foydalanuvchi biror amalni tezda ikki marta bajarganda, keyingi so‘rov ma’lumotlari avvalroq kelib, undan keyin oldingi so‘rov ma’lumotlari kelib, eng so‘nggi state’ni ustidan yozib yuborishi mumkinmi-yo‘qmi, tekshiring.

7. Beshinchi ko‘rib chiqish: Unga saqlash qulayligi nuqtayi nazaridan yana bir bor qarash

Nihoyat, kodni uni birinchi marta ko‘rayotgan odam nuqtayi nazaridan tartibga keltiring.

Nomlash va HTML semantikasi: const temp kabi nomlar o‘rniga rolni ochib beradigan nomlardan foydalaning va click hodisalarini talab qiladigan tugmalar uchun <div> o‘rniga <button> ishlatilganini tekshiring.

Izohlar va ishlatilmaydigan kod: Ishlatilmaydigan kodni qatorma-qator izohga olib qoldirmang. Git tarixni saqlaydi. Izohlar kod “nima” qilishini emas, balki nima sababdan aynan shu tarzda yozilganini tushuntirishi kerak.

Tuzilmaviy izchillik: Fayl ichida importlar, props, state, metodlar va boshqa elementlarning joylashuvi loyihaning mavjud qoidalariga mos kelishini tekshiring.

Agar loyihada API bilan ishlashning umumiy yondashuvi, yordamchi vositalar yoki UI komponentlari allaqachon mavjud bo‘lsa, yangi yondashuv yaratishdan oldin avval mavjud realizatsiyalarni tekshiring.

Yangi yozilgan kod texnik jihatdan yaxshiroq ko‘rinsa ham, loyiha­ning mavjud andozalaridan farq qiladigan andozadan foydalanish aslida texnik xizmat ko‘rsatish xarajatlarini oshirishi mumkin. Shuning uchun yangi yondashuvni qo‘llashda “bu usul yaxshiroq ko‘rinadi” degan sabab bilan mavjud yondashuvni shunchaki o‘zgartirishdan ko‘ra, avval uning butun loyiya bo‘ylab izchil ishlashini tekshirish xavfsizroq.

Masalan, API chaqiruvlari va xatolarni qayta ishlash allaqachon standartlashtirilgan bo‘lsa, muayyan ekran ularni alohida qayta ishlayotgan yoki ishlamayotganini tekshiring.

8. Haqiqiy o‘zgarishlar asosida o‘z-o‘zini tekshirish

Kod yozish jarayonida bularning barchasini tekshirish ishlab chiqishni sekinlashtirishi mumkin. Men avval funksionallikni to‘liq amalga oshirib, keyin faqat Git Diff yoki PR dagi o‘zgarishlar kabi haqiqatda o‘zgartirilgan kodni ko‘rish mumkin bo‘lgan ko‘rinishda uni yana bir bor tekshirishni ma’qul ko‘raman.

Kod yozayotganda men “Buni qanday amalga oshirishim kerak?” degan savolga e’tibor qarataman. Tekshiruv paytida esa nuqtayi nazarimni “Agar bu kodni birinchi marta ko‘rayotgan bo‘lsam, uni tushuna olarmidim?” degan savolga o‘zgartiraman.

[Minimal o‘z-o‘zini tekshirish ro‘yxati]

• Funksionallik

• To‘g‘ri kiritilgan ma’lumot bilan kutilganidek ishlaydimi?

• Yuklanish / Xatolik / Bo‘sh holatlar qayta ishlanganmi?

• Mumkin bo‘lgan null / undefined qiymatlarini tekshirdingizmi?

• Mavjud funksionallikka ta’sir qilmasligiga ishonch hosil qilinganmi?

• Kod

• Ishlatilmaydigan o‘zgaruvchilar / importlar / console.log bayonotlari bormi?

• Keraksiz state qiymatlarini yaratishdan qochdingizmi?

• Takrorlangan mantiqni tekshirdingizmi?

• Komponentning mas’uliyat doirasi haddan tashqari keng emasmi?

• API / Asinxron amallar

• Bir xil API lar ortiqcha ravishda takroran chaqirilmayaptimi?

• API xatolarini qayta ishlash izchilmi?

• Ketma-ket so‘rovlar state ning izchil bo‘lmay qolishiga sabab bo‘lishi mumkinmi?

• Texnik xizmat ko‘rsatish qulayligi

• O‘zgaruvchilar va funksiyalarning vazifasini faqat nomlariga qarab tushuna olasizmi?

• Ishlatilmaydigan kod yoki eskirgan izohlar bormi?

• Loyihaning mavjud andozalariga mos keladimi?

• Kodni birinchi marta ko‘rayotgan dasturchi uni tushunib, kuzatib bora oladimi?

9. Amaliy kod tekshiruvi tajribasi va realistik murosalar

Junior dasturchi sifatida tekshiruvlarni qabul qilib o‘rgan­ganlarim keyinchalik ishlab turgan xizmatlarni takomillashtiradigan loyihalarda kod tekshiruvlari uchun mas’ul bo‘lganimda ham yordam berdi. Koddagi muammolarni shunchaki izlashdan tashqari, ular kelajakdagi o‘zgartirishlar va texnik xizmat ko‘rsatishga qanday ta’sir qilishi mumkinligini ham hisobga ola boshladim. Aslida, shu jarayon orqali avvalgi loyihada yuzaga kelishi mumkin bo‘lgan muammolarni ular sodir bo‘lishidan oldin aniqlab, tuzata oldim.

Biroq har bir loyihaga mukammal standartlarni tatbiq etib bo‘lmaydi. Jadvali juda tig‘iz bo‘lgan loyihani qo‘llab-quvvatlaganimda buni boshdan kechirdim. Funksiyalarni ishlab chiqish uchun ham mas’ul bo‘lganim sababli, mavjud kodning barchasini tozalashga real vaqtim yetmasdi. Bunday vaziyatda men ustuvorliklarni belgilab, avval zarur qismlarni takomillashtirdim.

1. Funksionallikka ta’sir qiladigan muhim muammolar

2. Texnik xizmat ko‘rsatishga bevosita xalaqit beradigan qismlar

3. Standartlashtirish aniq foyda beradigan qismlar

4. Oddiy kod uslubini tozalash (console bayonotlarini olib tashlash va izohlarni tartibga solish kabi vazifalarni imkon qadar kamaytirish)

Jadval tig‘izligi sababli har bir muammoni e’tiborsiz qoldirish oxir-oqibat texnik qarzga olib keladi, ammo birdaniga mukammallikka erishishga urinib, muddatni o‘tkazib yuborish ham muammodir. Shuning uchun vaziyatga qarab ustuvorliklarni belgilayman va avval zarur qismlarni takomillashtirishga harakat qilaman.

Xulosa

Kodning o‘z-o‘zini tekshiruvi batafsil arxitektura tekshiruvi bo‘lishi shart emas. Bu, ayniqsa, tezkor ishlab chiqish talab etilganda to‘g‘ri. Men uchun kodning o‘z-o‘zini tekshiruvi, oxir-oqibat, “funksionallik amalga oshirilgandan keyin kodga yana bir bor tanqidiy nazar bilan qarash” degan ma’noni anglatadi.

Junior dasturchi sifatida kod tekshiruvlarida ko‘tarilgan masalalarni birma-bir hal qilish orqali o‘rgandim. Hozir ham shunga o‘xshash vaziyatlarga duch kelganimda, o‘sha tekshiruvlarda menga berilgan savollarni eslashga harakat qilaman.

Tez ishlab chiqish kerak bo‘lganda, har bir qismni mukammal tekshirishga urinishdan ko‘ra, avval o‘tkazib yuborgan narsalaringiz bor-yo‘qligini yana bir bor tekshirish uchun hatto besh daqiqa ajratishdan boshlashingiz mumkin.

Code_Latte