DEV Community: Akhmad

Htop, top monitoringlardan ma'lumotlar olish.

Akhmad — Sun, 05 May 2024 14:38:07 +0000

Keling oldin monitoring haqida ikki og'iz gaplashamiz. Agar real hayotdan misol qilsak bizga ma'lum vaqt oralig'idagi biror jarayonlar haqida ma'lumotlar kerak. Aytaylik xozirda hamma foydalanadigan to'lov tizimlaridagi kirim va chiqim monitoringi. Deyarli barcha dasturlarda siz ma'lum vaqt oralig'ida sizning bank kartangizga qancha pul kirgan va chiqgani haqidagi ma'lumotlarni olishingiz mumkin. Bu ma'lumotlar asosida siz keyingi moliyaviy masalaga doir rejalaringizni qilasiz. Ya'ni agar siz pulni tejamoqchi bo'lsangiz ko'rishingiz mumkin so'ngi oylarda aynan qandaydir chiqimlarni kamaytirish uchun xozirda qancha chiqim qilayotganingiz haqidagi ma'lumotni olasiz. Monitoringdan ko'ringizki har kuni coffe uchun 20ming so'm pul sarflayabsiz, tushlik uchun 30-40ming, transport va boshqa harajatlar uchun esa 10ming so'm. So'ngi 6 oylikda qilingan barcha chiqimlarnini biror to'lov tizimidan oldingiz. Endi siz chiqimlarni kamaytirish uchun o'z qaroriningizni qilasiz. Boshqa tomondan qarasak siz bir faktorga asoslangan ma'lumotlarni qayta ishlab aynan o'sha masalaga nisbatan chora ko'rmoqchisiz. Bu holatda asosiy faktor umumiy chiqimlar ko'p ekani. Ushbu ma'lumotlarga ega bo'lishingiz uchun biror to'lo'v tizimi ilovasidan foydalandingiz. Endi navbat yechimga va yechim ham turlicha bo'lishi mumkin. Masalan boshida pulni tejashni niyat qilgan edik ammo yana boshqa g'oya keldi ko'proq daromat qilishga chiqish kerak. Vaziyatni yana bir analiz qilamiz. Demak sizda qandaydir muammo bor edi lekin aniq dalilingiz yo'q. Muammo sizda xarajatlar ko'p ekani, bu masalga aniqlik kiritish uchun sizga monitoring aniq asosli ma'lumotlarni taqdim qildi endi shuni asosida yechim qilasiz. Hammamiz bilamizki pul bu universal tovar yoki resurs va bu resurs ham cheklangan.

Sohamizda ham huddi shunday bizning resurslarimiz cheklangan. Shu sababdan aynan qaysi resurs qayerga sarf bo'layotganini kuzatish va aniqlash eng muhim mavzulardan biri xisoblanadi. Buning uchun ham huddi biz to'lov tizimlarida ko'rib chiqganimiz kabi monitoring dasturlar mavjud. Ushbu dasturlar tur maqsadga va imkoniyatlarga ega. Bazilari umumiy, sodda bo'lsa bazilari juda ham batafsil va maxsus ma'lumotlarni bizga taqdim qiladi. Ammo bugun biz oddiy va sodda monitoring tizimlar yani top, htop kabi sodda posix dasturlar bizga qanday ma'lumotlarni taqdim qilishi haqida ko'rib chiqamiz.

htop yoki top dasturlarida ko'rib turganingizdak birqancha columnlar mavjud:

PID: Process id. Bilamizki operatsion tizimda barcha jarayonlar(process) ma'lum identifikatorlar bilan belgilanadi va biz barcha jarayonlarga aloqador amaliyotlarni ushbu identificatorlar asosida hal etishimiz mumkin.

kill <PID>
kill $(lsof -t -i:8080)

USER: Barcha mashxur operatsion tizimlarda alohida user managment mavjud. Barcha processlarning egasi esa userlar.

PR: Posix tizimlarda jarayonlarning prioriteti mavjud. Prioritetlar biror jarayonga nisbatan qanday resurs ajratilishini aniqlashda katta ahamiyatga ega.

NI: Yuqorida barcha resurslar cheklanganligini takidlagan edik. Shu sababdan Operatsion tizimlarda turli resurslardan unumli foydalanish uchun juda ko'p yechimlar qilingan. Resurslarni boshqarishning eng asosiy mexanizmi sifatida biz OS schedulerni ko'rishimiz mumkin. Ushbu NI ustunida aynan CPU resurslaridan foydalanish haqida gap ketadi. OS scheduler resurslarni boshqarish uchun ham turlicha uslublardan foydalanadi. Shulardan biri traditsional scheduling. NI ustunida nice qiymat ko'rsatiladi. Ushbu qiymat OSdagi processlarga resurs ajratishni prioritetizatsiya qilishning yana bir uslubi uchun kerak. Bu uslub dinamik prioritet asosida bo'ladi. Soddaroq aytadigan bo'lsak prioritet uchun ajratilgan nice ma'lum oraliqdagi qiymatlarni o'z ichiga oladi -20dan 20gacha bo'lgan oraliqni. Kegin ushbu qiymat asosida ushbu process uchun ma'lum vaqt CPU ajratilinadi. Qiymat qancha katta bo'lsa shuncha ko'proq vaqt ajratilinadi. Standart holatda esa nice qiymati 0 ga teng bo'ladi.

VIRT: Process sarflayotgan virtual hotira ko'rsatkichi batafsil

RES: Process sarflayotgan hotira ko'rsatkichi batafsil

SHR: Process sarflanayotgan umumiy hotira(shared memory).

S: Process statusi (zombied, sleeping, running etc...) batafsil

%CPU: Process sarflayotgan CPU vaqtining foizi.

%MEM: Process sarflayotgan hotira(RAM) foizi.

TIME+: Process uchun qancha CPU vaqti ishlatilgan.

COMMAND: Jarayonni boshlagan buyruqning nomi.

Yuqoridagi faktorlar orqali biz eng umumiy ma'lumotlarga ega bo'lgan holatda bizning muhitimizda nima bo'layotganini tushunishimiz mumkin. Masalan agar bizni dasturimiz ko'p hotira sarflayotgan bo'lsa demak %MEM ustuniga qarab birinchi hulosaga ega bo'lishimiz mumkin. Eng kamida shunday sodda monitoring tizimlar biror muammolarni hal etishimizda ishimizni ancha yengillashtiradi. Lekin ish jarayonida boshqa batafsil faktorlar ham kerak bo'ladi shu sababdan bunday ma'lumotlarga erishish uchun biz yana boshqa uskunalardan foydalanishimiz kerak.

Reference:

https://www.gnu.org/software/libc/manual/html_node/Process-Identification.html
https://www.gnu.org/software/libc/manual/html_node/Priority.html
https://www.cs.uic.edu/~jbell/CourseNotes/OperatingSystems/6_CPU_Scheduling.html
https://www.cs.uic.edu/~jbell/CourseNotes/OperatingSystems/8_MainMemory.html
https://core.ac.uk/download/534193555.pdf
https://www.cs.uic.edu/~jbell/CourseNotes/OperatingSystems/2_Structures.html
http://www.kohala.com/start/unpv22e/unpv22e.chap12.pdf
https://homes.cs.washington.edu/~levy/opal/opal-tocs.pdf
https://dl.acm.org/doi/pdf/10.1145/321738.321743
https://people.cs.rutgers.edu/~pxk/416/notes/07-scheduling.html

Statik methodlar bilan yangi yozilgan eski kod (Instant legacy code with static methods).

Akhmad — Wed, 14 Dec 2022 13:17:56 +0000

Disclaimer: Maqoladagi barcha so'zlar va fikrlar mening ancha vaqtdan buyon kuzatuvlarim natijasida hosil bo'lgan tahlillar hulosaasi va subyektiv fikrlarim. Har bir keltirilgan ma'lumot va faktlar barcha holatlarga mos kelishiga kafolat bermayman

Kirish

Qisqacha izoh: Ko'plab dasturlash tillari bir yoki birqancha dasturlash falsafalarini qo'llab quvvatlashi xozirgi kunda barchamizga ma'lum. Shu jumladan xozirgi davrga kelib dasturlash falsafalari yoki paradigmalari ham ancha muncha ko'payib ketdi. Tendensiyalar o'zgaryabti va texnalogiyalarda ham ancha evalution sodir bo'layabti. Avvalari dasturlashda compilerlar muammosi bo'lgan bo'lsa va buning yechimi C tili bo'lgan bo'lsa xozirgi zamonda tendensiya o'zgardi talab ham compilerga emas balki yaxshi kompozitsiya qilish mumkin bo'lgan falsafaga qaratila boshladi. Avvallari ASM C davrlarida falsafa muhim bo'lmagan bo'lsa xozirgi kunda falsafa yoki paradim muhimlik darajasi yuqoriga o'sib borayabti.

