Minimal frontend o‘z-o‘zini tekshirish

Asosiy ma’lumotlar

Men junior dasturchi bo‘lganimda kodni ko‘rib chiqish imkoniga ega bo‘lgan muhitda dasturlashni boshlaganimdan baxtiyor edim. Avvaliga ko‘rib chiqish mezonlari nimalardan iborat ekanini aniq bilmasdim. Funksionallik to‘g‘ri ishlasa, dasturlash yakunlangan deb o‘ylardim va ko‘rib chiqishlarda ko‘rsatilgan muammolar dastlab arzimasdek tuyulardi.

Ko‘pincha funksionallik bilan bevosita bog‘liq bo‘lmagan jihatlar, masalan, import bayonotlarining tartibi yoki o‘zgaruvchi nomlari haqida savollar olardim.

• "Bu state qiymati haqiqatan ham kerakmi?"

• "Buni watch bilan hal qilibsiz, lekin event yordamida hal qilish 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 tuzatishni bittadan kiritish ba’zan zerikarli edi. Biroq jamoaviy dasturlashda qatnashib, production muhitida ishlaydigan servislarni bevosita ko‘rganimdan so‘ng, qarashlarim asta-sekin o‘zgardi. "Funksionallik hozir to‘g‘ri ishlayaptimi?" degan savol bilan cheklanmay, o‘zimdan "Agar keyinchalik bu kodni boshqa kimdir o‘zgartirishi kerak bo‘lsa, uni oson tushuna oladimi?" deb so‘ray boshladim.

Production muhitida "keyinchalik muammo yuzaga kelsa, boshqa dasturchi uni tuzatadi" degan fikr bilan ishlash qiyin. Hatto jamoa bo‘lib dasturlashda ham men yozgan kodni boshqa kimdir o‘zgartirishi yoki bir necha oy o‘tgach, o‘sha kodni yana ko‘rib chiqishimga to‘g‘ri kelishi mumkin.

Bu tajribalarni takrorlaganim sari, avval kodni ko‘rib chiqishda tekshirgan jihatlarimni dasturlash jarayonida ham kamida bir marta tekshira boshladim.

Albatta, amalda har bir kod qismini batafsil ko‘rib chiqish hali ham qiyin. Bu, ayniqsa, dasturlash jadvali tig‘iz bo‘lganda yaqqol seziladi. Shuning uchun men "o‘z kodini ko‘rib chiqish" deganda batafsil tahlildan ko‘ra, tez dasturlash paytida e’tibordan chetda qolishi oson bo‘lgan muammolarni yana bir bor tezda tekshirishga yaqin bo‘lgan minimal tekshiruv jarayonini nazarda tutaman.

1. Nima uchun o‘z kodini ko‘rib chiqish zarur

Tez dasturlashda funksiyani amalga oshirib, uning to‘g‘ri ishlashini tasdiqlagandan so‘ng keyingi vazifaga o‘tib ketish oson. Agar faqat dasturlash tezligini hisobga olsangiz, bu samarali yondashuv bo‘lishi mumkin. Biroq qanchalik tez dasturlasangiz, kodga xolis nazar bilan qarash imkoniyatlari shunchalik kamayadi. Kodni yozayotganingizda uning umumiy kontekstini tushunganingiz uchun keraksiz kod yoki noaniq tuzilmalarni tabiiy ravishda e’tibordan chetda qoldirish oson.

2. Funksionallik ishlayotgani ko‘rib chiqish yakunlanganini anglatmaydi

Ekran odatdagidek ko‘rinsa va tugmani bosish kutilgan natijani bersa, dasturlash yakunlangandek tuyulishi mumkin. Biroq real servislar faqat odatiy holatlardan (Happy Path) iborat emas. Hatto bitta API so‘rovi uchun ham turli vaziyatlarni hisobga olish kerak.

• Muvaffaqiyatli 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 state nomuvofiqliklarining oldini olish

O‘z kodimni ko‘rib chiqishda faqat "To‘g‘ri ishlayaptimi?" deb so‘rash bilan cheklanmayman. Shuningdek, "G‘ayrioddiy vaziyatlarda u o‘zini qanday tutadi?" degan savolni ham ko‘rib chiqaman.

