🚀 Loyiha boshlashda eng muhim qadamlardan biri – reja va arxitektura

Ko‘pchilik developerlar kod yozishni iloji boricha tezroq boshlashni xohlaydi. Lekin yaxshi o‘ylangan reja va to‘g‘ri tanlangan arxitektura dizayni – loyihaning kelajakdagi barqarorligi va kengayishiga zamin yaratadi.

🔑 Nega muhim?

Qayta yozish (refactor) va xatoliklarni kamaytiradi

Katta jamoada ishlashni osonlashtiradi

Texnik qarz (technical debt) oldini oladi

Loyihani tezroq rivojlantirishga yordam beradi

💡 Shunday ekan, codingni boshlashdan avval, vaqt ajratib reja tuzing, arxitektura chizing va keyin kodga o‘ting. Bu kelajakda sizga ko‘p vaqt va asabni tejaydi.

Motivatsiya < Intizom
[chaqmoq izidan yurmang]

Shu kunlarda g‘ayratlantirish (motivatsiya) kurslari juda ko‘payib ketdi. Boshida foydali ko‘rindi. Vaqt o‘tib, hammasi yuzaga chiqa boshladi.

Biz bizga buyurilgan intizomni tark etdik. Bu Motivatorlarni ko‘payishiga olib keldi.

Motivatsiya chaqmoqqa o‘xshaydi – u birdaniga paydo bo‘ladi, ko‘p energiya beradi va hamma narsani yoritadi. Lekin u bir zumda o‘tib ketadi va ortidan yana qorong‘ulik qoladi. Intizom esa shamga o‘xshaydi – uning nuri kuchli bo‘lmasligi mumkin, lekin u tinmay yonadi. U sizni uzoq muddatli yo‘lingizda doimiy ravishda olg‘a boshlaydi. Sizga bir lahzalik porlash kerakmi yoki uzoq muddatli yorug‘lik?

“Phoenix project” kitobida yangi CTO xatolarini o‘rganish uchun mutaxassisga boradi. Fikrlar orasida shu fikr ham bor edi:

Tadqiqotlar shuni ko‘rsatdi-ki, kuniga 5 daqiqa shug‘ullanish haftada bir 3 soat shug‘ullanishdan yaxshiroq.

Nega?
Chunki intizom kichik, doimiy qadamlardan iborat. Aynan shu kichik harakatlar, kichik g‘alabalar bizga maqsadimizga yetishish uchun barqaror zamin yaratadi. G‘arbdagi ko‘plab muvaffaqiyatli insonlar aynan shu tamoyilga amal qilishadi: ular hasharlar uyushtirmaydi, ular har kuni oz-ozdan o‘z vazifalarini bajarib borishadi.

Niyatim kimnidir tanqid qilish emas.

Niyatim - esdan chiqib borayotgan intizomimizni qayta tiklashga chaqirish.

Shunday ekan, o‘zimizga bir savol beraylik: bizga bir lahzalik chaqmoq kerakmi yoki hayotimizni nurga to‘ldiruvchi doimiy sham?

03.09.2025 London
@DrAlgorith

💡 AWS IAM'da eng katta xato nima?
Ko'p kompaniyalar Root account bilan ishlashda davom etishadi! 🚫
✅ To'g'ri yondashuv:

1. Root accountni yashiring
2. Har bir xodim uchun alohida user yarating
3. Grouplar orqali ruxsatlarni boshqaring
4. Minimum zarur huquqlar berish tamoyili

🇰🇷 Koreyadagi kompaniyalar AWS servicelaridan juda ko'p foydalanishadi, shuning uchun bu ma'lumotlar ayniqsa foydali bo'lishi mumkin!
🔥 Pro tip: Charles kabi userlar bir vaqtda Development VA Operations ishlarini qilishi mumkin - shunchaki ikkala groupga qo'shing!
Sizning kompaniyangizda IAM qanday tashkil etilgan?
#AWS #Cybersecurity #Korea #BestPractices #ITTips

🔎 AWS EC2 va boshqa xizmatlarning instansiyalarini taqqoslash uchun qulay manba

Regionlar, resurslar va narxlar bo‘yicha tezkor qidiruv — FinOps va DevOps’lar uchun haqiqiy topilma😊.

https://instances.vantage.sh/

Professional "Yo‘q" deyish

Bilarmidingiz? Rahbaringiz aslida sizdan "Yo‘q" deyishingizni kutadi.

Har bir rahbar o‘z jamoasida "labbaychi", har bir topshiriqqa "xo‘p bo‘ladi" deydigan, savol bermasdan ishga kirishib ketadigan xodimlarni yoqtiradi, - deb o‘ylashadi. Yuzaki qaraganda shunday: kamroq muhokama, tezroq ishga kirishish. Lekin bu muvaffaqiyatsizlikka olib boradi.

