murodalidev />

Django’dagi dispatch()metodi - CBV'larning markaziy kirish nuqtasi. Har qanday so'rov (GET, POST va boshqalar) avval shu metoddan o'tadi. Uni override qilib, so'rovni loglash, tekshirish yoki oldindan filtrlash imkoniyati mavjud. Bu method haqida ko'proq o'qishni xohlasangiz shu linkka kiring. @murodalidev ✅

locals()- xavfli qulaylik? Python dasturlash tilida locals() funksiyasi ko‘p hollarda qulay va foydali vosita sifatida ko‘rinadi. Ayniqsa yangi boshlovchilar uchun bu funksiya sehrli tuyulishi mumkin: u hech qanday parametr qabul qilmaydi, lekin sizga butun funksiya kontekstidagi o‘zgaruvchilar ro‘yxatini qaytaradi. Biroq, bu qulaylik ba'zida xavfli odatga aylanishi mumkin.

def test():
    a = 5
    b = 'salom'
    print(locals())

Natija:

{'a': 5, 'b': 'salom'}

Django'da locals()dan foydalanmang: Ayniqsa Django kabi web-frameworklarda locals() funksiyasini render() funksiyasi ichida context sifatida ishlatish - bu anti-pattern deb hisoblanadi.

def my_view(request):
    user = request.user
    time = timezone.now()
    return render(request, 'template.html', locals())

Yuqoridagi kodda siz time degan o'zgaruvchini nomi uzgartirishingiz mumkin va buni template ichida ham o'zgartirib qo'ymasangiz bu xatolikka olib keladi To'gri foydalanich uchun doim contextdan foydalaning:

def my_view(request):
    user = request.user
    now = timezone.now()
    context = {
        'user': user,
        'now': now,
    }
    return render(request, 'template.html', context)

locals() — bu foydali vosita, lekin ehtiyot bo‘lmasangiz, kodni murakkablashtiradi. Django’da bu funksiyani render() context’ida ishlatishdan saqlaning. Har doim aniq va tushunarli yondashuvni tanlang. @murodalidev ✅

locals() funksiyasi haqida: foydali vositami yoki xavfli qulaylik? Python dasturlash tilida locals() funksiyasi ko‘p hollarda qulay va foydali vosita sifatida ko‘rinadi. Ayniqsa yangi boshlovchilar uchun bu funksiya sehrli tuyulishi mumkin: u hech qanday parametr qabul qilmaydi, lekin sizga butun funksiya kontekstidagi o‘zgaruvchilar ro‘yxatini qaytaradi. Biroq, bu qulaylik ba'zida xavfli odatga aylanishi mumkin.

def test():
    a = 5
    b = 'salom'
    print(locals())

Natija: {'a': 5, 'b': 'salom'}

select_for_update - ma'lumotni bloklab turuvchi kuchli qurol! Django'da select_for_update() metodi yordamida bazadagi yozuvni vaqtincha "band qilib" qo‘yish mumkin. Ya'ni, boshqa foydalanuvchilar bu yozuvni o‘zgartira olmaydi - sizning ish tugamaguncha kutadi. Bu race condition yoki data conflict (ma'lumot to‘qnashuvi) oldini olishda juda muhim.

with transaction.atomic():
    obj = MyModel.objects.select_for_update().get(id=1)
    obj.count -= 1
    obj.save()

Bu yerda obj boshqa tranzaksiyalar uchun vaqtincha bloklanadi. Bu - data buzilishining oldini oladi ❗️Faqat atom tranzaksiyalardagina ishlaydi. @murodalidev ✅

@murodalidev ✅

ObjectDoesNotExist vs DoesNotExist ObjectDoesNotExist har qanday model obyekti uchun qo‘llanilishi mumkin, DoesNotExist esa faqat aniq bir modelga tegishli. @murodalidev ✅

Kopchilik dasturchilar "ORM orniga SQL kod yozsang yengilroq ishlaydi" deyishadi, lekin man bu fikrga unchalik ham qo'shilmayman. Agar siz kerakli so‘rovni ORM yordamida osongina yozishingiz mumkin bo‘lsa - bundan unumli foydalaning! @murodalidev ✅