Nimaga ?

Biz eski bundan oldingi taxminan 90 yilar o'rtasini xisobga olsak u paytlar eng katta muammolardan biri resurs bo'lgan. Fizik resurslar xozirgidan ko'ra ancha muncha cheklangan bo'lgan shu qatori loyihalar hajmi ham unchalik keng qamrovli bo'lmagan. Shu sababdan tezlik va hajmga aloqador ko'rsatkichlar juda katta axamiyatga ega bo'lgan. Shu sababdan quality masalalariga juda ko'p etibor qilinmagan. Keyinchalik dasturlashda ham falsafa paradigmalar rivojlana boshladi. Boshqacha falsafaga asoslangan tillar paydo bo'ldi. Masalan Simula, Smalltalk ushbu tillar Object Oriented paradigmasining taqdim qilishdi. Tillar rivojlanishi bilan paralell ravishta texnalogiyalar ham ancha evolutionga uchradi. Huddi shunday loyihalar va ularning hajmi ham juda kattalashdi. Dasturchi engineerlar uchun code yozishdan boshqa bilim ko'nikmalar ham kerak bo'la boshladi. O'zi ishlatadigan tildan tashqari umumiy Paradigma fa dasturlash falsafalarini o'rganish kerak bo'ldi. Loyihaga ham birqancha kriteriyalarda talablar qo'yila boshlandi. Bir loyiha ustida yuzlab minglab insonlar ishlay boshlagandan keyin tendensiyalar ancha o'zgarib ketdi.
Endi tarixni yegishtirib asosiy mavzuga qaytsak )). ASM va C kabi tillarni o'rniga nima uchun yangi tillar chiqdi ? Asosiy moxiyatlardan biri ushbu tillar kop energiya sarflanadigan va birmuncha murakkabroq. Shu bilan bir qatorda dasturlash va tillar rivojlanishining boshida communityning juda katta qismi bir tomonlama qarashgan yani procedurial.

Procedurial programming haqida qisqacha:
Ushbu dasturlash paradigmasi biror ish jarayonida ketma ket ma'lum functionallar yordamida amalga oshirishga qaratilgan uslub. Bizga Algorithmlarni tushuntirishayotganda aytilganiday

O'zbek tilida quyidagi tarifni eshitgan edim:

"Algoritm – berilgan natijaga erishish uchun qilinishi kerak boʻlgan aniq koʻrsatmalar ketma-ketligi."

Bazi manbalarda esa quyidagicha tariflangan:

"Algoritm - bu muammoni hal qilish yoki hisoblash uchun ishlatiladigan protsedura. Algoritmlar apparat yoki dasturiy ta'minotga asoslangan tartiblarda ko'rsatilgan harakatlarni bosqichma-bosqich bajaradigan ko'rsatmalarning aniq ro'yxati sifatida ishlaydi. Algoritmlar ITning barcha sohalarida keng qo'llaniladi."

Juda ham ko'plab tariflar mavjud va ularning katta qismida ushbu tariflar procedurial qarashlarni ilgari suryabti.

Ho'sh nima muammo ? Procedurial programmingning nimasi yomon ?
Man ushbu paradigma va uning falsafasini tanqid qilishdan yoki argumentlarni keltirishdan oldin bir kichik manbani ulashishni xoxladim.

Yuqoridagi rasmlarda Linux kernel source code

Loyiha aynan procedurial paradimg asosida qurilgan va juda ham katta Judayam ! Yuqorida 10 minglab qator yozilgan codelarni ko'rishingiz mumkin.

Loyihada biror o'zgarishlar qilish anchagina qiyin undan tashqari tushunish ham. Shu bilan birga loyihaga on boarding ham birmuncha mashaqqatli ish. Lekin lekin yuqorida aytilgandan procedurial programming paradigmlari implement qilingan va deyarli to'liq ushbu falsafa asosida qurilgan. Texnik jixatdan ushbu loyihani o'rtacha dasturchi qo'llab quvvatlashi yoki biror o'zgarish kiritishi anchagina qiyin masala. Ushbu dasturchi C tilini yaxshi bilgan taqdirda ham project hajmi kattaligi undagi filelar va linelar juda kattaligi sababdan support yoki contributing anchagina qiyin. Lekin source code yaxshiroq yozilgan ekanini ham eslatib o'tish o'rinli.

Procedurial programming falsafasi umumiy biror product ishlab chiqish nuqtai nazaridan ham ish bermay qo'ydi ayniqsa xozirgi zamonda. Bunga asosisy sabab procedurial decomposition. Yani protesudurial kompozitsiyalar va dizayn anchagina mashaqqatli va yaxshi kompozitsiya qilish deyarli ilojisiz masala. Chunki procedurial like compositionlarda focus biror bir procedureni amalga oshiradigan functionallarga asoslangan buyoqda esa resonsibilitylarni taqsimlash maintanable code yozish anchagina qiyin abstraktsiya anchagina past lekin xozirgi zamonda esa dasturlarda abstraktsiya darajasi yuqorilashib borayabti. Xozir aspect oriented yechimlar kop tomonlama o'zini oqlab kelayabti. Bu kabi muammolarni project kattalashganida va uni contributorlari ko'payganida sezish mumkin. Yuqoridagi Linux kernel ham aynan shu maqsadda share qilindi. Pure functional yoki procedurial falsafalar juda ko'p holatlarda kengayish qo'llab quvvatlash imkoniyatlarini kamayishiga sabab bo'ladi.

Static methodlar anti pattern.

Static methodlarning anti pattern ekaniga eng asosiy sabablardan bir bu OOP ning eng asosiy prinspi bo'lmish Encapsulation buzulishi xisoblanadi. Procedurial yoki functional programmingda ko'proq functionlar ishlasa functionlar functionlarni ishlatsa. Object oriented falsafa bo'yicha asosiy focus objectlarga qaratiladi. Objectlar koproq encapsulated objectlar bilan ishlaydi. Kichik kichik functionalga ega bo'lgan Encapsulated objectlardan tashkil topadi umumiy loyiha.

Static methodlar va yana bazi anti Object oriented feauturelar esa asosan Old school contributor va authorlar tomonidan o'ylab topib implement qilingan narsalar deb o'ylayman (IMHO).
Koplab tillarda shunday featurelar qo'llab quvvatlanadi va eski falsafaga asoslangan yangi tillarga aylanib qolishyabti.
C++ C#, Java, PHP tillari OOP ni yaxshi implement qilishga xarakat qilgan ammo dasturchilar tomonidan OOP paradigmlari yaxshi tushunilmagani va implement qilinmagani uchun hali ham Ushbu tillarda yozishsa ham C kabi ASM kabi code yozishyabti.
Bir misol orqali objectlar va static methodlarni tushuntirib berishga xarakat qilaman.
Misol:

// Interval.xm

class Interval {
   left: i32
   right: i32

   public diff() i32 {
     return Math.abc(right - left)
   }
}

Instant legacy code :)

Yuqorida oddiy interval object. Aytaylik sizga intervallar bilan ishlaydigan object kerak va uni shunday ko'rinishda taqdim qildingiz. Ammo buyoqda yana bir muammo bor bu muammo shundaki diff() methodi ichidagi Math.abc() static methodi szni diff() methodingiz va Interval objectingiz yomon compozition bo'lishiga sabab bo'lmoqda. Buni biroz refactor qilish kerak. Sababi bu kabi compositionlarda Objectlar objectlar bilan emas balki Objectlar functionlar bilan yoki functionlar objectlar bilan ishlamoqda. Bunday mix composition oqibatida Object orieted prinsplar buzuladi.

// Interval.xm

class Interval {
   left: i32
   right: i32

   public diff() Int32 {
     return new Abc(right - left)
   }
}

Little Elegant code :)

Biroz refactoringdan keyin ko'rishimiz mumkinki biz Math.abc() methodi o'rniga Abc Degan objectga murojat qilayabmiz. Yechimning ishlashi deyarli o'zgarmadi. Ammo buyoqda paradigmaga muvofiq Object oriented yechim xosil bo'ldi. Shu bilan bir qatorda bizragi objectlar yana boshqa objectlardan foydalanyabti diff() methodi ham object qaytariyatbi toza integer emas :). Ammo bu yechimni ham yana refactor qilish mumkin masalan ecapsulated params ham object bo'lsa yanayam yaxshi bo'ladi.

Shunday qilib...