3. Birinchi ko‘rib chiqish: keraksiz kodni aniqlash

Men qaraydigan birinchi narsa hayratlanarli darajada oddiy: "Bu kod haqiqatan ham kerakmi?"

① Ishlatilmayotgan o‘zgaruvchilar va import bayonotlari

Test uchun qoldirib ketilgan console.log() bayonotlari, endi ishlatilmayotgan o‘zgaruvchilar yoki boshqa kerak bo‘lmagan import qilingan modullar bor-yo‘qligini tekshiring. Buni ESLint kabi statik tahlil vositalari yordamida avtomatlashtirish yaxshi fikr.

② Takroriy kod

Agar bir xil API chaqiruvlari va xatolarni qayta ishlash bir nechta ekran bo‘ylab takrorlansa, ularni umumiy qilish kerak yoki kerak emasligini ko‘rib chiqing. Biroq hamma narsani ko‘r-ko‘rona umumiy qilish har doim ham to‘g‘ri javob emas. Qarorni "Agar bu kod umumiy qilinsa, texnik xizmat ko‘rsatish haqiqatan ham osonlashadimi?" degan savol asosida 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, avval isEmpty yoki hasData kabi faqat dataList asosida hisoblash mumkin bo‘lgan qiymatlarni alohida state (ref) qiymatlari sifatida boshqarish haqiqatan ham kerakmi-yo‘qmi, shuni ko‘rib chiqishingiz mumkin.

Agar state alohida boshqarilsa, ma’lumotlar yangilanganda isEmpty yoki hasData qiymatlari ham qo‘lda yangilanishi kerak. State yangilash mantiqining hatto bitta qismi tushirib qoldirilsa, amalda ma’lumot mavjud bo‘lsa ham, ekranda "Ma’lumot yo‘q" ko‘rsatiladigan xato yuzaga kelishi mumkin. Mantiqni boshlang‘ich ma’lumotlarga bog‘lash uchun computed dan foydalanish state qiymatlarini qo‘lda sinxronlashtirish zaruratini kamaytiradi va dasturchining state yangilanishini o‘tkazib yuborish ehtimolini pasaytiradi.

4. Ikkinchi ko‘rib chiqish: komponentlar mas’uliyatini tekshirish

Dastlab oddiy bo‘lgan komponent ham dasturlash jarayoni davomida foydalanuvchini qidirish, autentifikatsiya, formani tekshirish, modallar va sahifalash kabi ko‘plab mas’uliyatlarni o‘z zimmasiga olishi mumkin.

Katta komponentni ko‘rsam, uni funksionalligiga ko‘ra qismlarga ajrataman va ularning birortasini mustaqil ajratish mumkin yoki mumkin emasligini ko‘rib chiqaman. Biroq kod uzun bo‘lgani uchungina uni tartibsiz ravishda bo‘lish fayllar bo‘ylab navigatsiya qilish xarajatini oshiradi. Muhim narsa uni "kichikroq qilish" emas, balki "mas’uliyatlarni aniq belgilash"dir.

Props va Emits: Ota komponent haddan tashqari ko‘p state ni bevosita boshqarayotganini va xatti-harakatni faqat event nomiga qarab tushunish mumkinligini tekshiring.

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

Shaxsan men buni o‘z kodini ko‘rib chiqishdagi eng muhim jihat deb bilaman. Ekranlar odatiy holatlarga qaraganda istisno holatlarda ancha ko‘proq ishdan chiqadi.

①Yuklanish va xato holatlari

• Ma’lumotlar yuklanayotgan vaqtda foydalanuvchiga mos holat ko‘rsatiladimi?

• API ishlamay qolganda, foydalanuvchi keyingi amalni bajarishi mumkin bo‘lgan holatda xatoga ishlov beriladimi?

