Tasavvur qiling: siz Google'da ishlaysiz. Siz beixtiyor qilgan xato sabab dunyo bo'ylab YouTube ishlamay qoldi.
1-savol: Endi nima bo'ladi?
2-savol: Endi sizning kompaniyadagi taqdiringiz nima bo'ladi?
~~~~~~~~~
• Birinchi bo'lib, YouTube'ning uzluksiz ishlashini kuzatib turadigan SRE jamoalari bundan xabar topishadi. Navbatchi SRE injenerlari darhol holat qay darajada yomon ekanligini aniqlab, boshqalarga xabar beradi.
• Vaziyat jiddiyligiga qarab, boshqa muhim odamlar yordamga chaqiriladi. Eng birinchi vazifa – tezroq YouTube'ni tiklash: Muammo nimadan kelib chiqqanini aniqlab, uni bartaraf etish. Bunday vaziyatda sabablarni to'liq tushunib yetish 2-darajali masala.
• Bir paytning o'zida bir nechta jamoalar tomonidan har xil nazariyalar ko'rib chiqiladi:
- Aloqadagi mummolar;
- Dasturdagi ohirgi o'zgarishlar;
- DDOS hujumi va hokazo.
• Foydalanuvchilarga ijtimoiy tarmoqlar orqali vaziyat haqida tez-tez xabar berib turiladi: Nima bo'lyapti, nimalar aniqlandi, qachon ishga tushadi.
• Sabab aniqlanishi bilanoq uni to'g'rilab, YouTube'ni progressiv tarzda ishga tushiriladi: avval kichikroq hududlar, keyin boshqalarida. Bunday qilishdan maqsad – YouTube tiklanayotgan paytda bir data-markaziga kuchlanish ortib ketishi oqibatida boshqa muammolar kelib chiqishining oldini olish.
• Shunday qilib, YouTube to'liq tiklanadi. Bunga soatlab vaqt ketishi mumkin.
~~~~~~~~~
Bu vaqt ichida siz ham barcha qatori YouTube'ni "jonlantirish" ustida ishlayapgan bo'lasiz. Vaziyat o'z o'rniga qaytgandan keyin muammo ustida ishlaganlar uning kelib-chiqish sabablarini chuqur tahlil qilishadi.
"Muhammadjon ish ko'rsatib qo'yibdi", "Bu muammo Vohidjon qilgan xato sabab kelib chiqibdi", "Rustamga hayfsan e'lon qilamiz yoki uni ishdan olamiz", degan gaplarni eshitmaysiz. Aksincha, "Bu muammo tizimdagi quyidagi xatolik sababli kelib chiqibdi", "Shunga o'xshash beixtiyor xatolar ro'y berganida uni tutish uchun bunday test yoki himoya tizimi ishlab chiqish kerak" kabi yechimlar muhokama qilinadi.
Siz katta ehtimollik bilan "Postmortem" yozasiz (hodisada qatnashgan boshqa ishtirokchilar bilan). Google'da "Postmortem" – bu yuqoridagi kabi muammo haqida tahliliy hujjat bo'lib, unda quyidagilar bo'ladi:
• Muammodan qanday xabar topildi?
• Sabablar qanday aniqlandi?
• Har bir harakat va voqeaning aniq vaqti.
• Yechim nima bo'ldi?
• Sabablar qayerdan kelib chiqdi?
• Talofat qay darajada bo'ldi?
• Bu hodisadan nimalar o'rganildi?
• Shunday xatolik yana takrorlanmasligi uchun qanday o'zgarishlar qilindi va hokazolar.
Bu hujjat juda muhim hisoblanib, boshqa injenerlar bundan o'rganishadi. Kelajakda yana "crash"lar bo'lganida undan foydalaniladi.
Shunday vaziyatlarda Google'ning ichki madaniyati dars olish, xulosa chiqarish va kimnidir barmoq bilan ko'rsatmaslikdir: "Blameless Postmortem Culture".
@muhammadjohns
1-savol: Endi nima bo'ladi?
2-savol: Endi sizning kompaniyadagi taqdiringiz nima bo'ladi?
• Birinchi bo'lib, YouTube'ning uzluksiz ishlashini kuzatib turadigan SRE jamoalari bundan xabar topishadi. Navbatchi SRE injenerlari darhol holat qay darajada yomon ekanligini aniqlab, boshqalarga xabar beradi.
• Vaziyat jiddiyligiga qarab, boshqa muhim odamlar yordamga chaqiriladi. Eng birinchi vazifa – tezroq YouTube'ni tiklash: Muammo nimadan kelib chiqqanini aniqlab, uni bartaraf etish. Bunday vaziyatda sabablarni to'liq tushunib yetish 2-darajali masala.
• Bir paytning o'zida bir nechta jamoalar tomonidan har xil nazariyalar ko'rib chiqiladi:
- Aloqadagi mummolar;
- Dasturdagi ohirgi o'zgarishlar;
- DDOS hujumi va hokazo.
• Foydalanuvchilarga ijtimoiy tarmoqlar orqali vaziyat haqida tez-tez xabar berib turiladi: Nima bo'lyapti, nimalar aniqlandi, qachon ishga tushadi.
• Sabab aniqlanishi bilanoq uni to'g'rilab, YouTube'ni progressiv tarzda ishga tushiriladi: avval kichikroq hududlar, keyin boshqalarida. Bunday qilishdan maqsad – YouTube tiklanayotgan paytda bir data-markaziga kuchlanish ortib ketishi oqibatida boshqa muammolar kelib chiqishining oldini olish.
• Shunday qilib, YouTube to'liq tiklanadi. Bunga soatlab vaqt ketishi mumkin.
Bu vaqt ichida siz ham barcha qatori YouTube'ni "jonlantirish" ustida ishlayapgan bo'lasiz. Vaziyat o'z o'rniga qaytgandan keyin muammo ustida ishlaganlar uning kelib-chiqish sabablarini chuqur tahlil qilishadi.
"Muhammadjon ish ko'rsatib qo'yibdi", "Bu muammo Vohidjon qilgan xato sabab kelib chiqibdi", "Rustamga hayfsan e'lon qilamiz yoki uni ishdan olamiz", degan gaplarni eshitmaysiz. Aksincha, "Bu muammo tizimdagi quyidagi xatolik sababli kelib chiqibdi", "Shunga o'xshash beixtiyor xatolar ro'y berganida uni tutish uchun bunday test yoki himoya tizimi ishlab chiqish kerak" kabi yechimlar muhokama qilinadi.
Siz katta ehtimollik bilan "Postmortem" yozasiz (hodisada qatnashgan boshqa ishtirokchilar bilan). Google'da "Postmortem" – bu yuqoridagi kabi muammo haqida tahliliy hujjat bo'lib, unda quyidagilar bo'ladi:
• Muammodan qanday xabar topildi?
• Sabablar qanday aniqlandi?
• Har bir harakat va voqeaning aniq vaqti.
• Yechim nima bo'ldi?
• Sabablar qayerdan kelib chiqdi?
• Talofat qay darajada bo'ldi?
• Bu hodisadan nimalar o'rganildi?
• Shunday xatolik yana takrorlanmasligi uchun qanday o'zgarishlar qilindi va hokazolar.
Bu hujjat juda muhim hisoblanib, boshqa injenerlar bundan o'rganishadi. Kelajakda yana "crash"lar bo'lganida undan foydalaniladi.
Shunday vaziyatlarda Google'ning ichki madaniyati dars olish, xulosa chiqarish va kimnidir barmoq bilan ko'rsatmaslikdir: "Blameless Postmortem Culture".
@muhammadjohns
O'qishni bitirib, eng birinchi ishimga qabul qilinganimga 7 yil bo'libdi. Bu orada 2 yil magistraturada o'qiganim va boshqa uzilishlarni hisobga olsam, 5 yilga yetmagan professional tajribam bor ekan. Shu 5 yillik tajribam mobaynida juda ko'p dasturchilar bilan birga ishladim, muloqot qildim, ko'pchilikdan muhim bilimlarni o'rgandim. Ular ichida "junior"dan tortib, "principal" dasturchilargacha bor.
Shu injenerlarning ishlarini kuzatish orqali va tajribam o'sib borgan sari ZO'R dasturchining YAXSHI dasturchidan farqini tushunib yetyapman. Ularning farqlarini birma-bir sanab o'tirmoqchi emasman, lekin zo'r dasturchilarning aksariyatida bir sifat bor: "Engineering Excellence". O'zbek tilida aytganda – "Muhandislik Kamoloti".
"Engineering Excellence" bu – dasturchilikning har bir qismida eng yaxshi standard/amaliyotlarni qo'llashga harakat qilishdir:
• Dastur yaratishda;
• Dasturni sinovdan o'tkazishda;
• Boshqalar bilan muloqot qilishda va birga ishlash mobaynida;
• Muammolarga yechim topishda;
• Jamoani boshqarishda va hokazo.
Masalan, dasturning bir kichik (tahminan 2-3 hafta vaqt oladigan) qismini 2 xil dasturchiga topshirildi.
• Yaxshi dasturchi berilgan muammoga zo'r yechim topadi, uni sifatli va vaqtida tugatib, topshiradi.
• Zo'r dasturchi muammoga bir nechta yechimlar o'ylab, hammasining prototipini tezda qilib ko'radi, ularni bir hujjatga yozib, boshqalarga ko'rsatib, muhokama qiladi. Kelib chiqishi mumkin bo'lgan risklarni tahlil qiladi. Yechimlar ichidan eng yaxshisini tanlab, sifatli hamda vaqtida tugatadi.
--------
Engineering Excellence'ni o'rganishga ozroq tajriba kerak, lekin u shunchaki tajriba oshgani sari o'zlashtirib olinadigan narsa emas. Junior bo'lib turib ham hozirdanoq uni qo'llashni boshlash mumkin. Yoki aksincha, senior bo'lib turib ham unga amal qilmaslik mumkin. Uni o'rganish uchun xohish va qunt kerak.
Keyingi postlarimda Engineering Excellence'ga oid ma'lumotlarni va shaxsiy tajribalarimdan misollarni ulashib bormoqchiman. Qiziq bo'lsa, kuzatib boring.
PS: O'zimni hali zo'r dasturchi, deb hisoblamayman.
#engineeringexcellence
@muhammadjohns
Shu injenerlarning ishlarini kuzatish orqali va tajribam o'sib borgan sari ZO'R dasturchining YAXSHI dasturchidan farqini tushunib yetyapman. Ularning farqlarini birma-bir sanab o'tirmoqchi emasman, lekin zo'r dasturchilarning aksariyatida bir sifat bor: "Engineering Excellence". O'zbek tilida aytganda – "Muhandislik Kamoloti".
"Engineering Excellence" bu – dasturchilikning har bir qismida eng yaxshi standard/amaliyotlarni qo'llashga harakat qilishdir:
• Dastur yaratishda;
• Dasturni sinovdan o'tkazishda;
• Boshqalar bilan muloqot qilishda va birga ishlash mobaynida;
• Muammolarga yechim topishda;
• Jamoani boshqarishda va hokazo.
Masalan, dasturning bir kichik (tahminan 2-3 hafta vaqt oladigan) qismini 2 xil dasturchiga topshirildi.
• Yaxshi dasturchi berilgan muammoga zo'r yechim topadi, uni sifatli va vaqtida tugatib, topshiradi.
• Zo'r dasturchi muammoga bir nechta yechimlar o'ylab, hammasining prototipini tezda qilib ko'radi, ularni bir hujjatga yozib, boshqalarga ko'rsatib, muhokama qiladi. Kelib chiqishi mumkin bo'lgan risklarni tahlil qiladi. Yechimlar ichidan eng yaxshisini tanlab, sifatli hamda vaqtida tugatadi.
--------
Engineering Excellence'ni o'rganishga ozroq tajriba kerak, lekin u shunchaki tajriba oshgani sari o'zlashtirib olinadigan narsa emas. Junior bo'lib turib ham hozirdanoq uni qo'llashni boshlash mumkin. Yoki aksincha, senior bo'lib turib ham unga amal qilmaslik mumkin. Uni o'rganish uchun xohish va qunt kerak.
Keyingi postlarimda Engineering Excellence'ga oid ma'lumotlarni va shaxsiy tajribalarimdan misollarni ulashib bormoqchiman. Qiziq bo'lsa, kuzatib boring.
PS: O'zimni hali zo'r dasturchi, deb hisoblamayman.
#engineeringexcellence
@muhammadjohns
Dasturchilik Kamoloti. 1-qism.
Kod sifati - Dasturlash tili standartlari
Bir necha yillik tajribaga ega aksariyat dasturchilar tabiiy ravishda o'zlarining shaxsiy kod yozish uslublarini yaratishadi. Masalan, o'zgaruvchilarni nomlashda va dastur kodini "package/module"larga ajratishda. Bunday uslubga ega bo'lishning ko'p ustunliklari bor: tezroq kod yozasiz, kod o'zingiz uchun tushunarliroq bo'ladi va hkz.
Jamoaviy proyektlarda, shu jumladan, ishingizda to'liq o'z uslubingizda yozishingiz to'g'rimi?
Har bir dasturlash tilining o'z standarti, tavsiya etilgan qoidalari mavjud. Ularni "<dasturlash tili> style guide", deb qidirib, topsangiz bo'ladi: "Python style guide", "Kotlin style guide". Ushbu qoidalar dasturlash tilini yaratganlar yoki uni yangilab boradiganlar tomonidan ishlab chiqilgan bo'lib, tildan foydalanishdagi eng yaxshi amaliyotlarni o'z ichiga oladi. Ba'zi kompaniyalar o'sha qoidalarni yanada rivojlantirib, kompaniya uchun ichki qoidalarni yaratishi (yoki rasmiy style-guide'dan foydalanishni talab qilishi) mumkin.
Siz, avvalo, shu standartlarni o'z uslubingizdan ustun qo'yishingiz kerak.
Bunday qoidalar nimaga kerak?
Kod yozishda ham hammaning ta'bi har xil bo'ladi. Bir odamning kodi boshqa odamga tushunish uchun qiyinlik qilishi mumkin. Bir xil standartdan foydalanish esa shunday tafovutlarni kamaytiradi va kod o'qishni osonlashtiradi.
Kod o'qishga kod yozishdan ko'ra 10 barobar ko'p vaqt sarflaysiz! Kodning hamma uchun tushunarli bo'lishi – juda muhim.
Standartlardan foydalanishni qanday boshlash kerak?
Style-guide'lar shunchaki o'qib chiqsangiz, esda qolmasligi mumkin. Keyingi safar shunday qiling:
• Kod yozishdan oldin o'zingiz ishlaydigan kompaniyada siz ishlatayotgan dasturlash tili uchun style-guide bor-yo'qligini tekshiring.
• Agar bo'lmasa, rasmiy style-guideni toping (o'qishingiz shart emas, faqat toping).
• Ozroq kod yozganingizdan keyin kodingizda nimalardan foydalanganingizga e'tibor bering (class, function, conditions, filters, ...).
• Keyin style-guide'dan o'shalar uchun berilgan tavsiyalarni o'rganib, kodingizni to'g'rilang.
Boshida bu ko'p vaqt olishi mumkin, lekin vaqt o'tgan sari qoidalar esingizda qolib, kodingiz sifati oshadi.
Jamoangiz bunday qoidalardan umuman foydanmaydimi?
Siz boshlab bering. Boshqalarga namuna bo'ling. Boshqa dasturchilarga ham shunday qilishni tavsiya qiling.
Happy coding!
#engineeringexcellence
@muhammadjohns
Kod sifati - Dasturlash tili standartlari
Bir necha yillik tajribaga ega aksariyat dasturchilar tabiiy ravishda o'zlarining shaxsiy kod yozish uslublarini yaratishadi. Masalan, o'zgaruvchilarni nomlashda va dastur kodini "package/module"larga ajratishda. Bunday uslubga ega bo'lishning ko'p ustunliklari bor: tezroq kod yozasiz, kod o'zingiz uchun tushunarliroq bo'ladi va hkz.
Jamoaviy proyektlarda, shu jumladan, ishingizda to'liq o'z uslubingizda yozishingiz to'g'rimi?
Har bir dasturlash tilining o'z standarti, tavsiya etilgan qoidalari mavjud. Ularni "<dasturlash tili> style guide", deb qidirib, topsangiz bo'ladi: "Python style guide", "Kotlin style guide". Ushbu qoidalar dasturlash tilini yaratganlar yoki uni yangilab boradiganlar tomonidan ishlab chiqilgan bo'lib, tildan foydalanishdagi eng yaxshi amaliyotlarni o'z ichiga oladi. Ba'zi kompaniyalar o'sha qoidalarni yanada rivojlantirib, kompaniya uchun ichki qoidalarni yaratishi (yoki rasmiy style-guide'dan foydalanishni talab qilishi) mumkin.
Siz, avvalo, shu standartlarni o'z uslubingizdan ustun qo'yishingiz kerak.
Bunday qoidalar nimaga kerak?
Kod yozishda ham hammaning ta'bi har xil bo'ladi. Bir odamning kodi boshqa odamga tushunish uchun qiyinlik qilishi mumkin. Bir xil standartdan foydalanish esa shunday tafovutlarni kamaytiradi va kod o'qishni osonlashtiradi.
Kod o'qishga kod yozishdan ko'ra 10 barobar ko'p vaqt sarflaysiz! Kodning hamma uchun tushunarli bo'lishi – juda muhim.
Standartlardan foydalanishni qanday boshlash kerak?
Style-guide'lar shunchaki o'qib chiqsangiz, esda qolmasligi mumkin. Keyingi safar shunday qiling:
• Kod yozishdan oldin o'zingiz ishlaydigan kompaniyada siz ishlatayotgan dasturlash tili uchun style-guide bor-yo'qligini tekshiring.
• Agar bo'lmasa, rasmiy style-guideni toping (o'qishingiz shart emas, faqat toping).
• Ozroq kod yozganingizdan keyin kodingizda nimalardan foydalanganingizga e'tibor bering (class, function, conditions, filters, ...).
• Keyin style-guide'dan o'shalar uchun berilgan tavsiyalarni o'rganib, kodingizni to'g'rilang.
Boshida bu ko'p vaqt olishi mumkin, lekin vaqt o'tgan sari qoidalar esingizda qolib, kodingiz sifati oshadi.
Jamoangiz bunday qoidalardan umuman foydanmaydimi?
Siz boshlab bering. Boshqalarga namuna bo'ling. Boshqa dasturchilarga ham shunday qilishni tavsiya qiling.
Happy coding!
#engineeringexcellence
@muhammadjohns
Goodreads
A quote from Clean Code
Indeed, the ratio of time spent reading versus writing is well over 10 to 1. We are constantly reading old code as part of the effort to write new code. ...
Kod sifati - "Toza kod" yozish
Dasturlash tili standartlariga rioya qilish kodingiz sifatini biroz oshiradi. Kod sifatini yanada oshirish uchun keyingi qadam – "toza kod" yozish.
Ko'pchiligimiz Clean Code kitobi haqida (juda ko'p) eshitganmiz. "Engineering excellence" haqida gap ketganida "Clean Code" haqida ham aytib ketmasam bo'lmaydi.
Kitobda yozilgan hamma narsalarni bitta postga jamlash – imkonsiz. Quyida o'sha kitobda yozilgan amal qilish oson, lekin ta'siri katta maslahatlarni keltirib o'taman:
• O'zgaruvchi, funksiya va boshqalarga ma'noli nom tanlash.
• Kodni sodda, o'qishga oson yozish. "Aqlli" koddan tushunarli kodni afzal ko'rish.
• Funksiyalarni iloji boricha faqatgina bitta logikali amalni bajaradigan darajada kichikroq qilish.
• Bir necha marta takrorlangan logikalarni alohida funksiyaga o'tkazish.
• Kodingiz nima ish qilayotganini kod orqali tushuntirish, kommentlar orqali emas.
• Kodni tez-tez refaktor qilish. Yaxshilasa bo'ladigan joylarni topib, to'g'rilash.
Misol #1
❌ Noaniq nom:
✅ Aniq va tushunarli nom:
Misol #2
❌ O'qish qiyin ("bitwise"ni hamma ham bilmasligi mumkin):
✅ O'qish oson ("modulo"ni ko'pchilik biladi):
Misol #3
❌ Tushunarsiz kodni komment bilan tushuntirish:
✅ Tushunarli kodga komment shart emas:
Agar siz ham "Clean Code" haqida eshitgan, asosiy joylarini internetdan qarab chiqqan, lekin hali to'liq o'qib chiqmagan bo'lsangiz, o'qishni maslahat beraman. Shaxsan o'zim bu kitobni 1 yil oldin o'qidim. Kitobni sotib olib, ish stolimga qo'yib qo'ydim va har kunlik ish vaqtimning eng ohirgi 30 daqiqasini shu kitobni o'qishga sarfladim. O'rganganlarimni keyingi kun ishda qo'llashga harakat qildim :)
#engineeringexcellence
@muhammadjohns
Dasturlash tili standartlariga rioya qilish kodingiz sifatini biroz oshiradi. Kod sifatini yanada oshirish uchun keyingi qadam – "toza kod" yozish.
Ko'pchiligimiz Clean Code kitobi haqida (juda ko'p) eshitganmiz. "Engineering excellence" haqida gap ketganida "Clean Code" haqida ham aytib ketmasam bo'lmaydi.
Kitobda yozilgan hamma narsalarni bitta postga jamlash – imkonsiz. Quyida o'sha kitobda yozilgan amal qilish oson, lekin ta'siri katta maslahatlarni keltirib o'taman:
• O'zgaruvchi, funksiya va boshqalarga ma'noli nom tanlash.
• Kodni sodda, o'qishga oson yozish. "Aqlli" koddan tushunarli kodni afzal ko'rish.
• Funksiyalarni iloji boricha faqatgina bitta logikali amalni bajaradigan darajada kichikroq qilish.
• Bir necha marta takrorlangan logikalarni alohida funksiyaga o'tkazish.
• Kodingiz nima ish qilayotganini kod orqali tushuntirish, kommentlar orqali emas.
• Kodni tez-tez refaktor qilish. Yaxshilasa bo'ladigan joylarni topib, to'g'rilash.
Misol #1
❌ Noaniq nom:
fetchData()
✅ Aniq va tushunarli nom:
fetchEmailsInTrashFolder()
Misol #2
❌ O'qish qiyin ("bitwise"ni hamma ham bilmasligi mumkin):
val numbers = listOf(1, 2, 3, 4, 5, 6)
val evens = numbers.filter {
it and 1 == 0
}
✅ O'qish oson ("modulo"ni ko'pchilik biladi):
val numbers = listOf(1, 2, 3, 4, 5, 6)
val evens = numbers.filter {
it % 2 == 0
}
Misol #3
❌ Tushunarsiz kodni komment bilan tushuntirish:
d = 100.0 # Distance in meters
t = 15.0 # time in seconds
print(get_speed(d, t))
✅ Tushunarli kodga komment shart emas:
distance_meters = 100.0
time_seconds = 15.0
print(calculate_speed(distance_meters, time_seconds))
Agar siz ham "Clean Code" haqida eshitgan, asosiy joylarini internetdan qarab chiqqan, lekin hali to'liq o'qib chiqmagan bo'lsangiz, o'qishni maslahat beraman. Shaxsan o'zim bu kitobni 1 yil oldin o'qidim. Kitobni sotib olib, ish stolimga qo'yib qo'ydim va har kunlik ish vaqtimning eng ohirgi 30 daqiqasini shu kitobni o'qishga sarfladim. O'rganganlarimni keyingi kun ishda qo'llashga harakat qildim :)
#engineeringexcellence
@muhammadjohns
Kod sifati - Kodlarni tahlil qilish
Dasturga kichik o'zgarish qilish uchun 2 kun bosh qotirib, tahminan 200 qatorli kod yozdim. Style guide'ga va Clean code'dagi qoidalarga amal qildim. Kodimni o'zim yaxshilab tekshirdim: xatolar yo'q. Dasturni yurgizib ko'rdim: o'zgarishim kutilgandek ishlayapti. Endi kodimni topshirishdan oldin tahlil qilishga jo'nataman, ya'ni "Pull Request" qilaman.
2 soatdan keyin qarasam, kodimni tekshirayotgan dasturchi:
• Kodimda bitta umuman hayolimga kelmaydigan ("edge-case") kamchilik topibdi. To'g'riladim.
• Bir-ikkita joylariga kodni yanada yaxshiroq qilish uchun taklif beribdi. Takliflarni hisobga olib, kodimni o'zgartirganimdan keyin o'zgarishlarim 200 qatordan 180 qatorga tushdi.
• Kodimning tushunmagan joylari haqida savol so'rabdi. "U tushunmadimi, demak boshqalar uchun ham tushunarsiz bo'ladi", deb kodimni yanada tushunarliroq qilib yozdim.
Shundan keyin tekshiruvchi kodimni topshirishimga ruxsat berdi.
~~~
Kodlarni tahlil qilish ("code review") jarayoni yo'lga qo'yilgan kompaniyalarda holat tahminan yuqoridagidek bo'ladi.
Kodlarni tahlil qilish – "Engineering Excellence"ning eng asosiy ustunlaridan biri. Kodlarni tahlil qilish – bu faqat junior'ning kodini senior tekshirishi kerak, degani emas.
Ushbu jarayondan maqsadlar quyidagicha:
1. O'zgarishlarga boshqa odamning nuqtai nazaridan qarash. Ikkita dasturchi ikki xil fikr yuritadi. Kodni yozgan dasturchi o'zining yechimini "eng yaxshi yechim", deb o'ylashi mumkin. Boshqa dasturchi yanada yaxshiroq yechim taklif qilishi mumkin.
2. Beixtiyor xatolarni tutish. Bir kishi ko'rmay qolgan xatoni boshqasi tutishga yordam beradi.
3. Kodning tushunarli ekanligiga ishonch hosil qilish. Bir necha soat muammo ustida bosh qotirib kod yozgan odam uchun o'zining kodi juda tushunarli bo'ladi. Boshqa dasturchi tekshirganida esda tushunarsiz joylarini topib, ko'rsatadi.
4. Kod bazasini yaxshilash. Kodga qilinayotgan har bir o'zgarish kodni avvalgi holatiga nisbadan yaxshiroq holatga olib kelishi kerak. Aks holda vaqt o'tgan sari kod bazasining sifati pasayib boradi. Boshqa dasturchi shuni tekshirib oladi.
5. Boshqalarga bilim ulashish. Ha, siz o'zingiz yozgan kodni boshqalarga tekshirtirish orqali bilim ulashasiz. Ular bir muammo va unga yechim haqida o'rganib olishadi.
~~~
Kodni tekshiruvchi sifatida sizning vazifangiz boshqa dasturchining kodini tanqid qilish bo'lmasligi kerak. Aksincha, konstruktiv tarzda o'zgarishlar taklif qilishingiz kerak.
Kodning egasi sifatida siz kodingizga bildirilgan fikrlarni to'g'ri qabul qilib, kerakli o'zgarishlarni amalga oshirishingiz kerak.
Kodni tahlil qilish borasida Vohid Karimov yaxshi maslahatlarni shu va undan keyingi bir nechta postlarda keltirib o'tgan. O'qib chiqishni tavsiya qilaman.
#engineeringexcellence
@muhammadjohns
Dasturga kichik o'zgarish qilish uchun 2 kun bosh qotirib, tahminan 200 qatorli kod yozdim. Style guide'ga va Clean code'dagi qoidalarga amal qildim. Kodimni o'zim yaxshilab tekshirdim: xatolar yo'q. Dasturni yurgizib ko'rdim: o'zgarishim kutilgandek ishlayapti. Endi kodimni topshirishdan oldin tahlil qilishga jo'nataman, ya'ni "Pull Request" qilaman.
2 soatdan keyin qarasam, kodimni tekshirayotgan dasturchi:
• Kodimda bitta umuman hayolimga kelmaydigan ("edge-case") kamchilik topibdi. To'g'riladim.
• Bir-ikkita joylariga kodni yanada yaxshiroq qilish uchun taklif beribdi. Takliflarni hisobga olib, kodimni o'zgartirganimdan keyin o'zgarishlarim 200 qatordan 180 qatorga tushdi.
• Kodimning tushunmagan joylari haqida savol so'rabdi. "U tushunmadimi, demak boshqalar uchun ham tushunarsiz bo'ladi", deb kodimni yanada tushunarliroq qilib yozdim.
Shundan keyin tekshiruvchi kodimni topshirishimga ruxsat berdi.
~~~
Kodlarni tahlil qilish ("code review") jarayoni yo'lga qo'yilgan kompaniyalarda holat tahminan yuqoridagidek bo'ladi.
Kodlarni tahlil qilish – "Engineering Excellence"ning eng asosiy ustunlaridan biri. Kodlarni tahlil qilish – bu faqat junior'ning kodini senior tekshirishi kerak, degani emas.
Ushbu jarayondan maqsadlar quyidagicha:
1. O'zgarishlarga boshqa odamning nuqtai nazaridan qarash. Ikkita dasturchi ikki xil fikr yuritadi. Kodni yozgan dasturchi o'zining yechimini "eng yaxshi yechim", deb o'ylashi mumkin. Boshqa dasturchi yanada yaxshiroq yechim taklif qilishi mumkin.
2. Beixtiyor xatolarni tutish. Bir kishi ko'rmay qolgan xatoni boshqasi tutishga yordam beradi.
3. Kodning tushunarli ekanligiga ishonch hosil qilish. Bir necha soat muammo ustida bosh qotirib kod yozgan odam uchun o'zining kodi juda tushunarli bo'ladi. Boshqa dasturchi tekshirganida esda tushunarsiz joylarini topib, ko'rsatadi.
4. Kod bazasini yaxshilash. Kodga qilinayotgan har bir o'zgarish kodni avvalgi holatiga nisbadan yaxshiroq holatga olib kelishi kerak. Aks holda vaqt o'tgan sari kod bazasining sifati pasayib boradi. Boshqa dasturchi shuni tekshirib oladi.
5. Boshqalarga bilim ulashish. Ha, siz o'zingiz yozgan kodni boshqalarga tekshirtirish orqali bilim ulashasiz. Ular bir muammo va unga yechim haqida o'rganib olishadi.
~~~
Kodni tekshiruvchi sifatida sizning vazifangiz boshqa dasturchining kodini tanqid qilish bo'lmasligi kerak. Aksincha, konstruktiv tarzda o'zgarishlar taklif qilishingiz kerak.
Kodning egasi sifatida siz kodingizga bildirilgan fikrlarni to'g'ri qabul qilib, kerakli o'zgarishlarni amalga oshirishingiz kerak.
Kodni tahlil qilish borasida Vohid Karimov yaxshi maslahatlarni shu va undan keyingi bir nechta postlarda keltirib o'tgan. O'qib chiqishni tavsiya qilaman.
#engineeringexcellence
@muhammadjohns
Kanadada ham kun boshlanib, bayram avjida.
Ramazon Hayiti Muborak bo'lsin, Azizlar!!!
🎉🎊🥳
@muhammadjohns
Ramazon Hayiti Muborak bo'lsin, Azizlar!!!
🎉🎊🥳
@muhammadjohns
Yangi ofisga ko'chdik
Avval Voterlu shahrida Google'ning 2 ta asosiy binosi bo'lib, boshqa bir nechta binolarni ijaraga olar edi. Yaqinda yangi 3-bino qurib bitkazildi va ijaraga olingan binolardagi ishchilarning barchasi shu ofisga ko'chib o'tishdi.
Ohirgi paytda Google Kanada o'sib boryapti. Hozir ham ~30 ta ochiq ish o'rni bor ekan: link.
@muhammadjohns
Avval Voterlu shahrida Google'ning 2 ta asosiy binosi bo'lib, boshqa bir nechta binolarni ijaraga olar edi. Yaqinda yangi 3-bino qurib bitkazildi va ijaraga olingan binolardagi ishchilarning barchasi shu ofisga ko'chib o'tishdi.
Ohirgi paytda Google Kanada o'sib boryapti. Hozir ham ~30 ta ochiq ish o'rni bor ekan: link.
@muhammadjohns