Xozirgi xolatda bunday muammolardan to'liq qutilish deyarli imkonsiz ayniqsa traditional C like tillarda. Ammo biz Object oriented composition qilishni xoxlasak maksimal darajada ushbu paradigmaning prinsplarini implement qilishimiz va ularga rioya qilishimiz kerak. Static methodlar objectlar encapsulated bo'lmasligiga taminlaydi ular asosidagi classlar esa shunchaki birqancha procedurelar to'plami kabi ishlaydi. Procedural paradigmada yuqorida aytib o'tilgani kabi juda katta functionlar yoki mayda functionlardan tashkil topgan katta functionlar deb qaraladi. OOP da esa kichik objectlardan tashkil topgan objectlar ularda asosiy focus constructorlarga qaratiladi methodlar esa anchagina kichik bo'ladi. Static methodlardan tashqari yana ko'plab boshqa anti pattern componentlar feauturelar mavjud bularni ham alohida yoritish kerak Biz yangi narsalarni eski dunyo qarashga asoslanib quradigan bo'lsak hech narsa o'zgarmaydi faqatina yanada yomonlashadi ))). Shu sababdan dunyo qarashlarni ham yangilash ancha foydali.

Etiboringiz uchun Rahmat :)

Happy Coding !

Telegram: Kanalim

Dastur infratuzulmasi. Sizni loyihangiz qanchalik ozod ?

Akhmad — Wed, 09 Nov 2022 20:20:07 +0000

Disclaimer: Maqoladagi barcha so'zlar va fikrlar mening ancha vaqtdan buyon kuzatuvlarim natijasida hosil bo'lgan tahlillar hulosaasi va subyektiv fikrlarim. Har bir keltirilgan ma'lumot va faktlar barcha holatlarga mos kelishiga kafolat bermayman

Kirish

Qisqacha izoh: Dastur infratuzulmasi yoki ekotizimi deganda. Loyihadagi barcha dependencylar, layerlar, ma'suliyatga ega bo'lgan turli componentlarning jamlanmasi nazarda tutilyabit. Bunga alternative contextlar topa olmaganim uchun aynan shu terminlardan foydalanishni afzal bildim )

Maqsad: Infratuzulmani tashqi omillarga bog'lamagan holatda qurish va loyiha erkin o'sib rivojlanishini ta'minlash. Ushu mavzuga nisbatan 3ta rakursdan qarab ko'rish o'rinli deb bildim. Ya'ni bog'liqliklarga nisbatan Loyiha talablari qanday ? Biznes bu mavzuga qanday qaraydi ? Dasturchi qanday qaraydi ?. Undan oldin esa tashqi bog'likliklar oqibati nimalarga olib kelishi mumkinligini ko'rib chiqamiz.

Postda keltirilgan ba'zi sourcelar shunchaki barchaga tushunarliroq syntax holos va shunday bo'ldi deb umid qilaman :)

Qaramlik yoki bog'liqliklar oqibatlari.

Aytaylik sizga qo'yilgan vazifa yuzasidan foydalanuvchilar elektron pochtasiga mail xabar yuborishingiz kerak. Aytaylik registratsiyadan keyingi emailni tasdiqlash uchun. Ushbu holatda ko'pchilik qanday 3-tomonlama bo'lgan qandaydur kutbxona yoki tooldan foydalanadi. Oqibatda n vaqtdan keyin ushbu kutbxona o'zgarishi va yana boshqa turli sabablar tufayli ana o'sha qismda anchagina muammolar yuzaga keladi. Masalan:

Application.xm


import otherdebs
import TrashMailer

class ApplicationLogicLayer {
  // other logics
  register(data) {
    // other logic of registration
    try{
      result = new TrashMailer(smtpConfig)
      .to(data.email)
      .header(data.header)
      .bodyAsHTML(data.body)
      .send()

      if(!result.isOk) throw new Exeption(result.error)
    }
    catch(error){
      throw new Exeption(error)
    }
  }
}

Endi tasavur qiling siz TrashMailer kutubxonasini registratsiyada reset passworda va yana boshqa birqancha joylarda ishlatdingiz va huddi yuqoridagi kabi tadbiq qildingiz. Oradan vaqt o'tib ushbu kutbxonani siz yangiladingiz yoki bo'lmasa yangilashga majbur bo'ldingiz. Aytaylik siz ishlatadigan texnalogiya yoki tilni yangilashingiz natijasida kutbxona ishlamay qoldi va yangilashga majbur bo'kdingiz va siz xmpm update TrashMailer deb yangi versiyani qo'ydingiz...
Bingo sizga kun sovg'asi sifatida juda koplab muammolar olib keldi. Ushbu yangilanish ancha qimmatga tushdi. Siz birqancha xatoliklarga duch keldingiz a,b,c xatoliklar shunchaki siz yangi versiyani o'rnatganingiz evaziga kelib chiqdi.
Tabirklayman! Siz xatoni tezda bartaraf qila oldingiz. Dahosiz :). Xatolikni ham qisqacha izohlaylik bizni TrashMail kutbxonamizda ba'zi apilar o'zgaribti endilikda 5.6.7 versiyadan boshlab biz HTML contentni email orqali yubormoqchi bo'lsak. send() emas balki sendAsHTMLContent() methodiga murojat qilar ekanmiz.
Endi yagona qilishingiz kerak bo'lgan narsa siz qayerda HTML content yuborgan bo'lsangiz barchasini o'zgartirishingiz kerak :) Shu bilan birga sizni ishingiz N marotaba kopaydi...

Yechim:
Ushbu muammoning yechishni uslublari ko'p keling asosiy 2 ta yo'lni ko'rib umumiyroq chiqamiz.

Siz SMTP messagingni to'liq o'zingiz yozishingiz mumkin ammo bu narsa ko'p vaqt olishi va qimmatga tushishi extimoli katta. Lekin buni oqibatida barcha narsani boshqaruvi sizni qo'lingizga o'tadi va sizni loyiha konsepsiyasiga moslanadi yani sizni barcha qoliplaringizga mos keladigan bo'ladi. Ammo Over engineering bo'lishi extimoli ham mavjud.
Siz xar qanday kutbxona yoki libraryni bir qolipga o'raysiz va loyihangizning ekotizimiga moslab alohida qatlam qilasiz. Yani alohida wrapped external service yoki dependency. Bunday yechim siz ushbu kutbxona imkoniyatlarini faqatgina bir joyda boshqarishingiz va bir joydan o'zgartirishingizga sabab bo'ladi. Qachonki loyihadagi ushbu funksional logikasi interfeyslari o'zgarmaguncha!

Shu sababdan agarda siz biror tashqi dependecnylardan foydalanishingiz kerak bo'lsa va xozirgi holat kabi boshqa imkoningiz bo'lmasa ikkinchi yechimni tavsiya etaman va ushbu yechim quyidagi misolda keltirilgan.

SmtpMessage.xm


import Mailer

class SmtpMessage {
  // other logics
  send(data) {
    try{
      result = new Mailer(this.config)
      .to(data.email)
      .header(data.header)
      .bodyAsHTML(data.body)
      .send()

      if(!result.isOk) throw new SmtpExeption(result.error)
    }
    catch(error){
      throw new SmtpExeption(result.error)
    }
  }
}

Application.xm

import otherdebs
import SmtpMessage

class ApplicationLogicLayer {
  // other logics
  register(data) {
    // other logic of registration
    try{
      new SmtpMessage().send(message)
    }
    catch(error){
      throw new Exeption(error)
    }
  }
}

Yuqoridagi misol kabi amaliyotlarda bog'liqliklar oqibatlari ko'pincha qimmatga tushadi. Shu sababdan ushbu risklarni biroz o'ylab ko'rgan va oldindan yechimini qilgan afzal deb o'ylayman. Undan tashqari bu kabi amaliyotlarda avvalo loyiha ekotizimini ustun qo'yi maqsadga muvofiq.

Ekotizim qurish.

Ekotizim masalasi A-Z masala ushbu mavzu to'g'ridan to'g'ri biznes logikani qanday tadib qilish va arxitekturaviy masalalarga kelib taqaladi. Shu sababdan avvalo tayyor arxitekturaviy patternlarni ko'rib o'rganib chiqishni tavsiya etaman. Ko'pchilik biror loyiha qiladigan bo'lsa biror til yoki texnalogiya asosidagi framework va Third party kutbxonalarni tanlaydi va shular asosida ularni ekotizimi asosida loyihani qurishadi. Ushbu uslub esa kelajakda juda koplab muammolarni keltirib chiqaradi bularning eng qimmatga tushadigani esa ana o'sha frameworklar qolipi doirasidan tashqariga chiqmaslik yoki o'sha qolipda fikrlash. Shaxsan mani kuzatuvlarim natijasida aytaylik web dasturlashda koryera qurishdan boshlab shunday xatoliklar va muammolar kelib chiqadi masalan odatiy yo'nalish standarti quyidagicha.

