Code
Professional kod yozish san'ati - Git workflow, code style, linting va testing asoslari bilan tanishing.
Code nima?
Kod - bu dasturchilar kompyuterga buyruqlar beradigan til. Oddiy qilib aytganda, siz kompyuterga "nima qilish kerakligini" yozma shaklda aytasiz. Biroq, professional dasturlashda kod yozish faqat "ishlasa bo'ldi" emas.
Professional kod yozish quyidagilarni o'z ichiga oladi:
- O'qilishi oson bo'lsin - 6 oydan keyin o'zingiz ham tushunasiz
- Qayta ishlatilsin - bir joyda yozib, ko'p joyda ishlatish
- Xatolar kam bo'lsin - testlar va tekshiruvlar orqali
- Jamoa bilan ishlashga mos bo'lsin - Git va code review
Yaxshi kod - bu faqat ishlaydigan kod emas, balki boshqalar (va kelajakdagi siz) oson tushuna oladigan koddir.
Nega kerak?
Ko'p yangi dasturchilar "Kod ishlaydimi? Bo'ldi-da!" deb o'ylashadi. Lekin real loyihalarda bu yetarli emas:
Jamoa ishlashi
Bir loyihada 5-50 odam ishlashi mumkin. Barcha bir xil standartga amal qilishi kerak.
Loyiha uzoq yashaydi
Loyiha 5-10 yil davomida rivojlanishi mumkin. Tartibsiz kod vaqt o'tishi bilan "chigal"ga aylanadi.
Xatolarni tuzatish
Tartibli kodda xatoni topish oson. Chalkash kodda esa soatlab izlaysiz.
Tez rivojlantirish
Yaxshi kod bazasi bo'lsa, yangi funksiyalar qo'shish tez va oson.
Katta kompaniyalarda noto'g'ri yozilgan kod tufayli millionlab dollar yo'qotilgan holatlar bor. Masalan, Knight Capital 2012-yilda 45 daqiqada $440 million yo'qotdi - sabab: eski kod yangi tizimga to'g'ri integratsiya qilinmagan edi.
Asosiy tushunchalar
Version Control (Git)
Version control - bu kodingiz tarixini saqlaydigan tizim. Git eng mashhur version control tizimi hisoblanadi. U sizga imkon beradi:
- Har bir o'zgarishni saqlash va kerak bo'lsa orqaga qaytarish
- Bir vaqtda bir nechta odam ishlashi
- Turli versiyalarni (branch) parallel rivojlantirish
Branching Strategy
Branchlar - bu kodning alohida nusxalari. Eng ko'p ishlatiladigan strategiyalar:
- main/master - production tayyor kod
- develop - rivojlanish jarayonidagi kod
- feature/* - yangi funksiyalar uchun
- hotfix/* - shoshilinch tuzatishlar uchun
Code Style
Jamoadagi barcha dasturchilar bir xil uslubda yozishi kerak. Bu o'z ichiga oladi:
- Nomlash qoidalari (camelCase, snake_case)
- Indentatsiya (tab yoki space, nechtasi)
- Fayllar tuzilishi
- Kommentariy yozish qoidalari
Linting
Linter - bu kodingizni avtomatik tekshiradigan dastur. U topadi:
- Sintaksis xatolarini
- Code style buzilishlarini
- Potensial xatolarni (masalan, ishlatilmagan o'zgaruvchilar)
Amaliy jarayon (step-by-step)
Repository yaratish
Yangi loyiha uchun Git repository oching. GitHub, GitLab yoki Bitbucket dan birini tanlang.
Branch ochish
Har bir yangi funksiya uchun alohida branch oching: git checkout -b feature/login-page
Kod yozish va commit qilish
Kichik, mantiqiy bo'laklarda commit qiling. Har bir commit bitta ishni bajarsin.
Lint va testlarni ishga tushirish
Commit qilishdan oldin linter va testlarni ishga tushiring. Xatolar bo'lsa tuzating.
Pull Request ochish
Ishingiz tugagach, Pull Request (PR) oching. Jamoa a'zolari kodingizni ko'rib chiqadi.
Code Review va merge
Review'dan o'tgach, kod asosiy branch'ga qo'shiladi (merge).
Eng ko'p uchraydigan xatolar
Bir commitda 1000 qator o'zgartirish qilish. Bunday commitni review qilish va xato topish juda qiyin.
"fix", "update", "changes" kabi xabarlar hech narsa aytmaydi. Aniq yozing: "Fix login button not responding on mobile"
Hech qachon main branch'ga to'g'ridan-to'g'ri kod qo'shmang. Har doim PR orqali.
Maxfiy kalitlar va parollarni Git'ga qo'shmang! .gitignore dan foydalaning.
Pre-commit hooks o'rnating - ular commit qilishdan oldin avtomatik tekshiruvlar o'tkazadi.
Best practices
- Har kuni kamida bir marta pull qiling (yangilanishlarni oling)
- Commit xabarlarini imperativ shaklda yozing: "Add feature" emas "Added feature"
- Branch nomlarini standart qiling: feature/, bugfix/, hotfix/
- Har bir PR 400 qatordan oshmasin (ideal: 200-300)
- README.md faylini yangilab turing
- .gitignore faylini to'g'ri sozlang
- Semantic versioning ishlating (v1.2.3)
- Code review'da konstruktiv bo'ling
Asboblar va texnologiyalar
Git
Versiya boshqaruv tizimi. Barcha zamonaviy loyihalarda ishlatiladi.
ESLint + Prettier
ESLint xatolarni topadi, Prettier kodni formatlaydi. Birga juda kuchli.
Husky
Git hooks boshqarish uchun. Commit qilishdan oldin testlarni ishga tushiradi.
Mini misol
Oddiy Git workflow misoli:
# 1. Repository klonlash git clone https://github.com/username/project.git cd project # 2. Yangi branch ochish git checkout -b feature/user-authentication # 3. Kod yozish va o'zgarishlarni staging'ga qo'shish git add src/auth/login.js # 4. Commit qilish (yaxshi xabar bilan) git commit -m "Add user login functionality with JWT" # 5. Remote'ga push qilish git push origin feature/user-authentication # 6. GitHub/GitLab'da Pull Request ochish
ESLint konfiguratsiya misoli:
{
"extends": ["eslint:recommended"],
"env": {
"browser": true,
"node": true,
"es2021": true
},
"rules": {
"no-unused-vars": "warn",
"no-console": "warn",
"semi": ["error", "always"]
}
}
Xavfsizlik va ishonchlilik
- Maxfiy kalitlarni HECH QACHON Git'ga push qilmang. .env fayllarni .gitignore'ga qo'shing.
- GitHub Secrets yoki boshqa secret manager'lardan foydalaning.
- Dependency'larni muntazam yangilang (npm audit, Dependabot).
- Branch protection rules o'rnating - main branch'ga to'g'ridan-to'g'ri push taqiqlang.
- 2FA (ikki faktorli autentifikatsiya) yoqing GitHub/GitLab akkauntingizda.
Ko'p so'raladigan savollar (FAQ)
Git - bu versiya boshqaruv dasturi (local kompyuteringizda ishlaydi). GitHub esa Git repository'larni online saqlash va hamkorlik qilish uchun platforma. GitLab va Bitbucket ham GitHub'ga o'xshash xizmatlar.
Merge - ikki branch'ni birlashtiradi va yangi "merge commit" yaratadi. Rebase esa branch tarixini "qayta yozadi", commitlarni boshqa branch ustiga ko'chiradi. Rebase tarixni toza saqlaydi, lekin shared branch'larda ehtiyot bo'lish kerak.
Oxirgi commit'ni o'zgartirish: git commit --amend. Commit'ni bekor qilish (lekin o'zgarishlarni saqlash): git reset --soft HEAD~1. Butunlay o'chirish: git reset --hard HEAD~1.
.gitignore fayli Git'ga qaysi fayl va papkalarni e'tiborsiz qoldirish kerakligini aytadi. Masalan: node_modules/, .env, build/, *.log kabi fayllarni commit qilmaslik kerak.
Conflict - ikki odam bir faylning bir joyini o'zgartirganda yuzaga keladi. Uni hal qilish uchun: 1) Conflict bo'lgan fayllarni oching, 2) <<<, ===, >>> belgilar orasidagi kodni ko'ring, 3) Qaysi versiyani saqlashni hal qiling, 4) Belgilarni o'chirib, to'g'ri kodni qoldiring, 5) git add va git commit qiling.
Yaxshi format: "type(scope): description". Masalan: "feat(auth): add password reset functionality", "fix(ui): correct button alignment on mobile", "docs(readme): update installation instructions". Conventional Commits spetsifikatsiyasiga amal qiling.
1) Kod ishlayaptimi? 2) Testlar bormi va o'tayaptimi? 3) Code style qoidalariga mos kelayaptimi? 4) Xavfsizlik muammolari yo'qmi? 5) Performance ta'sir qilmaydimi? 6) Dokumentatsiya yangilangan mi?
git stash - joriy o'zgarishlarni vaqtinchalik saqlaydi. Masalan, biror ishni qilyapsiz, lekin tezda boshqa branch'ga o'tishingiz kerak. git stash qiling, branch'ni almashtirib ish qiling, keyin git stash pop bilan o'zgarishlarni qaytaring.