Bir loyiha uchun kodni ko‘rib chiqayotganimda, autentifikatsiya vaqtida muayyan xato yuz berganda istisno qayta ishlanmay, butun ekran oqarib qolishi va keyingi jarayon davom etmasligiga sabab bo‘layotgan muammoni aniqlagan edim. Oddiy autentifikatsiya oqimida muammo bo‘lmagani uchun, faqat odatiy holat tekshirilganida bu xatoni payqash oson bo‘lmasdi. O‘shandan beri API chaqiruvlari kodini ko‘rganimda, nafaqat muvaffaqiyatli natijani tekshiraman, balki "Agar bu yerda xatolik yuz bersa, foydalanuvchi qaysi ekranni ko‘radi?" deb ham so‘rayman.

② Bo‘sh va Null / Undefined

Ma’lumotlar bo‘sh massiv ([]) bo‘lgan vaziyat (Empty State) API ishlamay qolgan vaziyatdan farq qiladi. Shuningdek, user.profile.name kabi murojaatlarda profile mavjud bo‘lmasligi mumkinligini hisobga olmasangiz, runtime xatosi yuzaga kelib, ekran to‘g‘ri ko‘rsatilishiga to‘sqinlik qilishi 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 chaqirilayotganini tekshiring.

Asinxron qayta ishlash tartibi (Race Condition): Foydalanuvchi amalni ketma-ket ikki marta tez bajarganda, keyingi so‘rov ma’lumotlari avval, oldingi so‘rov ma’lumotlari esa keyinroq kelib, eng so‘nggi state ni ustidan yozib yuborishi mumkinligini tekshiring.

7. Beshinchi ko‘rib chiqish: texnik xizmat ko‘rsatish nuqtayi nazaridan qayta ko‘rib chiqish

Nihoyat, men hammasini kodni birinchi marta ko‘rayotgan odam nuqtayi nazaridan umumlashtiraman.

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

Izohlar va ishlatilmayotgan kod: Ishlatilmayotgan kodni izoh sifatida qoldirgandan ko‘ra, uni tozalab tashlagan ma’qul. Avvalgi kodni Git o‘zgarishlar tarixidan tekshirish mumkin. Izohlar zarur bo‘lganda esa, kodning o‘zidangina tushunish qiyin bo‘lgan narsalar yoki alohida e’tibor talab qiladigan jihatlar sababini yozib qoldiring.

Tuzilmaviy izchillik: import, props, state, methods va boshqalarning joylashuvi hamda uslubi loyihadagi mavjud koddan sezilarli darajada farq qilish-qilmasligini tekshiring. Biroq mavjud yondashuvga ko‘r-ko‘rona ergashish o‘rniga, joriy kod uchun yanada mos yondashuv bor-yo‘qligini ham ko‘rib chiqing.

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

Mavjud yondashuvdan o‘z holicha foydalanishingiz mumkin, ammo vaziyatga qarab yangi yondashuvni ham tanlashingiz mumkin. Muhimi, avval mavjud yondashuv nima sababdan ishlatilayotganini o‘rganish, so‘ng joriy kod uchun qaysi usul mosroq ekanini aniqlashdir.

Masalan, API chaqiruvlari va xatolarni qayta ishlash allaqachon standartlashtirilgan bo‘lsa, avval mavjud yondashuvdan foydalanish mumkinligini tekshiring. Aksincha, mavjud yondashuv faqat muayyan vaziyatlarda ishlasa yoki uni yaxshilash kerak bo‘lsa, yangi yondashuvni qo‘llashni ko‘rib chiqing.

8. Haqiqiy o‘zgarishlarga asoslangan o‘z-o‘zini ko‘rib chiqish

Kod yozish jarayonining o‘rtasida bularning barchasini tekshirish aslida ishlab chiqishni sekinlashtirishi mumkin. Men avval funksionallikni to‘liq amalga oshirib, keyin faqat haqiqatda o‘zgartirilgan kodni ko‘rish mumkin bo‘lgan ekranda, masalan, Git diff yoki PR dagi o‘zgarishlar orqali, yana bir bor ko‘rib chiqishni ma’qul ko‘raman.

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

[O‘z-o‘zini ko‘rib chiqishning minimal tekshiruv ro‘yxati]

-Funksionallik

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

• Loading / Error / Empty holatlari qayta ishlanganmi?