Dasturlash tili yoki asosiy texnalogiyani o'rganish (Javascript/Typescript/Nodejs)
Falon fismadon ishlarni qilish uchun librarylar toolar (nodemailer, socket.io, passportjs, jwt, expressjs, telegrafjs, ORMs and ODMs etc...)
Frameworklarni o'rganish (nestjs, adonis) Eng ohirida esa ushbu frameworklar ekotizimi yoki infratuzulmasi asosida qandaydur loyiha qurish

Endilikda esa yana bir g'alati narsa kelib chiqadi.

Men Nestjs dastuchiman !

Web dasturchlas bir yo'nalish va ekotizim bo'lsa undagi frameworklar yana bir katta ekotizim yo'nalishni tashkil qilib qo'yadi ))).

Yuqoridagi gaplardan bir narsani hulosa qilish mumkin bog'liqliklar faqatgina loyiha miqyoisida emas balki kerak bo'lsa dasturchi tarafdan ham bo'lishi mumkin aslida esa dasturchi ko'proq ayibdor bo'lish extimoli katta. Yaxshiyamki biz qilgan xatolarimiz evaziga ham pul oladigan kasb egalarimiz :)

Shu o'rinda qardli xamkasblar va bo'lajak qadrli xamkaslbarga bera oladigan tavsiyam shuki. Bu kabi bo'gliklar oqibatida o'ladigan fatalniy xatoliklarni kamaytirish yoki oldini olish uchun. Ustingizda ko'proq ishlang va boshqa rakursdan ham fikrlab ko'ring. Bu sizga kelajakda koryerangida yanayam ko'proq narsalarga erishishingiz imkonini beradi. Ko'plab dasturiy taminot dizayni va arxitekturasiga aloqador adabiyot va manbalar mavjud. Eng boshlang'ich adabiyotlarni qoldirib ketaman.

Robert.C Martin: Clean Code
Alex Yu: Design patterns yoki refactoring.guru
Robert.C Martin: Clean Architecture

Bogliqliklar bilan aloqador bo'lgan juda kop xatoliklar bor va ularning faktorlari ham yetarlicha kop. Shu sababdan ushbu vaziyatni baxolash va manfatli qaror qabul qilish uchun ham risklarni baxolay olish talab qilinadi.

Risklarni ko'rib chiqish yoki baxolash.

Qancha xarakat qilsangiz ham siz to'liq mustaqillikga erisha olmaysiz (Gap O'zbek ekanimizda ham emas). Masalan barbir sizni loyiha qandaydur DB yoki transportga muxtoj bo'ladi. Lekin bularni ham to'g'ri baholash va bu masalalarga ham chiroyli yechimlar qilish imkoni mavjud. Risklarni baxolashda boshlang'ich birqancha kriteriyalarni izohlayman.

Ushbu tooldan foydalansam meni loyiham funksionali va asosiy logikasi bunga qanchalar bog'lanadi ?
Men ushbu tooldan foydalansam bu qanchalik ishonchli ? (Security, Support, Contributing etc...)
Ushbu texnalogiyaning alternativlari mavjudmi ? Agar bo'lsa mobodo ularga migratsiya jarayoni taxminan qanday bo'ladi ? Bu meni loyihamning asosiy logikasiga qanchalik tasir o'tkazadi ?
Ushbu kutbxonani qaysi versiya intervalini tadbiq qilganim yaxshi ?

Shu bilan birga loyiha logikasiga deyarli tasir o'tkazmaydigan lekin kerakli bo'lgan dependencylar tool va frameworklar ham mavjud. Bular odatda devDependencies deyiladi. Yani bizni asosiy codebasega qo'shilmaydi. Bularga misol. Testing framework va toolar, Documentation toolar linterlar static analyzerlar package build managerlar vaxakazo. Ushbu toolar va texnalogiyalar asosan engineerlar uchun kerak bo'ladi. Lekin bulardan foydalanishda ham support community va verisyalarga etiborli bo'lish ancha yaxshi foyda keltiradi.

Buni nima aloqasi bor ?

Agar biznes tomondan qaraladigan bo'lsa dasturiy product biror framework qolipida bitishini hush ko'rishadi sababi tezroq MVP chiqadi tezroq foyda keladi. Ha shunday biznes uchun ushbu yechim juda ajoyib va biznesmen biznesdagi risklarni xisoblaydi yoki managerlar xisoblaydi va ular ham qandaydur asosga (axmoqona) tayanib shunday qaror qabul qilishadi va o'zlari bilib bilmay texnik tomonlama ham qaror qabul qilishadi.
Dasturchi bizda biror framework ishlatilinishiga sabab juda ko'p xolatda biznes singdirgan MVP tezroq chiqishi. Agar barcha huquq bizda bo'lganda esa kop holatlarda bilimsizlik. Lekin boshqa aspectlar ham bo'lish extimoli katta. Jamoada tajrbalilar kam ekanligi vaxakazolar. Shu sababdan jamoadagi top dasturchilar shunday qarorlarni qabul qilishda shu masalalarni jiddiy ko'rib chiqganlari yaxshi deb o'ylayman. Bo'lmasa texnik jixatdan ham koplab yomon oqibatlarga sabab bo'lish extimollari katta hurmatli xamkasb va xamkasabalar))).
Loyiha sifati. Odatda loyiha sifati Top managment va top dasturchilar kelishuvi asosida belgilanadi. Aslida bunday emas. Lekin bu mavzu katta bo'lgani uchun to'liq yoritmasdan xozirgi holatdagi bog'liqliklardan kelib chiqadigan maummolar sifatga qanchalik tasir qilishini qisman izohlamoqchiman. Juda ko'p frameworklar, ORM, Librarylar antipatternlarga to'lib toshgan bo'ladi. Shu sababdan ularni qo'llash loyiha sifatiga ham jiddiy tasir o'tkazadi. Undan tashqari umumiy arxitektura sifatiga ham jidiy tasir o'tkazadi. Sababi framework o'z konseptlarini sizga taqdim qilgandan keyin shular asosisda loyihani qurasiz ))).

Hulosa

Demak dependency va frameworklardagi bog'liqliklar ancha katta va jiddiy mavzu ekanini menimcha bilib oldingiz. Ushbu ma'lumotlar xamkasb engineerlarga ekanini xisobga olsak. Yagona iltimosim oldin o'zingiz ishlatayotgan texnalogiyani yaxshilab o'rganing va dasturlash paradigmalarini yaxshilab o'rganing. Biznes uchun biz resursmiz shunday ekan ular ham biz uchun daromat resursi shaxsan men shunday xisoblayman. Shu sababdan bazi paytlarda qaror qabul qilish sizni qo'lingizda bo'lmay qoladi va axmoqona qarorlar bo'lganida sizga yoqmasa ham bazida ishlashga majbur bo'lasiz. Agarda ish bervuchi bu masalada kompensatsiya qilayotgan bo'lsa nazarimda ishlayvergan ham yomon emas. Lekin kompensatsiya sezilmasa foydasiz ))). Undan tashqari agar siz shunday xatoliklarni sezib qolsangiz eng kamida 1-2 marotaba ushbu mavzuni ko'tarib barchani ogolantirib ko'ring. Balki sizni firk inobatga olinib yanayam yaxshiroq yechim qilinar nima bo'lganda ham biz jamiyatga sifatli maxsulotni yetkazishimiz kerak. Shunday ekan bunga xarakat qilinsa va kurashsa arziydi.

Etiboringiz uchun Rahmat :)

Happy Coding !

Telegram: Kanalim

The things a beginner programmer must know or beginner's problem part 1

Akhmad — Mon, 17 Oct 2022 19:40:59 +0000

Introduction

I've been attempting to assist new programmers in their learning and problem-solving for a while as I've observed their development as programmers. Additionally, I enjoy analyzing how they have grown and developed since I find it fascinating. I've now made the decision to inform the public of the findings of my investigation. I believe that a lot of people will find this material useful. The most important issues and abilities that novice programmers must be aware of or understand are highlighted and explained in this article.

Disclaimer: All the ideas and words in the text are the results of my analysis and my personal beliefs, which have developed as a result of my extended observations. I don't want to disparage, belittle, or stereotype any of the things or themes addressed in this post!

1. Having an individual viewpoint and worldview.

This requirement, if it can even be called that, is straightforward and essential. Right now, our country needs this. The main cause is that many people at the basic level lack personal ideas on a wide range of issues, and instead base their decisions on those of others. That is why I questioned. Work on broadening your perspective of the world and refining your personal ideas before you begin programming.

