Dasturlash asoslari — ma'lumotnoma
Dastur tuzish nazorat ro’yxati
- Dastur kim uchun va qanday natija beradi?
- Kirish ma’lumoti hamda natija nima?
- Qaysi holatlar noto’g’ri yoki mumkin emas?
- Masala qaysi kichik qadamlarga bo’linadi?
- Qayerda shart, sikl yoki funksiya kerak?
- Eng kichik uchta test misoli qaysilar?
Xato xabarini o’qish
| Ko’rinish | Birinchi tekshiruv |
|---|---|
| Dastur ishga tushmadi | Xabar, fayl, qator va yopilmagan belgi |
| Dastur to’xtadi | Xabar turi hamda o’sha qadamdagi qiymat |
| Natija noto’g’ri | Kutilgan/haqiqiy natija va oraliq o’zgaruvchilar |
| Faqat ayrim holatda buzildi | Eng kichik takrorlanuvchi kirish |
Ish shablonlari
Keyingi yo’l
| Maqsad | Davom eting |
|---|---|
| Kod yozishni noldan boshlash | Python |
| Brauzerda sahifa yaratish | HTML/CSS |
| Saytning ichki ishlashi | Web dasturlash |
| Ma’lumot bilan ishlash | SQL |
Texnologik javobni avval rasmiy hujjatdan tekshiring, keyin kichik misolda sinang. Kod parchasi ulashilganda parol, token, cookie va .env mazmunini albatta olib tashlang.
Masalani tahlil qilish shabloni
Yangi vazifani boshlaganda ushbu to’rt qatorni to’ldiring:
Maqsad: foydalanuvchi nimaga erishadi?
Kirish: qaysi qiymatlar keladi?
Chiqish: qanday aniq natija qaytadi?
Qoidalar: qaysi qiymatlar yaroqsiz va qaysi holatlar alohida?Masalan, xarajatlar hisoblagichida kirish nom va summa, chiqish jami hamda budjet holati, yaroqsiz holat esa bo’sh nom yoki nol/manfiy summa bo’ladi. Shu to’rt qator kod yozishdan oldin mantiqiy noaniqlikni kamaytiradi.
Psevdokod uchun savollar
Psevdokod yozganda har qadam bajariladimi, u tugaydimi va qiymatlar qayerda o’zgarishini tekshiring. Sikl uchun “qaysi elementlar” va “qachon to’xtaydi” degan savol bo’lishi kerak. Shart uchun rost hamda yolg’on yo’lning ikkalasi aniq bo’lishi kerak. Funksiya uchun esa u nimani olishi va nimani qaytarishi yoziladi.
Ish sifatini tekshirish
| Bosqich | Savol |
|---|---|
| Talab | Kerakli natija gap bilan aniq aytilganmi? |
| Mantiq | Kirish, qoida va chiqish ajratilganmi? |
| Kod | Nomlar tushunarli va takror kamaytirilganmi? |
| Test | Odatiy, bo’sh va noto’g’ri holat tekshirilganmi? |
| Debugging | Muammo takrorlanib, dalil bilan toraytirilganmi? |
| Xavfsizlik | Maxfiy qiymat Git, log yoki xabarga tushmaganmi? |
Rasmiy hujjatni o’qish odati
Rasmiy hujjatdan avval kerakli bo’limning maqsadini, so’ng parametr va qaytadigan qiymatni toping. Misolni ko’chirishdan oldin o’zgartirib sinang: bitta kirish qiymatini almashtiring, chekka holat qo’shing va xato chiqqanda xabarini o’qing. Shu odat sizni tayyor yechimga qaram bo’lishdan saqlaydi.
Tushuncha va qoidalar
Asosiy tushunchalar xaritasi
Dasturlashdagi atamalar bir-biridan alohida emas. Talab nima qurilishini belgilaydi. Talabdan algoritm, ya’ni qadamlar rejasi chiqadi. Algoritmni yozayotganda qiymatlarni saqlash uchun o’zgaruvchi, tanlov qilish uchun shart, takror uchun sikl va qadamlarni tartiblash uchun funksiya kerak bo’ladi. Tayyor kod esa test bilan tekshiriladi, muammo chiqsa debugging qilinadi. Bu bog’lanishni tushunish yangi til yoki freymvork o’rganilganda ham yo’lni yo’qotmaslikka yordam beradi.
| Tushuncha | Nima uchun kerak? | Oddiy misol |
|---|---|---|
| Talab | Ishning chegarasini belgilaydi | “Xarajatlar jamini ko’rsatish” |
| Algoritm | Qadamlarni tartiblaydi | Qo’shish, hisoblash, solishtirish |
| O’zgaruvchi | Qiymatni saqlaydi | jami, budjet |
| Shart | Vaziyatga qarab yo’l tanlaydi | Jami oshsa ogohlantirish |
| Sikl | Bir qoidani ko’p marta bajaradi | Har xarajatni qo’shish |
| Funksiya | Vazifani nomlaydi va qayta ishlatadi | jami_hisobla() |
| Test | Kutilgan natijani tekshiradi | Bo’sh ro’yxatda jami 0 |
Atamalarni yodlashning o’zi yetarli emas. Har birini o’zingizning kichik misolingizga ulang. Masalan, kontakt qidirish dasturida kontaktlar ro’yxati kirish, qidirilayotgan ism o’zgaruvchi, har kontaktni ko’rish sikl, ism mosligini tekshirish shart va qidirish jarayoni funksiya bo’ladi. Shunda atama mavhum so’z emas, ishlayotgan qadamga aylanadi.
Ma’lumot turi va validatsiya
Qiymat tashqi ko’rinishda to’g’ri ko’rinishi mumkin, lekin dastur uchun noto’g’ri turda kelishi mumkin. Masalan, "12" matn, 12 esa son. Ularni qo’shish ayrim tillarda 24 emas, "128" kabi qo’shilgan matn berishi mumkin. Shuning uchun foydalanuvchi kiritgan qiymatga ishonishdan oldin uning turi, bo’sh emasligi va ruxsat etilgan chegarasini tekshiring.
Validatsiya uchun quyidagi savollar foydali:
- Bu qiymat majburiymi yoki ixtiyoriymi?
- U qaysi turda keladi: matn, son, sana, ro’yxatmi?
- Eng kichik va eng katta ruxsat etilgan qiymat qancha?
- Bo’sh yoki noto’g’ri qiymatda dastur nima deydi?
- Qiymat keyin qayerda ishlatiladi va xavfsizmi?
Xato xabari foydalanuvchiga tuzatish yo’lini ko’rsatsin. “Invalid input” o’rniga “Summa 0 dan katta son bo’lishi kerak” aniqroq. Shu bilan birga, ichki texnik ma’lumotlarni — server yo’li, token, baza xabari yoki stack trace’ni — foydalanuvchiga bermang. Ular logda xavfsiz kontekst bilan qayd etilishi mumkin, ammo interfeysda keraksiz va xavfli bo’lishi mumkin.
Shart, sikl va funksiya tanlash
| Vaziyat | Mos vosita | Tekshiruv savoli |
|---|---|---|
| Qiymatni keyin ishlatish kerak | O’zgaruvchi | Nom nimani anglatyapti? |
| Ikki natijadan biri tanlanadi | Shart | Rost va yolg’on yo’li bormi? |
| Har elementga bir qoida kerak | Sikl | Nima o’zgaradi, qachon tugaydi? |
| Bir qadamlar qayta ishlatiladi | Funksiya | Kirish va chiqish aniqmi? |
| Noto’g’ri qiymat kelishi mumkin | Validatsiya | Qaysi holat rad etiladi? |
| Natija ishonchli bo’lishi kerak | Test | Odatiy va chekka misollar bormi? |
Funksiya bir nechta ishni bajara boshlasa, uni bo’lish haqida o’ylang. buyurtmani_yubor degan funksiya bir vaqtning o’zida kiritishni tekshirsa, narxni hisoblasa, faylga yozsa va xabar chiqarsa, muammoni alohida sinash qiyinlashadi. buyurtmani_tekshir, jami_hisobla, saqla va xabar_tuz kabi kichik qismlar esa maqsadni ko’rinarli qiladi. Biroq har bitta satr uchun yangi funksiya yaratish ham shart emas; bo’lish qarori tushunarlilik va takrorni kamaytirishga xizmat qilsin.
Test holatlarini tanlash
Kamida uch turdagi misol yozing: odatiy holat, chekka holat va noto’g’ri kirish. Xarajat hisoblagichida odatiy holat ikki musbat summa bo’lishi mumkin; chekka holat bo’sh ro’yxat yoki budjetga aynan teng jami; noto’g’ri kirish esa manfiy summa yoki matn. Har holat uchun faqat “sinab ko’rdim” demang, kutilgan natijani oldindan yozing. Shunda haqiqiy natijani solishtirish mumkin bo’ladi.
| Kirish | Kutilgan natija | Nega kerak? |
|---|---|---|
12000 va 8000 | Jami 20 000 | Asosiy hisobni tekshiradi |
| Bo’sh ro’yxat | Jami 0 yoki bo’sh holat xabari | Sikl va boshlang’ich qiymatni tekshiradi |
| Budjet 20 000 | Qoida aniq ishlaydi | > va >= farqini ushlaydi |
-5000 | Validatsiya xabari | Yaroqsiz ma’lumotni tekshiradi |
"o'n ming" | Son kiritish so’raladi | Turlar bilan xatoni tekshiradi |
Tuzatishdan keyin faqat muammo chiqqan misolni emas, avval ishlagan asosiy oqimni ham qayta sinang. Bu regressiyani, ya’ni yangi o’zgarish boshqa ishlaydigan qismni buzib qo’ygan holatni erta aniqlaydi.
Debuggingning qisqa protokoli
- Muammoni aniq kirish bilan qayta yarating.
- Kutilgan natija va haqiqiy natijani yonma-yon yozing.
- Xato xabaridagi fayl, qator va turini o’qing.
- Eng kichik ishlamaydigan misolni qoldiring.
- Kerakli oraliq qiymatni
print, Console yoki debugger bilan kuzating. - Bitta taxminni sinang; bir paytda ko’p tahrir qilmang.
- Tuzatishni odatiy, chekka va noto’g’ri holatda tekshiring.
Bu protokol taxminiy tahrirlar o’rniga dalil to’plashga majbur qiladi. Masalan, 12 + 8 o’rniga "128" chiqsa, avval qiymatlarning turini ko’ring. So’ng ular qayerda matndan songa aylanishi kerakligini aniqlang. Rangni yoki butun funksiyani o’zgartirish bu muammoga aloqador emasligini dalil bilan bilasiz.
Git bilan xavfsiz ishlash
Git loyihaning o’zgarishlar tarixini saqlaydi, lekin tartibli ishlatilsa foydali bo’ladi. Ishdan oldin git status orqali nimalar o’zgarganini ko’ring. Commitdan oldin git diff bilan farqni o’qing: tasodifan maxfiy fayl, keraksiz katta fayl yoki boshqa ishga tegishli o’zgarish qo’shilmaganini tekshiring. Commit xabari nima o’zgarganini aytsin, masalan “xarajat validatsiyasini qo’shish”.
Branch alohida ish maydoni, pull request esa o’zgarishni review qilish nuqtasidir. Ular ayniqsa jamoada foydali: boshqa odam kiritilgan farqni o’qiydi, test yoki build natijasini ko’radi, savol beradi. Hech qachon token, parol, cookie, .env yoki shaxsiy ma’lumotni Gitga qo’shmang. Bunday ma’lumot tarixi ichida qolib ketishi mumkin.
Keyingi darsni tanlash mezoni
Yo’nalishni “eng ommabop til”ga qarab emas, o’zingiz qurmoqchi bo’lgan narsa va hozirgi tayyorgarligingizga qarab tanlang. Mantiq, algoritm va kichik terminal dasturi yoqsa, Python mos davom bo’ladi. Brauzerda ko’rinadigan sahifa yaratish qiziq bo’lsa, HTML/CSSdan boshlang. Sahifaning interaktivligi va so’rovlar qiziqtirsa, JavaScript hamda Web dasturlashga o’ting. Jadval va ma’lumot so’rovlari bilan ishlash uchun SQL kerak bo’ladi.
Bir vaqtning o’zida hammasini o’rganishga urinmang. Bitta yo’nalishda kichik loyiha tugating, undagi kamchiliklarni yozing va keyingi mavzuni shu ehtiyojdan tanlang. Masalan, xarajatlar ro’yxatini faylga saqlash zarurati Python fayllari yoki ma’lumotlar bazasiga tabiiy o’tish bo’ladi. Shu tariqa yangi mavzu alohida vazifa emas, amaliy ehtiyojga javob beradi.
Qisqacha xulosa
Ma’lumotnoma biror javobni tayyor berish uchun emas, savolni to’g’ri qo’yishga yordam beradi. Talabni aniqlang, kichik misol tuzing, psevdokod yozing, test qiling va faqat keyin sintaksisga o’ting.
Keyingi darsda takrorlash va keyingi qadam — butun bo’limni bitta ish oqimiga jamlaymiz.