• Mumkin bo‘lgan null / undefined qiymatlarni tekshirdingizmi?

• U mavjud funksionallikka ta’sir qilmaslikni ta’minlaydimi?

-Kod

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

• Keraksiz state qiymatlarini yaratdingizmi?

• Takrorlangan mantiqni tekshirdingizmi?

• Komponentning mas’uliyati haddan tashqari kattami?

-API / Asinxron amallar

• Bir xil API ortiqcha ravishda takroran chaqirilayaptimi?

• API xatolarini qayta ishlash izchilmi?

• Ketma-ket so‘rovlar state holatining izchilligini buzishi mumkinmi?

-Qo‘llab-quvvatlanish qulayligi

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

• Ishlatilmayotgan kod yoki eskirgan izohlar bormi?

• Mavjud andozadan farqli yondashuvdan foydalangan bo‘lsangiz, bunga sabab bormi?

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

9. Haqiqiy loyihalardagi ko‘rib chiqish tajribasi va amaliy murosalar

Yangi dasturchi sifatida ko‘rib chiqishlarni qabul qilishdan o‘rganganlarim keyinchalik kodni o‘zim ko‘rib chiqa boshlaganimda ham yordam berdi. Men shunchaki koddagi muammolarni izlash bilan cheklanmay, ular keyingi o‘zgartirishlar va texnik xizmat ko‘rsatishga qanday ta’sir qilishi mumkinligini ham o‘ylay boshladim. Amalda kodni shu nuqtayi nazardan tekshirish ba’zan ishlab chiqish vaqtida e’tibordan chetda qolishi oson bo‘lgan xatolarni aniqlash va tuzatishga yordam berdi.

Biroq har bir loyihaga mukammal standartlarni qo‘llashning imkoni yo‘q. Jadvali juda tig‘iz bo‘lgan loyihani qo‘llab-quvvatlaganimda buni boshdan kechirdim. Funksionallikni ishlab chiqish uchun ham mas’ul bo‘lganim sababli, mavjud kodning barchasini tozalashga real vaqtim yetmasdi. Bunday vaziyatda ustuvorliklarni belgilab, avval zarur sohalarni yaxshiladim.

1. Funksionallikka ta’sir qiladigan muhim muammolar

2. Qo‘llab-quvvatlanish qulayligiga bevosita xalaqit beradigan sohalar

3. Standartlashtirish aniq foyda beradigan sohalar

4. Kod uslubini oddiy tozalash (console bayonotlarini olib tashlash, izohlarni tartibga solish va hokazo, lekin buni minimal darajada saqlagan holda)

Jadval tig‘izligi sababli har bir muammoni e’tiborsiz qoldirish oxir-oqibat texnik qarz sifatida qaytib keladi, ammo bir yo‘la mukammallikka erishishga urinish va belgilangan muddatni o‘tkazib yuborish ham muammo. Shuning uchun vaziyatga qarab ustuvorliklarni belgilayman va avval zarur sohalarni yaxshilashga harakat qilaman.

Xulosa

Kodning o‘zini ko‘rib chiqish batafsil arxitektura tahlili bo‘lishi shart emas. Bu, ayniqsa, tezkor ishlab chiqish talab qilinganda to‘g‘ri. Men uchun kodni o‘zini ko‘rib chiqish, oxir-oqibat, “funksionallik amalga oshirilgandan keyin kodga yana bir bor shubha bilan qarash” degan ma’noni anglatadi.

Yangi dasturchi sifatida men kodni ko‘rib chiqishlarda ko‘tarilgan masalalarni birma-bir hal qilish orqali o‘rgandim. Hozir ham shunga o‘xshash vaziyatlarga duch kelganimda, o‘sha ko‘rib chiqishlarda menga berilgan savollarni eslashga harakat qilaman.

Tez ishlab chiqish kerak bo‘lganda, har bir qismni mukammal ko‘rib chiqishga urinish o‘rniga, hech narsani o‘tkazib yubormaganingizni tekshirish uchun bor-yo‘g‘i besh daqiqa vaqt ajratib, kodga yana bir bor qarashdan boshlashingiz mumkin.

Code_Latte