Analysis of the issue: When I spoke with at least 50 to 60 novice programmers, I found that their personal perspectives on both programming and everyday issues were lacking. Out of 15-20 people with a personal opinion and a broader worldview, almost all of them found their place in the field faster and are still developing well.

Solution: Books, documentaries on various subjects, conversations with individuals or watching interviews, and many sources of travel information (Podcasts, Videos, etc.). Analyze the data you are given.Without believing that so-and-so spoke (Please make me post like this too)! . Develop rational thinking.

2. To communicate an issue and identify a solution or an answer to an inquiry.

This subject is regarded as one of the most current ones in existence today. There are frequently questions with the same template answers, numerous off-topic questions, and low-quality questions in many open programming communities. As if that weren't enough, topics that have nothing to do with the subject at hand are brought up.

Analysis's finding and the source of the issue: In at least 70–85% of instances, the subject of conversations in community groups is repeated. In many communities in particular, this repetition rate is very high. Please use the analysis to persuade me. There are many causes and contributing factors to this situation, but the main one is that world has an excessive number of inexperienced programmers and few resources available in other languages like uzbek other asian... It makes sense from this perspective that this would be the case. But there is another side of the coin. Professionals with experience find the situation monotonous and repetitive.

Solution:Despite the fact that this sentence has been repeated ad nauseam, the answer is to learn a foreign language.

Start by conducting an English or Russian Internet search for answers to your questions. Finding solutions to many problems also involves putting the issue in writing so that Google can understand it. In 95–98% of cases, if the question is written correctly, you will receive a response. In about 50–60% of cases, if you do thorough research, you will find a good response. Work on improving your reporting abilities concurrently. Reports are available on Stackowerflow github. Even when you ask a question to Google in a community, the more precisely you state the issue or question, the better the response you will receive!

3. Just search and try

Not only at the beginning, but also at many of my colleagues, I reached this conclusion. Most people do not search because they are simply interested in a subject. He never conducts research on a subject without a purpose. When something needs to be done or a problem arises, it is sought after. This situation, in my opinion, is totally at odds with engineering.

Analysis's finding and the source of the issue: Some people seem to lack the time for any research because they are difficult to discipline or have other justifications. In the following circumstances, the majority of programmers are searching for something:

1.If you have a problem or need a solution

2.Before the interview

3.When someone asks a question, there is no answer

4.If levelup is near :)

5.And if there is some kind of motivation that is considered serious.

Solution:Make it a daily ritual to read up on programming-related topics, do some research on them, and experiment. Consider taking an hour. Let's just start by introducing ourselves from various topics related to the field; if you've only recently learned programming, look for OOP or other paradigms. What they are, why they are important, how to use them, sample projects, articles or books on the subject. Generally speaking, the primary drivers and causes of your constant search are:

1.You might come across such an issue one day.

2.You'll gain more life experience and perspective.

3.A piece of engineering culture will be yours.

4.There are countless additional reasons, but the main one is that our field is a scientific one and that research is something we must always do.

4. Don't just watch the video!

The majority of new programmers actually hardly ever read the documentation and instead prefer to learn from a video or a live person. But that's not entirely accurate. You must broaden the range of information you consume, so include books, articles, podcasts, and meetups in your daily routine.

Analytical finding and root of the issue: Almost 80–90% of people have read no more than 3–4 books, according to conversations with colleagues with up to 5 years of experience. For no apparent reason, 75% did not read the article. Because of this circumstance, knowledge does not grow on its own.

Solution: As I already stated, it is always important to give something some thought, research, and time before using it in practice.

5.Pet projects

Because knowledge is tested in practice, pet projects are crucial at this stage. It demands serious consideration. Place your own projects on your Github profile. Try cloning something if project ideas are not forthcoming. If you only need to work on short-term, simple projects, you will become stagnant and unable to advance.

Analysis's finding and the issue's root: Only about 15% of developers with 12 to 18 months of experience work on side projects. that they independently created (can be a clone). The majority of Bor's projects were completed while he was taking the course; no projects were completed outside of the course. Practical inexperience results from this.

Solution: Try completing more small tasks or sections of larger tasks. It can appear differently depending on the style. Simply put, you must produce. Experience should be gained through action, which develops the imagination.

There are actually a lot more issues than just these. But for the time being, try to make decisions based on this knowledge. Comment any modifications and differences.I appreciate you paying attention.

Happy Coding ! :)

https://t.me/programming_everyone

Bularni boshlang'ich dastruchi bilishi shart yoxud Beginnerning muammosi 1-qism

Akhmad — Sun, 28 Aug 2022 02:31:00 +0000

Kirish

Ancha muddatdan buyon dasturlashni endi boshlagan dasturchilarni o'sishini kuzataman va ulardagi muammolarni o'rganib hal etishga yordamlashishga xarakat qilaman. Shu bilan bir qatorda ulardagi bo'layotgan o'sish va rivojlanish evalyutsiyasi men uchun qiziq shu sababdan tahlil qilishni yoqtiraman. Endilikda ushbu taxlillarim va hulosalarim natijalarini ommaga ulashishga qaror qildim. O'ylaymanki ushbu ma'lumotlar ko'pchilikga foydali bo'ladi. Ushbu maqolada boshlag'ich dasturchilarning eng birlamchi muammolari va bilishi yoki o'rganishi talab etiladigan ko'nikmalari yortiladi va izohlanadi. Ushbu tavsiyalar ko'proq o'zbek millatidagi insonlarga qaratilgan chunki muammolar bizni millatdoshlarniki asosan.

Disclaimer: Maqoladagi barcha so'zlar va fikrlar mening ancha vaqtdan buyon kuzatuvlarim natijasida hosil bo'lgan tahlillar hulosaasi va subyektiv fikrlarim. Postda tilga olingan obyekt yoki subyektlarni haqorat qilish, millatchilik va kamsitish niyatida emasman!

1. Shaxsiy fikrga ega bo'lish va dunyo qarash.

Ushbu talab (agar talab deyishga arzisa) oddiy bo'lgani bilan juda ham muhim rol o'ynaydi. Ayni bizni millat uchun xozirda juda ham kerakli bo'lgan narsa. Sababi asosiy qatlamdagi insonlarning juda katta qismida ko'p mavzularda shaxsiy fikrlari yo'q va boshqalar fikrlari bilan qaror qabul qilinadi huddi shunday dunyo qarash ham. Shu sababdan iltimos qilar edimki. Dasturlashni boshlashdan avval o'zingiz dunyo qarashingizni kengaytirish va shaxsiy fikrlaringizni rivojlantirish ustida ishlang.

Tahliliy hulosam va muamoni kelib chiqishi: Taxminan kamida 50-60ta boshlang'ich dasturchilar bilan shuxbatlashganimda nafaqat sohaga nisbatan balki oddiy hayotdagi mavzularda ham shaxsiy qarashlari zaif ekanini kuzatganman. Shaxsiy fikrga ega va dunyo qarashi kengroq insonlarning 15-20tasidan deyarli barchasi sohada o'z o'rnini tezroq topgan va xozirgacha yaxshi rivojlanib kelmoqda.

Yechim: Turli mavzudagi hujjatli filmlar, kitoblar, insonlar bilan gaplashish yoki intervyularni ko'rish, sayoxat boshqacha ko'rinishdagi ma'lumotlar (Podcastlar, Videolar vaxakazo). Qabul qilgan ma'lumotaringizni taxlil qiling. Falonchi gapirdi deb ishonib ketmasdan (Iltimos meni ham postimni shnday qiling)!. Ratsional fikrlashni rivojlantiring.

2.Savolga javob topish yoki muammolar yechimmi va muammoni yetkazish.

Ushbu mavzu hozirgi kunda juda actual masalalardan biri xisoblanadi. Dasturlashga aloqador ochiq communitylarning ko'plarida doyimo birxil shablondagi javobi bor bo'lgan savollar va sifatsiz savollar bilan bir qatorda mavzuga aloqador bo'lmagan savollar ham ko'plab beriladi. Bunisi ham yetmaganday mavzuga umuman aloqador bo'lmagan mavzular ko'tariladi.

Tahliliy hulosam va muamoni kelib chiqishi: Community guruhlardagi suxbatlarning mavzusi kamida 70-85% holatda takrorlanadi. Ayniqsa o'zbek communitylarda ushbu takrorlanish ko'rsatkichi juda ham baland. Fikrimga ishonch xosil qilish tahlil qilib ko'ring. Bu holatga sabab va faktorlar ko'p lekin asosiy sabab o'zbekistonda boshlag'ich dasturchilarni juda ham ko'pligi va o'zbek tilida resurslar kam ekanligi. Shu nuqtai nazardan bu holat bo'lishi ham tabiy. Ammo tanganing boshqa tomoni ham bor. Tajribali mutahasisslar bunday muhitda zerikib qolishadi va takr etishadi.