Kitobda qiziq gap o‘qib qoldim. Erik ismli qahramon aytgan gapi bor, bu gap har bir rahbar ish stoliga yozib qo‘yishiga arziydi:

"Albatta, siz "Yo‘q" deyishingiz mumkin. Biz sizga fikrlashingiz uchun haq to‘laymiz, shunchaki ishni bajarish uchun emas."

"Of course you can say No. We pay you to think, not to do."


Nima uchun "Ha, xo‘p bo‘ladi"chi xodimlar xavfli?

Tasavvur qiling, men jamoaga yangi bir loyiha ustida ishlashni topshirdim. Dasturchi hech qanday savol bermasdan, darhol kod yozishni boshladi. Ikki haftadan so‘ng u ishni tugatdi. Ammo keyin ma’lum bo‘ladiki:

1. Bu ish boshqa bir modul bilan ziddiyat hosil qilgan.

2. Loyihani yaratishda qo‘llanilgan yondashuv kelajakda katta "texnik qarz" (technical debt) qoldirgan.

3. Aslida, bundan ancha samaraliroq va tezroq yechim mavjud edi, lekin hech kim bu haqda o‘ylab ko‘rmagan.

Natijada nima bo‘ldi?

Vaqt, pul va eng asosiysi - jamoaning ishtiyoqi behuda sarflandi. Agar o‘sha dasturchi yoki jamoa boshida "Yo‘q, bu yondashuv to‘g‘ri emas, chunki..." deb aytganida, biz bu isrofgarchilikning oldini olgan bo‘lardik.

Qanday qilib to‘g‘ri "Yo‘q" deyish mumkin?

"Yo‘q" deyish – bu qo‘pollik yoki bo‘ysunmaslik emas. Bu – professional mas’uliyat. Muhimi, buni to‘g‘ri yetkazib bera olish.

1. "Yo‘q, chunki..." formulasidan foydalaning.
Shunchaki "yo‘q, qilolmayman" demang. Sababini aniq va raqamlarga asoslanib tushuntiring.

Salbiy: "Yo‘q, bu vazifani bugun qila olmayman."

Ijobiy: "Yo‘q, bu vazifani bugun bajara olmayman, chunki hozirda men A loyihasining muhim qismi ustida ishlayapman. Agar chalg‘isam, ertangi reliz kechikishi mumkin. Bu esa korxonamiz uchun X miqdorida zarar keltirishi ehtimoli bor."

2. Muqobil yechim taklif qiling.
Siz muammoning bir qismi emas, yechimning bir qismi ekanligingizni ko‘rsating.

Salbiy: "Bu funksiyani ikki kunda qo‘shib bo‘lmaydi."

Ijobiy: "Bu funksiyani to‘liq hajmda ikki kunda qo‘shishning imkoni yo‘q. Lekin, biz eng muhim qismini (MVP) ertaga tayyor qilib berishimiz mumkin. Yoki, agar bizga to‘rt kun vaqt berilsa, uni barcha testlardan o‘tkazib, barqaror versiyasini taqdim etamiz. Qaysi biri biz uchun hozir muhimroq?"

3. Ustuvorliklarni (prioritetlarni) aniqlashtiring.

Ba’zida rahbariyat (yoki buyurtmachi) barcha vazifalar birdek muhim deb o‘ylaydi. Sizning vazifangiz - ularga haqiqiy vaziyatni ko‘rsatish.

Savol bering: "Tushundim, bu juda muhim. Hozir men ishlayotgan A va B vazifalar bilan solishtirganda, bu yangi topshiriqning ustuvorligi qanday? Agar buni boshlasam, qaysi birini kechiktirsam bo‘ladi?"


Xulosa

Sizning ishingiz – shunchaki kod yozish, dizayn chizish yoki jadval to‘ldirish emas. Sizning ishingiz - korxonaning umumiy maqsadiga erishish uchun o‘z tajribangiz va aqlingizni ishlatishdir.

Buning ichiga xavflarni oldindan ko‘ra bilish, noto‘g‘ri qarorlarni shubha ostiga olish va yaxshiroq yo‘llarni taklif qilish ham kiradi.

Agar sizga biror vazifa berilsa, bir zum to‘xtang. O‘zingizga savol bering:
* Bu vazifaning asl maqsadi nima?
* Nima uchun aynan shu yo‘l tanlandi?
* Bundan yaxshiroq, tezroq yoki arzonroq yechim yo‘qmi?
* Bu ish kelajakda qanday muammolarga olib kelishi mumkin?