GenericForeignKey Django’da ba’zida bir nechta turli modellarga bir xil bog‘lanish kerak bo‘ladi. Masalan, sizga blog post, mahsulot, video kabi turli obyektlarga izoh (comment) yozish imkoniyati kerak bo‘lsa, har model uchun alohida comment modeli yaratish mashaqqatli. Mana shu holatda Django’da GenericForeignKey yordam beradi. Bu - mos yozuvni turli modellar bilan bog‘laydigan “universial cheklanmagan tashqi kalit”. Ya’ni, bitta Comment modeli turli modellar (BlogPost, Product, Video va boshqalar) bilan ishlay oladi. GenericForeignKey ishlatish qulay ko‘rinsa-da, indexlanmaydi va cheklovlar (integrity constraints) bo‘lmagani uchun ma’lumotlar buzilishi xavfi mavjud. Shuning uchun zarurat bo‘lmasa, oddiy ForeignKey dan foydalanish tavsiya qilinadi. @murodalidev ✅

Og’riqli mavzu!

Nima uchun Service layers'dan foydalanmaslik kerak, muhim sabablarini ko'rib chiqamiz: Murakkablikni joyini almashtirish – uni yo‘qotmaydi: Agar model metodidagi murakkablikni service layerga ko‘chirsangiz, u oddiygina boshqa joyga ko‘chgan bo‘ladi - murakkablik hali ham saqlanib qoladi. Qo‘shimcha abstraction - qo‘shimcha yuk: Service layer qo‘shilishi bilan siz kod bazangizga yangi qatlam qo‘shasiz, bu yangi developerlarga tushunishni qiyinlashtiradi, kodni kuzatish va test qilishni murakkablashtiradi. Django’ning o‘z modeli - bu biznes logika uchun yetarli: Django modeli, manager va queryset orqali biznes logikani joylashtirish uchun yetarli darajada kuchli. Test qilish uchun to‘liq ajratish zararli bo‘lishi mumkin: Testlar uchun ORM’ni butunlay ajratish ko‘pincha noto‘g‘ri ishonchga olib keladi, chunki real tizimdagi muhim omillar (masalan, ma'lumotlar bazasi) e'tibordan chetda qoladi. Yaxshi dizayn — service layer emas, balki dizayn patternlari orqali yechiladi: Katta tizimlarda murakkablikni boshqarish uchun yaxshi arxitektura, masalan: - Pub/Sub pattern - Observer - Command pattern kabi uslublar ko‘proq foyda beradi. Django o‘zining Active Record ORM modelida biznes logikani joylashtirish uchun yetarlicha vositalarga ega va qo‘shimcha qatlamlar ko‘proq zarar keltirishi mumkin. @murodalidev ✅

Django loyihalaringizda Service Layers ishlatishni bas qiling. @murodalidev ✅

⚙️ Django ilova dizaynining oltin qoidasi: Django asosiy ishlab chiquvchilaridan biri bo‘lgan James Bennett bizga yaxshi Django ilovasi qanday yaratilishi va boshqarilishi kerakligini o‘rgatgan. U quyidagi fikrni keltirgan:

Yaxshi Django ilovasi yaratish va uni saqlash san’ati shundan iboratki, u Unix falsafasining qisqartirilgan shaklini bajara olishi kerak. Douglas McIlroy aytganidek: "Dasturlarni bitta ishni bajaradigan va uni juda yaxshi bajaradigan qilib yozing."

Bu nimani anglatadi? Har bir Django ilovasi (app) aniq bitta vazifaga yo‘naltirilgan bo‘lishi kerak. Agar siz yozgan ilovani bitta o‘rtacha uzunlikdagi jumlada tushuntira olmasangiz yoki uni izohlashda “va” (yoki “ham”) so‘zini bir necha marta ishlatishga to‘g‘ri kelsa, bu — ilova haddan tashqari ko‘p funksiyani o‘z ichiga olgan, ya’ni uni bo‘lib chiqish va soddalashtirish kerak degani. Yaxshi loyihalar kichik, tushunarli va boshqarilishi oson bo‘lgan ilovalardan tuzilgan bo‘ladi. Har bir ilova o‘z vazifasini aniq bajaradi va qolganlar bilan minimal bog‘liq bo‘ladi. Shu yondashuv orqali siz uzoq muddatda barqaror va kengaytiriladigan Django loyihalarini yaratishingiz mumkin. @murodalidev ✅

Real NoCode application https://github.com/kelseyhightower/nocode

Noto’g’ri kod yozsang, lekin u kod to’g’ri ishlasa: @murodalidev ✅

Mavjud loyiha qoidalarini o‘zgartirmang: PEP 8 uslubi asosan yangi Django loyihalari uchun amal qiladi. Agar siz avvaldan mavjud bo‘lgan Django loyihasiga qo‘shilsangiz va u PEP 8’dan farq qiladigan konvensiyalarga (yozish qoidalariga) amal qilayotgan bo‘lsa, siz ham o‘sha mavjud qoidalarga rioya qilishingiz kerak. Buning sabablari va boshqa hollarda “qoidani buzish” mumkin bo‘lgan vaziyatlar haqida PEP 8 hujjatidagi “A Foolish Consistency is the Hobgoblin of Little Minds” bo‘limini o‘qib chiqing. @murodalidev ✅

Dasturlar odamlar o‘qishi uchun yozilishi kerak, kompyuterlar esa faqat bajarish uchun. Kod yozish oson, lekin uni debug qilish bir necha daqiqa yoki hatto soatlab vaqt olishi mumkin. Va ba’zida u kod yillar davomida o‘zgarmay turadi. Ertaga yoki o‘n yil o‘tib o‘sha kodga siz yoki boshqa dasturchi qaytib kelganida, uning aniq, tushunarli va izchil yozilgan bo‘lishi nihoyatda foydali bo‘ladi. Tushunarli yozilgan kod miya yukini kamaytiradi, ya’ni turli chalkashliklarni tushunishga energiya sarflanmaydi. Bu esa har qanday hajmdagi loyihani saqlash va takomillashtirishni ancha osonlashtiradi.

Yaxshi dasturchi kodni faqat mashina uchun emas, uni keyin o‘qiydigan boshqa odamlar uchun yozadi. Zotan Kod — bu kommunikatsiya vositasi.

@murodalidev ✅

"KISS" so'zini dasturchilar qanday tushunishadi, ko'ramiz: Dasturiy loyihalar yaratishda, har bir ortiqcha murakkablik yangi funksiyalar qo‘shishni va mavjudlarini saqlab turishni qiyinlashtiradi. Eng oddiy yechimni tanlashga harakat qiling, lekin ayni paytda haddan tashqari soddalashtirilgan, noto‘g‘ri taxminlarga asoslangan yechimlarni amalga oshirmaslikka e’tibor bering. Bu tushuncha ba’zida “KISS” (Keep It Simple, Stupid) qisqartmasi bilan ifodalanadi. KISS - Keep It Simple, Stupid @murodalidev ✅

Kredit va Deposit(Omonat) qiymatlarini hisoblab beradigan kutbxonamni sizlarga ulashmoqchiman Yuklab olish uchun:

pip install credit-deposit-calculator

Batafsil o'qish uchun: https://pypi.org/project/credit-deposit-calculator/ ps: sizda ham bunday tasklar mavjud bo'lsa bemalol olib ishlatishingiz mumkin😊 @murodalidev ✅

Qiziq Python tilining falsafasi nima o'zi? "The Zen of Python" (Python tilining falsafasi) - Keling buni o'rganamiz, Python dasturlash tilining 19ta falsafi bor, tilning falsafasini yaxshi o'rganishga va tushunishga harakat qiling, kodlaringizni bu falsafalarga mos qiling yozing. Bu falsafalarni ko'rish uchun Python terminalda quyidani kodni yuriting,

import this

@murodalidev ✅