Yechim: Chet tilini o'rganing bu gap million marotaba aytilgan bo'lsa ham ko'p narsanging asosi ham shuda :)
Savollaringizni avvalo internetdan qidirib ko'ring ingliz yoki rus tillarida. Muammoni google tushunadigan qilib yozish ham juda ko'plab savollarga javob topishga yordam beradi. Savolni to'g'ri yozsangiz sizni holatda 95-98% holatda javob topilishi aniq. Yaxshilab qidirsangiz ~50-60% holatsa sifatli javob olasiz. Shu bilan birga reporting skillaringiz ustida ham ishlang. Stackowerflow githubda qilingan reportlarni kuzatsangiz bo'ladi. Communitylarda ham googlega savol berganda ham savol yoki muammoni qanchalik aniq va lo'nda qilsangiz shunchalik sifatli javob olasiz !

3. Shunchaki izlaning va sinab ko'ring

Nafaqat boshlang'ich balki juda ko'plab xamkasblarimda kuzatib shunday hulosaga keldimki. Ko'pchilik shunchaki qandaydur mavzuda qiziqib ko'rmaydi izlanib ko'rmaydi. Hech qanday sabablarsiz nimadur ustida izlanish olib bormaydi. Qachonki nimadur qilish kerak bo'lsa yoki muammo chiqsa izlanadi. Ushbu holat engineeringa umuman teskari deb hisoblayman.

Tahliliy hulosam va muamoni kelib chiqishi: Bazilarida distiplina qilish qiyin bo'ladi yoki boshqacha bahonalar bo'ladi va hech qanday izlanishlarga vaqt qolmaganday tuyuladi. Aksariyat dasturchilar quyidagi holatlarda biror narsa ustida izlanadilar:

Muammo chiqsa yoki biror narsaga yechim kerak bo'lsa
Interviewdan oldin
Kimdur savol berganda javob bo'lmasa
Levelup yaqin bo'lsa :)
Yana qandaydur jiddiy deb xisoblangan turtki bo'lsa vaxakazo.

Yechim: Dasturlashga aloqador mavzularda izlanishni va nimadurlar o'qishni va turli expirementlarni kundalik odatga aylantiring. Masalan 1 soat vaqt ajrating )). Boshlanishiga shunchaki o'zingizni soha atrofidagi topiclardan aytaylik siz endi dasturlashni o'rgangan bo'lsangiz OOP haqida izlaning yoki boshqa paradigmlar haqida. Ularni o'zi nima va nima uchun qanday tadbiq qilish mumkin example projectlarni ko'ring shu mavzularga aloqador maqola yoki kitob o'qing. Umuman olganda siz doyimo izlanishda bo'lishingizga asosiy turtki va sabablar:

Birkun shunday muammoga duch kelishiz mumkin
Dunyo qarash va tajribangiz oshadi
Engineering madaniyatining bir bo'lagi sizda bo'ladi
Yana boshqa minglab sabablar bor asosiy sabab bu sohamiz ilmiy soha bo'lgani uchun katta qismi izlanishlardan iborat va biz doyim izlanish qilishimiz kerak ekanligi !

4.Faqat video ko'rmang !

Ko'pchilik boshlang'ich dasturchilar aslida deyarli docsga ham qarashmaydi asosan videodan yoki biror insondan o'rganishga xarakat qilishadi. Lekin bu unchalik to'g'ri emas. Malumot qabul qilish doirasini kengaytirish kerak buning uchun o'zingizni kundalik menuga kitob, maqolalar, podcast va meetuplarni ham qo'shish kerak.

Tahliliy hulosam va muamoni kelib chiqishi: Tajribasi 5 yilgacha bo'lgan xamkasblar bilan bo'lgan muloqotlar natijasida deyarli 80-90% kishi maksimal holatda 3-4ta kitob o'qigan. 75% qismi esa sababsiz deyarli maqola o'qimagan. Bu holat o'z o'zidan bilim rivojlanmasligiga olib keladi.

Yechim: Yuqorida aytib o'tganimday har doyim N vaqt ajratib nimadur izlanish qilib o'rganishni va dars qilish kerak va bilimlarni amaliyotda qo'llash kerak.

5.Pet projectlar

Bilimlarni amaliyotda sinab tajriba qilinadi shu sababdan pet projectlar bu bosqichda eng asosiy rolda. Bunga jiddiy qarash kerak. Github profilingizga o'zingiz qilgan loyihalarni qo'ying. Loyihalar uchun g'oyalar kelmasa biror narsani clone qilishga xarakat qiling. Faqat qisqa muddatli kichik loyihalar qilish kerak bo'lmasa uzoq vaqt bir loyihada qotib qolasiz va o'smaysiz.

Tahliliy hulosam va muamoni kelib chiqishi: Tajribasi 12-18 oy bo'lgan dasturchilarning juda kam qismida taxminan 15-20% pet projectlari bor. Yani o'zlari o'ylab topgan (clone bo'lishi ham mumkin). Bor projectlarining ko'plari o'rganayotgan kursi davomida qilingan va kursdan tashqari hech qanday loyiha qilinmagan. Bu amaliy tajribasizlikga sabab bo'ladi.

Yechim: Ko'proq kichik projectlar yoki projectlarning qismlarini qilib ko'rish kerak. Turli uslubda turlicha ko'rinishda bo'lishi mumkin. Qisqasi ijod qilish kerak. Expiremetn qilish kerak shu orqali tajriba yeg'iladi tassavur hosil bo'ladi.

Bular hali hammasi emas aslida bundan boshqa yana ko'plab muammolar mavjud. Ammo xozircha shular ushbu keltirilgan ma'lumotlar asosida xarakat qilib ko'ring. O'zgarishlar va firklarni izohlarda qoldiring. Etiboringiz uchun Rahmat

Happy Coding ! :)

https://t.me/programming_everyone

Muvaffaqiyatli Git filialash modeli (A successful Git branching model)

Akhmad — Sun, 27 Mar 2022 21:33:58 +0000

Intro

Ushbu maqolada men turli loyihalarni ishlab chiqish jarayonida tadbiq qilsa bo'ladigan rivojlanish modelini yoritib beraman. Aynan ushbu modelni qo'llashdan oldin judayam ko'plab noqulaylik va muammolarga duch kelgan edim. Ushbu maqolani birqancha resurslardan olgan firklarim va ozgina to'plagan tajribam asosida yozishga qaror qildim. Bu maqola sizga tarmoqlanish strategiyasi (branching strategy) va relizlarni boshqarish (release management) masalalarida foydali bo'ladi degan umiddaman.

Git va Nima uchun Git ?

Gitning boshqa tizimlarga nisbatan farqlarini batafsil ma'lumotlar yetarlicha shu sababdan bu mavzuga batafsil to'xtalmayman. Ammo gitni boshqa alternativ VCS vositalaridan afzal ko'raman. Ushbu tizim bir qancha ishlab chiqaruvchilar ishini birlashtira oladigan eng yaxshi tizim. Shu bilan birga git bilan bu jarayon juda sodda va oson. Git haqida asosiy ma'lumotlar 1-3 bo'limlarda yortilgan. Undan tashqari ushbu mavzuga aloqador boshqa ko'plab resurslar topishingiz.
Men foydalangan va foydalanadigan manbalarni post ohirida qoldiraman!
Qo'shimcha sifatida ayta olamanki Gitda branching va merging amaliyotlari juda ham oson tadbiq qilingan. Versiyani boshqarish vositalari hamma narsadan ko'ra ko'proq tarmoqlanish/birlashishda yordam berishi kerak.

Keling, ishlab chiqish modeliga o'taylik. Men bu erda taqdim etmoqchi bo'lgan model, aslida, boshqariladigan dasturiy ta'minotni ishlab chiqish jarayoniga kelish uchun har bir jamoa a'zosi amal qilishi kerak bo'lgan protseduralar to'plamidan iborat.

Asosiy filiallar (The main branches)

Eng asosiysi ushbu rivojlanish modeliga ko'ra markaziy repositoryda cheksiz umrga ega 2ta filial bo'lishi kerak

master or main
develop or dev

master branch har bir Git foydalanuvchisi uchun tanish bo'lishi kerak. Asosiy branchga paralell ravishta dev deb nomlangan branch bo'lishi kerak. origin/masterda mavjud bo'lgan HEAD manba kodini (source code) productionga tayyor deb hisoblaymiz.

origin/developda mavjud bo'lgan so'ngi HEAD manba kodi (source code) keyingi taqdimot (production|relase) uchun ohirgi ishlab chiqarish o'zgarishlari (development changes) holatni aks ettiradi. Bazilar buni "integration branch" deb atashadi. Bu yerda har qanday avtomatik buildlar sodir bo'ladi.