Agar javoblaringiz sizni qoniqtirmasa, o‘z fikringizni aytishdan qo‘rqmang. Asosli dalillar bilan aytilgan "Yo‘q" — bu korxonaga qilingan eng katta yaxshilikdir.

Unutmang, siz shunchaki klaviaturani bosishingiz yoki qog‘ozlarni to‘ldirishingiz uchun oylik olmaysiz. Siz tajribangiz, bilimingiz va eng muhimi - fikrlash qobiliyatingiz uchun haq olasiz.

Shunday ekan, keyingi safar topshiriq olganingizda, o‘ylang.
Agar kerak bo‘lsa, o‘z professional lug‘atingizdagi eng qudratli so‘zni ishlating: "Yo‘q, chunki..."

10.09.2025 London
@DrAlgorithm

🎙 Bugun men ham mehmon sifatida MashaqqaTV podkastida qatnashaman!
Dasturchilik, hayot, tajriba va motivatsiya haqida jonli suhbat bo‘ladi.

🕕 UZB vaqti: 18:00
🕙 KR vaqti: 22:00
📍 Jonli efir: YouTube’da tomosha qiling
🎧 Instagram: @MashaqqaTV

Savollaringizni yozib qoldiring — suhbat davomida ularga javob beramiz! 💬

Assalom Aleykum!
Bugun sizlar bilan bosh qotiradigan bir qiziq keysni bo'lishmoqchiman. Yuqoridagi sxemaga bir qarang.

Ikki xil tarmoq bor:

1. Bizning serverimiz (u 172.30.1.x tarmog'ida)
2. O'zicha yopiq ishlaydigan NVR va kameralar (bular 10.10.x.x tarmog'ida)

Vazifa: O'sha serverga kameralardan jonli video (stream)ni olib kelishim kerak.

Muammo: Bu ikkita tarmoq bir-biri bilan umuman "gaplashmaydi", o'rtada hech qanday aloqa yo'q.

❗️Eng asosiy sharti: NVR va kameralarning hozirgi ulanishiga (sxemadagi "S-1 networks") umuman tegilmasligi, ularning ishi buzilmasligi kerak.

Xo'sh, qanday yo'l tutamiz? Qanday qilib bu ikki tarmoqni "uchrashtirsa" bo'ladi?

G'oyalaringizni kutaman!

#network #idea

Yuqoridagi masala mana shu takllif bilan osongina hal qilindi, Bugun tehnik testlar muvaffaqiyatli o'tdi 💪 😊

Dasturlash faqat kod yozish emas: Risk Menejment va "Kichik zarar" falsafasi ⚖️

Dasturchi sifatida ko‘pincha "Ideal Arxitektura" qurishga intilamiz. Ma'lumotlar 100% butun, hammasi real-time, xatolik nolga teng bo‘lishini xohlaymiz. Lekin yaqinda bir loyihada Biznes va Texnologiya to‘qnashdi, va "Eng to‘g‘ri yechim" har doim ham "Mukammal kod" emasligini tushundim.

Dilemma quyidagicha edi: Katta tarqoq (distributed) tizimda internet uzilib qolganda nima qilish kerak?

Xizmatni to‘xtatish: Tizim xavfsiz bo‘ladi, ma’lumotlar buzilmaydi. Lekin biznes mijozlarni yo‘qotadi va daromad to‘xtaydi.

Ishlashda davom etish: Mijoz xursand, daromad bor. Lekin eski ma'lumot (kesh) asosida ishlagani uchun, kompaniya moliyaviy zarar ko‘rish ehtimoli bor.

Bu yerda masala texnik muammodan chiqib, Risk Menejment masalasiga aylandi.

Biz qanday yo‘l tutdik? Biz "Zararlarning eng kamini tanlash" (Lesser of two evils) prinsipiga o‘tdik. Tizimni 100% sinxronizatsiya qilishga urinib, serverlarni qiynash yoki oflayn rejimni butunlay yopish o‘rniga, "Cheklovli Ishonch" (Limited Trust) modelini qo‘lladik.

Ya'ni: "Mayli, oflayn rejimda ishlayver, lekin kompaniya ko‘tarishi mumkin bo‘lgan minimal summa/limitgacha."

Xulosa: Senior darajaga chiqish nafaqat kodni optimizatsiya qilish, balki biznes xatarlarini optimizatsiya qilish ham ekan. Ba'zida biznesga "Buni texnik jihatdan qilish qimmat" deyish o‘rniga, "Keling, mana bu kichik xatarga rozi bo‘lamiz, evaziga tizim barqaror ishlaydi" degan yechimni berish — haqiqiy muhandislikdir.

Mukammallik — bu xatolar yo‘qligi emas, balki xatolar boshqariladigan darajada ekanligidir.

PS: oxirgi jumla sekin internetda eplashtirildi. 😉