develop bo'limidagi manba kodi (source code) barqaror (stable) kelib tayyor bo'lganida barcha o'zgarishlar master branchga biriktirilishi (merge) va reliz uchun belgilanishi kerak. Bu jarayon birmuncha intensiv yondoshuvni ham talab etadi. Misol uchun relizlarni versiyalash ham mumkin. Barcha hali reliz qilinmagan o'zgarishlar ushbu branchga birlashadi.

Shuning uchun har safar o'zgarishlar masterga birlashtirilganda by yangi nashr (relase) ekanini anglatadi. Biz ushbu masalaga jiddiy qarashimiz lozim. Dasturiy ta'minotni ishlab chiqish jarayonida yangi reliz uchun maksimal darajada ishonchli va barqaror bo'lishi kerak. Bu bizga loyihamiz sifatli bo'lishini ta'minlaydi.

Qo'llab-quvvatlovchi filiallar (Supporting branches)

Asosiy filiallar master va develop bilan bir qatorda bizning rivojlanish modelimiz jamoa a'zolari o'rtasida paralell rivojlanishga yordam berish, yangilanishlarni kuzatishni onsonlashtirish, relizlardan keyingi chiqgan muammolarni tuzatishga yordam berish uchun turli yordamchi branchlardan foydalaniladi. Asosiy branchlardan farli o'laroq ushbu branchlar vaqtinchalik xisoblanadi chunki ular kerakli ishlar yakunlangach olib tashlanadi.

Biz foydalanishimiz mumkin bo'lgan har xil turdagi branchlar:

Feature branches (Yangi xususiyatlar)
Release branches (Relizlar)
Hotfix branches (Relizda chiqgan xatolarni tuzatish uchun)

Ushbu filiallarning har biri o'ziga xos maqsadga ega va qaysi filiallar ularning boshlang'ich filiali bo'lishi mumkinligi va qaysi filiallar ularni birlashtirish maqsadlari bo'lishi kerakligi haqidagi qat'iy qoidalarga bog'liq.

Hech qanday holatda bu filiallar texnik nuqtai nazardan "maxsus" emas. Filial turlari biz ulardan qanday foydalanishimizga qarab tasniflanadi. Ular, albatta, oddiy eski Git branchlari. Shunchaki semantik nuqtai nazardan qarash to'g'ri bo'ladi.

Xususiyatli filiallar (Feature branches)

Quyidagidan bo'linishi mumkin:
develop
Qayta birlashishi kerak:
develop

Filial nomlash qoidalari (branch naming convention):
Barcha nomlar faqat quyidagilardan tashqari master, develop, release-*, hotfix-*

Xususiyat (feature) yoki biror imkoniyat branchlari (bazan topic branch deb ataladi chunki biror imkoniyat nomi bilan nomlanishi mumkin masalan authentication yoki auth-feauture) yaqin yoki uzoq kelajakdagi versiya uchun yangi imkoniyatlarni ishlab chiqish uchun ishlatiladi. Imkoniyatni ishlab chiqish boshlanganda ushbu imkoniyat birlashtiriladigan versiya xozircha nomalum bo'lishi mumkin. Xususiyat yoki imkoniyat (feauture) branchining mohiyati shundaki, u xusisiyat ishlab chiqarilgunga qadar mavjud bo'ladi lekin oxir-oqibat developga qayta birlashadi (biror ishlab chiqilgan xususiyatni ma'lum versiyaga qo'shish uchun) yoki o'chirib tashlanadi (xafagarchilik tug'diradigan tajriba bo'lsa).

Xususiyat tarmoqlari odatda origin emas, faqat ishlab chiquvchi repolarida mavjud.

Xususiyat bo'limi yasash

Yangi xususiyat ustida ishlashni boshlaganingizda, develop bo'limidan (branch) ajralib chiqing.

$ git checkout -b myfeature develop
Switched to a new branch "myfeature"

Tugallangan xususiyatni `develop` branchiga birlashtirish (merge)

Yakunlangan xususiyatlar ularni kelgusi relizga qo'shish uchun ishlab chiqish bo'limiga birlashtirilishi mumkin:

$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff myfeature
Updating ea1b82a..05e9557
(Summary of changes)
$ git branch -d myfeature
Deleted branch myfeature (was 05e9557).
$ git push origin develop

--no-ff bayrog'i birlashma har doim yangi topshiriq ob'ektini yaratishga olib keladi, xatto birlashtirish oldinga siljish bilan amalga oshirilishi mumkin bo'lsa ham. Bu xususiyat filialining tarixiy mavjudligi haqidagi ma'lumotni yo'qotib qo'ymaydi va ushbu xususiyatni birgalikda qo'shgan barcha majburiyatlarni birgalikda guruhlaydi. Quyidagi rasmni ko'ring:

Ikkinchi holda, Git tarixidan ob'ektlarning qaysi biri birgalikda xususiyatni amalga oshirganligini ko'rishning iloji yo'q - barcha jurnal xabarlarini qo'lda o'qish kerak bo'ladi. Butun xususiyatni (ya'ni, bir guruh majburiyatlarni) qaytarish oxirgi vaziyatda haqiqiy bosh og'rig'idir, holbuki --no-ff bayrog'i ishlatilsa, buni osonlikcha bajarish mumkin.

Ha, u yana bir nechta (bo'sh) ob'ektlarni yasaydi, foydasi zararidan katta.

Reliz branchlari (Release branches)

Quyidagidan bo'linishi mumkin:
develop
Qayta birlashishi kerak:
develop va master
Filial nomlash qoidalari:
relase-*

Reliz branchlari yangi reliz nashrini (new production relase) tayyorlashni qo'llab-quvvatlaydi. Bundan tashqari, ular kichik xatolarni tuzatishga va meta-ma'lumotlarni relizlar uchun tayyorlashga imkon beradi (versiya raqami, tuzilish sanalari va boshqalar). Ushbu barcha ishlarni reliz bo'limida bajarish orqali ishlab chiqish bo'limi (develop branch) keyingi katta versiya uchun xususiyatlarni olish uchun tozalanadi.

Yangi versiyani develop branchdan ajratishning asosiy maqsadi ishlab chiqarish jarayonida aynan ma'lum relizda qilinishi kerak bo'lgan imkoniyatlar yoki tuzatish ishlarini aynan shu relizga bog'lab uni ishlab chiqarish bilan ham birlashtirishdan iborat. Kelajakdagi versiyalarga mo'ljallangan barcha xususiyatlar bo'lmasligi mumkin - ular relizlar tarmog'i bo'linmaguncha kutishlari kerak.

Aynan relizlar bo'limining boshida bo'lajak versiyaga versiya raqami beriladi . O'sha paytgacha ishlab chiqish bo'limi "keyingi versiya" uchun o'zgarishlarni aks ettirdi, ammo bu "keyingi reliz" oxir-oqibat 0,3 yoki 1,0 bo'ladimi, toki reliz bo'limi ishga tushirilgunga qadar noma'lum. Ushbu qaror relizlar bo'limining boshlanishi bilan qabul qilinadi va loyihaning versiya raqamini buzish qoidalari bilan amalga oshiriladi.

Reliz branchini yasash (Creating a release branch)

Reliz branchlari ishlab chiqish (develop) branchidan yasaladi. Misol uchun, 1.1.5 versiyasi joriy ishlab chiqarish versiyasidir va bizda katta reliz bor. Rivojlanish holati “keyingi versiya”ga tayyor va biz bu versiya 1.2 (1.1.6 yoki 2.0 oʻrniga) boʻlishiga qaror qildik. Shunday qilib, biz filialni ajratamiz va reliz branchiga yangi versiya raqamini aks ettiruvchi nom beramiz:

$ git checkout -b release-1.2 develop
Switched to a new branch "release-1.2"
$ ./bump-version.sh 1.2
Files modified successfully, version bumped to 1.2.
$ git commit -a -m "Bumped version number to 1.2"
[release-1.2 74d9424] Bumped version number to 1.2
1 files changed, 1 insertions(+), 1 deletions(-)

Yangi branchni yasab, unga o'tgandan so'ng, biz versiya raqamini ko'ramiz. Bu yerda bump-version.sh yangi versiyani aks ettirish uchun ishchi nusxadagi ba'zi fayllarni o'zgartiradigan xayoliy qobiq skript. (Bu albatta qo'lda o'zgartirish bo'lishi mumkin - bu ba'zi fayllarning o'zgarishidir. Bizning holatda ushbu jarayoni avtomatlashtirib qo'yilgan deb tassavur qilamiz. Jarayon abstakt bo'lgani uchun skript fayl misolida keltirildi) Keyin, buzilgan versiya raqami amalga oshiriladi.

Bu yangi branch albatta chiqarilgunga qadar bir muddat mavjud bo'lishi mumkin. Bu vaqt ichida xatolarni tuzatishlar ushbu branchda qo'llanilishi mumkin (ishlab chiqish develop branchda emas). Bu yerda yangi katta funksiyalarni qo'shish qat'iyan man etiladi. Ular ishlab chiqishga birlashtirilishi kerak agar katta funksionallar qo'shilishi kerak bo'lsa bularni keying relizga o'tkazish kerak bo'ladi.

Reliz branchni tugatish (Finishing a release branch).

Reliz branchning holati haqiqiy reliz bo'lishga tayyor bo'lganda ba'zi harakatlarni bajarish kerak. Birinchidan, reliz filiali masterga birlashtiriladi (chunki masterdagi har bir topshiriq ta'rifi bo'yicha yangi relizdir, esda tuting). Keyinchalik, ushbu tarixiy versiyaga kelajakda oson murojaat qilish uchun master bo'yicha ushbu majburiyat belgilanishi kerak. Va nihoyat, relizlar bo'limiga kiritilgan o'zgarishlarni ishlab chiqishda qayta birlashtirish kerak, shunda kelajakdagi productionlarda ham ushbu xatolar tuzatiladi.

Gitdagi dastlabki ikki qadam:

$ git checkout master
Switched to branch 'master'
$ git merge --no-ff release-1.2
Merge made by recursive.
(Summary of changes)
$ git tag -a 1.2

Chiqarish tugallandi va kelajakda foydalanish uchun belgilandi.

Tahrirlash: Tegingizni kriptografik tarzda imzolash uchun -s yoki -u <key> bayroqlaridan foydalanishningiz ham mumkin.

Reliz branchida kiritilgan o'zgarishlarni saqlab qolish uchun biz ularni qayta ishlab chiqishga (develop) birlashtirishimiz (merge) kerak. Gitda:

$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff release-1.2
Merge made by recursive.
(Summary of changes)

Ushbu qadam birlashma mojarosiga (merge conflict) olib kelishi mumkin (ehtimol xatto versiya raqamini o'zgartirganimiz uchun). Agar shunday bo'lsa, uni tuzating va majburiyatni bajaring.

Endi biz haqiqatan ham tayyormiz va reliz filiali olib tashlanishi mumkin, chunki bizga endi kerak emas:

$ git branch -d release-1.2

Tuzatish filiallari (Hotfix branches)

Quyidagidan bo'linishi mumkin:
master
Qayta birlashishi kerak:
develop va master
Filial nomlash qoidalari:
hotfix-*

Tuzatish branchlari reliz branchlarga juda o'xshaydi chunki ular rejalashtirilmagan bo'lsa ham yangi ishlab chiqarish relizlariga tayyorgarlik ko'rish uchun mo'ljallangan. Ular jonli ishlab chiqarish versiyasining istalmagan holatiga darhol harakat qilish zaruratidan kelib chiqadi. Ishlab chiqarish versiyasidagi muhim xatolik darhol hal qilinishi kerak bo'lsa, tuzatish filiali ishlab chiqarish versiyasini belgilaydigan asosiy filialdagi tegishli tegdan ajratilishi mumkin.

Mohiyat shundan iboratki, jamoa a'zolarining ishi (rivojlanish bo'limida) davom etishi mumkin, boshqa bir kishi esa tezkor ishlab chiqarishni tuzatishni tayyorlamoqda.

Tuzatish branchini yasash (Creating the hotfix branch)

Tuzatish branchlari master branchdan yasalgan. Misol uchun, aytaylik, 1.2 versiyasi jonli ishlayotgan va jiddiy xato tufayli muammolarni keltirib chiqaradigan joriy ishlab chiqarish versiyasidir. Ammo rivojlanishdagi o'zgarishlar hali ham barqaror emas. Keyin tuzatish filialini ajratib, muammoni hal qilishni boshlashimiz mumkin:

$ git checkout -b hotfix-1.2.1 master
Switched to a new branch "hotfix-1.2.1"
$ ./bump-version.sh 1.2.1
Files modified successfully, version bumped to 1.2.1.
$ git commit -a -m "Bumped version number to 1.2.1"
[hotfix-1.2.1 41e61bb] Bumped version number to 1.2.1
1 files changed, 1 insertions(+), 1 deletions(-)

Tarqalgandan keyin versiya raqamini ko'rsatishni unutmang!

Keyin xatoni tuzating va tuzatishni bir yoki bir nechta alohida topshiriqlarda (commit) bajaring.

$ git commit -m "Fixed severe production problem"
[hotfix-1.2.1 abbe5d6] Fixed severe production problem
5 files changed, 32 insertions(+), 17 deletions(-)

Tuzatish branchini yakunlash (Finishing a hotfix branch)

Tugallangach, xato tuzatish (hotfix) yana masterga birlashtirilishi (merge) kerak, lekin xato tuzatish keyingi versiyaga ham kiritilishini taʼminlash uchun uni yana ishlab chiqishga birlashtirish kerak. Bu reliz branchlari qanday tugaganiga to'liq o'xshaydi.

Birinchidan, masterni yangilang va relizni belgilang.

$ git checkout master
Switched to branch 'master'
$ git merge --no-ff hotfix-1.2.1
Merge made by recursive.
(Summary of changes)
$ git tag -a 1.2.1

Tahrirlash: Tegingizni kriptografik tarzda imzolash uchun -s yoki -u <key> bayroqlaridan foydalanishningiz ham mumkin.

Keyinchalik, ishlab chiqishda develop xato tuzatishni ham kiriting:

$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff hotfix-1.2.1
Merge made by recursive.
(Summary of changes)

Bu yerdagi qoidadan bitta istisno shundaki agar hozirda reliz branch mavjud bo'lsa tuzatish o'zgarishlarini ishlab chiqish develop o'rniga o'sha reliz bo'limiga birlashtirish kerak. Tuzatishning reliz bo'limiga qayta birlashtirilishi oxir-oqibat reliz bo'limi tugagach xato tuzatuvchining ham ishlab chiqishga birlashishiga olib keladi. (Agar ishlab chiqishda ish shu zahotiyoq xatoni tuzatishni talab qilsa va reliz bo'limi tugashini kutmasa xato tuzatishni hozirda ishlab chiqishga xavfsiz tarzda birlashtirishingiz mumkin.)

Nihoyat vaqtinchalik branchni olib tashlang:

$ git branch -d hotfix-1.2.1
Deleted branch hotfix-1.2.1 (was abbe5d6).

DEV Community: Akhmad

Htop, top monitoringlardan ma'lumotlar olish.

Statik methodlar bilan yangi yozilgan eski kod (Instant legacy code with static methods).

Kirish

Nimaga ?

Static methodlar anti pattern.

Shunday qilib...

Dastur infratuzulmasi. Sizni loyihangiz qanchalik ozod ?

Kirish

Qaramlik yoki bog'liqliklar oqibatlari.

Ekotizim qurish.

Risklarni ko'rib chiqish yoki baxolash.

Buni nima aloqasi bor ?

Hulosa

The things a beginner programmer must know or beginner's problem part 1

Introduction

1. Having an individual viewpoint and worldview.

2. To communicate an issue and identify a solution or an answer to an inquiry.

3. Just search and try

4. Don't just watch the video!

5.Pet projects

Happy Coding ! :)

Bularni boshlang'ich dastruchi bilishi shart yoxud Beginnerning muammosi 1-qism

Kirish

1. Shaxsiy fikrga ega bo'lish va dunyo qarash.

2.Savolga javob topish yoki muammolar yechimmi va muammoni yetkazish.

3. Shunchaki izlaning va sinab ko'ring

4.Faqat video ko'rmang !

5.Pet projectlar

Happy Coding ! :)

Muvaffaqiyatli Git filialash modeli (A successful Git branching model)

Intro

Git va Nima uchun Git ?

Asosiy filiallar (The main branches)

Qo'llab-quvvatlovchi filiallar (Supporting branches)

Xususiyatli filiallar (Feature branches)

Xususiyat bo'limi yasash

Tugallangan xususiyatni develop branchiga birlashtirish (merge)

Reliz branchlari (Release branches)

Reliz branchini yasash (Creating a release branch)

Reliz branchni tugatish (Finishing a release branch).

Tuzatish filiallari (Hotfix branches)

Tuzatish branchini yasash (Creating the hotfix branch)

Tuzatish branchini yakunlash (Finishing a hotfix branch)

Tugallangan xususiyatni `develop` branchiga birlashtirish (merge)