DEV Community: Humoyun Ahmad

Qancha Code Coverage yetarli?

Humoyun Ahmad — Thu, 30 Mar 2023 13:07:15 +0000

Bismillah

Assalom alaykum!

Taxminiy o'qish vaqti: ~3 daqiqa

Code coverage bu dasturiy ta'minotning qanchalik darajada testlanganligini ko'rsatuvchi o'lchov hisoblanadi ya'ni har bir qator kodning test bilan tekshirilgan yoki tekshirilmaganligini ko'rsatib beradi. Umuman olganda dastur qanchalik ko'p testlar bilan qoplangan bo'lsa uning shuncha xavfsiz ekanligini bildiradi, eng kamida nazariyada. Lekin kodning to'liq ya'ni 100% testlar bilan qamrab olish qanchalik foydali, unga ketgan vaqtga o'zi arziydimi? 100% coverage quloqqa chiroyli eshitiladiyu ammo amaliyotda bu unchalik ham yaxshi ko'rsatgich emas.

Quyida 100% lik code coverage ga (test bilan qoplanganlik) intilish bilan bog'liq muammolarni ko'rib chiqamiz:

o'ta yuqori darajali code coverage dasturchilarga soxta xavfsizlik xissiyotini beradi. Chunki testlarni run qilish jarayonida har bir qatorning testlangani degani bu hali har bir qatorning o'z vazifasini to'g'ri bajarishini tasdiqlangani degani emas. 100% tasdiqlangan kod bu umuman buglarsiz kod degani, bu esa amaliy imkonsiz bo'lgan narsa. Xatolar doim bo'ladi, asl maqsad ularni sonini iloji boricha kamaytirish va ularning xavflilik darajasini iloji boricha tushirishdir.
dasturning ba'zi imkoniyatlarini (feature) test qilish ancha mashaqqatli, masalan browserda fayllarni yuklash yoki drag-and-drop. Har bir test foydalanuvchilar nuqtai-nazaridan kelib chiqib yozilishi kerak ya'ni testlarimiz foydalanuvchi dasturning muayyan imkoniyatini qanday ishlatsa uni shunday shaklda o'zida aks ettirishi kerak (e.g. button elementini loading yoki disabled holatini redux yoki useState da saqlayotganimiz foydalanuvchi uchun muhimmas (bilishi kerak ham emas), unga buttondagi visual o'zgarishni ko'rish muhim). Lekin bu holatda odatda ko'plab mocklar ishlatamiz, componentning ichki mexanizmlarini testlarga aralashtirishga majbur bo'lamiz va oxirida esa testlarimiz umuman boshqa shaklga aylanib qoladi va juda ko'p vaqt foydasi kam bo'lgan va o'zgarishlarga chidamsiz bo'lgan testlarga ketib qoladi. Bu esa testlashda "anti-pattern"dir 🚫. Ushbu maqolada Kent C. Dodds buni juda ajoyib qilib tushuntirgan.

mocking odatda unit testlarda ishlatiladi. Qisqa qilib aytganda, mocking bu real obyektlarni vazifasi/funksiyasini bajaruvchi soxta obyektni yaratish. Undan asosiy ko'zlangan maqsad esa testlanayotgan obyektning boshqa obyeklarga nisbatan bog'liqligini iloji boricha kamaytirish ya'ni dependency lardan holi ixotalangan muhit yaratish.

anti-pattern: bu dasturiy ta'minot ishlab chiqishda (ba'zi boshqa sohalarda ham) ko'p takrorlanadigan muammolarga samarasiz va oqibatda yaxshi natijalarga olib kelmaydigan yechimdir (lekin ishlaydigan). Sodda misol:

yaxshi "pattern" kodning takrorlanuvchi qismini alohida funksiyaga olib kerak paytda qayta ishlatish (code-reuse)

"anti-pattern" xuddi shu muammo uchun har safar copy-paste ishlatish.

Ko'p dasturchilarning tajribalaridan kelib chiqadigan bo'lsak, odatda ~100% lik code coverage 2 ta holatdagina foydali:

kutubxonalarda (library), tasodifiy breaking change 💥 lardan saqlanish juda ham muhim. Chunki bunday kutubxonalarni odatda minglagan yoki hatto millionlagan dasturchilar ishlatatishi mumkin (log4j eslang).
va open source ya'ni ochiq kodli proyektlarda, chunki bunday proyektlarda contributorlarning ko'pgina qismi proyektni arxitekturasi bilan to'liqligicha tanish bo'lishmaydi.

breaking change bu kutubxonaning yoki har qanday dasturiy ta'minotning (REST API, SDK, UI Toolkit...) biron qismidagi o'zgarish unga bog'liq bo'lgan tizimning boshqa qismlariga ham ta'sir qilishi (to'liq yoki qisman ishdan chiqarish) mumkin bo'lgan o'zgarishdir. Odatda bunday o'zgarishlar dasturiy ta'minot (DT) foydalanuvchilariga (bu holatda dasturchilar) oldindan o'sha DTning rasmiy websayti yoki boshqa yo'llar orqali bildiriladi (bildirilishi zarur ham).

Xo'sh unda o'rta yo'l qayerda, buni aniq aytish qiyin, odatda bu muayyan dasturiy ta'minotga, jamoaga va undagi qabul qilingan prioritetlarga bog'liq, o'rtacha dastur kodining 60-70 foizi testlar bilan qoplanganligi bu yaxshi ko'rsatgich (lekin bu meni subyektiv fikrim).

Code coverage uchun vositalar:

Static Testlash: Linting va Formatting

Humoyun Ahmad — Tue, 28 Mar 2023 13:04:04 +0000

Bismillah!

Taxminiy o'qish vaqti: ~5 daqiqa

Assalom Alaykum!

Dasturchi sifatida yozgan har bir kodimiz iloji boricha clean, consistent va simple bo'lishi kerak. Shunday bo'lsinki, 3-4 oy yoki hatto 3-4 yildan keyin ham bu kodni kim yozgan o'zi deb jig'i biyron bo'lishmasin. Bundan tashqari jamoaga yangi qo'shilgan dasturchilar uchun kodning muayyan qoida va qonuniyatlar bo'yicha yozilgani ularning tezda dastur kodiga ortiqcha qiyinchiliklarsiz hissa qo'shishlariga yordam beradi. Bu esa o'z navbatida dasturning kodiga (codebase) ortiqcha zo'riqishlarsiz o'sish, kengayish va unga yangi imkoniyatlarning qo'sha olishlik xususiyatlarini beradi. Har qanday muvaffaqiyatli dasturiy ta'minot (software product or service) bu xususiyatga ega bo'lishi shart. Bu ham aslida bir san'atdir ya'ni dasturlash sa'nati. Bu narsaga erishishda bizga katta yordam beradigan amaliyotlardan biri bu code stylelardir.

Code style bu kod yozishning muayyan qoidalari/usullari bo'lib uzoq muddat davomida biron dasturlash tilida ishlash jarayonida orttirilgan tajribalar asosida tajribali dasturchilar tomonida yig'ilgan qoidalar majmuasidir.

Quyida JavaScript uchun ushbu qoidalardan namunalar keltirilgan cheatsheet:

Sifatli dasturiy ta'minotlarni ishlab chiqarishda bu amaliyotlarning o'rni kattadir. Quyida ushbu amaliyotlarni amalga oshirishda frontendda ishlatiladigan eng ommabop vositalar bilan tanishib chiqamiz. ESLint dastur kodini statik analiz qilish vositasi bo'lib, to'g'ri va izchil kod yozishda muayyan qoidalariga amal qilinishini ta'minlaydi. Prettier esa dastur kodini to'g'ri va chiroyli formatga keltirishga yordam beradi. Unit testlar haqida esa pastroqda, umumiy testlash bo'limida, bafurja gaplashamiz.

Eslint & Prettier -> Clean & Consistent Code

Unit Testing -> Correct Code

Linting va formattingni proyektimizga qo'shganimizda biz butun jamoa a'zolarini o'zaro belgilangan muayyan coding stylega (e.g. airbnb) amal qilgan holda kod yozishini kutamiz. Lekin bazida gitga push qilayotganimizda bu qoidalar esimizdan chiqib qoladi yoki erinchoqlik qilib yoki uzoq muddat kod yozib charchab bunga amal qilmaymiz. Ba'zi jamoalarda esa bu qoidalarga deyarli amal qilinmasligini guvohi bo'lishi mumkin (ESLint o'rnatishni unda nima keragi bor?). Demak, buning oldini olish uchun har doimgidek bu amaliyotlarni avtomatlashtirish kerak. Bunga esa gitdagi hooklar yordamida osongina erishish mumkin, commit yoki push eventlaridan oldin o'zimiz belgilab olgan scriptlarni run qilamiz (ishga tushuramiz). Yuqoridagi amaliyotlarni avtomatlashtirish uchun bizga quyidagi vositalar kerak bo'ladi:

lint-staged aynan "staged" fayllar bilan ishlashga mo'ljallangan bo'lib (ya'ni proyektimizni lokal reposiga yangi qo'shilgan yoki o'zgartirilgan lekin hali commit qilib ulgurmagan fayllar) linting qilinishi kerak bo'lgan fayllarni sonini cheklaydi, bu esa ishlash jarayonini ancha tezlashtiradi (5-6 tagina o'zgartirilgan fayllar uchun minglagan fayllar ustida linting qilish vaqtni zoe qilishdir). husky esa gitning hook mexanizmi bilan ishlashni osonlashtiradi. Bizni qiziqtirgan asosiy git hook bu pre-commit bo'lib, kodga kiritgan o'zgartirishlarimizni lokal repoimizga commit qilishdan oldin, bajarilishi kerak bo'lgan amaliyotlarni (linting, testing...) run qilib olishimiz uchun imkon beradi.

Oddiy setup

Keling ushbu vositalarni kompyuterimizga o'rnatib ko'ramiz:

npx mrm lint-staged

mrm open source proyektlarni konfiguratsiyalarini avtomatlashtiruvchi vosita. mrm bilan lint-staged va husky ni osongina setup qila olamiz.
Yuqoridagi kommandani run qilganimizdan so'ng .husky degan folder proyektimizni root qismida hosil bo'ladi va package.json fayliga quyidagi qatorlar qo'shib qo'yiladi:

{
  "scripts": {
    "prepare": "husky install"
  },
  "devDependencies": {
    "husky": "^6.0.0",
    "lint-staged": "^11.0.0",
  },
  "lint-staged": {
    "*.js": "eslint --cache --fix"
  }
}

Odatda, mrm o'rnatgan oddiy konfiguratsiya ko'p use caselar uchun yetarli.

.husky degan folderdagi pre-commit degan faylga qarasak, quyidagi setupni ko'ramiz:

#!/bin/sh
. "$(dirname "$0")/_/husky.sh"

npx lint-staged

Endi esa lint-staged: u birozgina qo'shimcha setup talab qiladi, har bir jamoa o'zi ishlatadigan vositalarni shu buyruq orqali run qilishi mumkin, quyida bizni jamoa ishlatadigan konfiguratsiya misol sifatida berilgan:

  "lint-staged": {
    "./src/**/*.{ts,tsx}": [
      "yarn depcheck:validate",
      "prettier --write",
      "yarn lint --fix --max-warnings 0",
      "yarn test"
    ]
  },

Endi esa sinab ko'ramiz:

git add .
git commit -m "JIRA-777 ushbu commitga qisqacha sharh"

Commit komandasini run qilishingiz bilan terminalingizda eslint, prettier va unit testlarni ishlayotganini ko'rasiz.

So'ngra esa yo muvaffaqiyatli commit yoki biron linting bilan bog'liq xatolar yoki muvaffaqiyatsiz testlarni guvohi bo'lasiz (xuddi yuqoridagi skrinshotdagidek). Muvaffaqiyatli commitdan so'ng esa bemalol remote repoimizga yangi qo'shilgan o'zgarishlarni push qilamiz!

ESlint vs Prettier ziddiyati

Agar ESLintni Prettier bilan ishlatishni xohlasak (ishlatishimiz kerak ham) albatta bu ziddiyatga duch kelishimiz muqarrar ya'ni ESLintning formatlash qoidalari bilan Prettierni formatlash qoidalari albatta bir biri bilan kelishmay qoladi.

Buning yechimi esa juda oddiy, shunchaki ESLintning formatlash bilan bog'liq qoidalarini o'chirib qo'yamiz, Prettierga o'zini ishini qilishga halaqit bermasligi uchun. Hamma o'zini ishini qilgani maqul (bu bilan Linux targ'ib qilgan dasturlash falsafasiga: Write programs that do one thing and do it well ham amal qilgan bo'lamiz). Bu maqolada buni amaliyotda qanday qilishga to'xtalib o'tirmadim, chunki bu narsa haqida allaqachon 10 lagan yaxshi maqolalar mavjud, quyida ulardan ba'zilarini keltirib o'tdim.

Boshqa muhim amaliyotlar

Har qanday proyektda agar unda ko'plab dasturchilar birgalikda ishlashar ekan, code stylelardan tashqari dasturlash uchun muhim bo'lgan boshqa umumiy konvensiyalar va jarayonlarni (semantic commits, git branching strategy, pull requests, ...) ham kelishib olish ya'ni ish jarayonining bir qismiga aylantirish yaxshi ROI olib keladi. Muayyan proyekt ustida qancha ko'p dasturchi ishlayotgan bo'lsa, yuqorida sanab o'tilgan konvensiyalar va jarayonlarning ahamiyati shuncha ko'p bilinadi chunki ular ishtirokchilarning samarali muloqot qilishlari uchun umumiy asos yaratib beradi. Bundan tashqari, ularni sifatli qo'llash hozirgi kunda har qanday zamonaviy dasturiy ta'minot yaratishning asosi bo'lgan CI/CD pipeline (DevOps) o'rnatish jarayoniga katta yordam beradi. Quyidagi linklar yordamida ushbu mavzular haqida kengroq ma'lumot olsangiz bo'ladi

Last but not least

Bu qismdagi yana eng muhim bo'lgan narsalardan biri bu static type checking system, TypeScript yoki Flow kabi, bu mavzuni o'zi ancha katta bo'lgani uchun boshqa maqolada alohida to'xtalib o'tamiz. Bunday vositalar dasturchiga type safety xususiyatini ya'ni dastur kodini iloji boricha xatolardan holi va barqaror bo'lishini (stable) ta'minlab beradi. Bundan tashqari, ushbu vositalar IDElar bilan birgalikda

error highlighting

autocomplete

automated refactoring

auto-documentation

kabi DX (developer experience) ni oshiradigan qulayliklarni ham taqdim etadi.

Testlash o'zi nimaga kerak, tinchgina yashasak bo'lmaydimi!

Humoyun Ahmad — Tue, 21 Mar 2023 02:28:22 +0000

Bismillah!

Taxminiy o'qish vaqti: ~5 daqiqa

Assalom Alaykum!

O'tgan qismimizda asosan frontend dagi relizgacha bo'lgan barcha jarayonlarni umumlashtirilgan shaklda ko'rib chiqdik. Bu va bundan keyingi qismlarda dastlabki maqolada keltirilgan mavzularga kengroq kiramiz va ularni qanday oddiy setup qilishlikni ko'rib chiqamiz. Bugun shu mavzularga kirish qismi qilamiz!

Ushbu turkum maqolalarda ishlatilgan barcha kodlarni quyidagi github repodan topishingiz mumkin: testing-demo-app. Alohida repodan asosiy maqsad ham bu mavzularni iloji boricha amaliy ko'rinishga keltirishdir.

humoyun / testing-demo-app

React Testing Demo App

This repo is developed for showing how to setup all necessary modern tooling and good practices for development and bootstrap tests with React (both Jest and Cypress)

Available Scripts

In the project directory, you can run:

yarn install: run this after cloning project to install all necessary dependencies

yarn postinstall: run this to setup pre-commit

yarn start: run this to start an app

yarn test: run this to run all tests

yarn start:msw: run this to start app in mocking mode

yarn cy:open: run this to open Cypress in UI mode

yarn cy:run: run this to open Cypress in headless mode

npm run build:

Extra steps

Need to setup relative path resolving using tspath as tsconfig baseUrl is only helpful on compile time, in order to resolve after it is transpiled into JS it cannot resolve TS configs…

View on GitHub

Testlash o'zi nimaga kerak, tinchgina yashasak bo'lmaydimi!

Spoiler: Ground truth of testing is the confidence! 😊

Hozirgi kunda sifatli dasturiy ta'minotni ishlab chiqish jarayonini testlarsiz tasavvur qilish qiyin. Yozayotgan kodimiz doimo to'g'ri ishlashiga ishonch hosil qilishimiz uchun albatta ularni testlar bilan himoyalab qo'yishimiz lozim. Chunki tabiatan har qanday dasturiy ta'minot vaqt o'tishi bilan o'zgarishlarga mahkum va har qanday o'zgarishlardan keyin ham uning to'g'ri ishlayotganiga ishonch hosil qilishimiz uchun ham testlarni yozamiz. Ho'p test yozish muhim ekan lekin ularni qanday yozamiz, ularning qanday turlari bor, ularni yozishda qandaydir usullar, qonun qoidalar ham bormi... Shu va shunga o'xshash savollar test yozishni yangi boshlayotganlarda bo'lishi tabiiy. Keling shular haqida biroz gaplashamiz.

Little story: Esimda, bundan taxminan 3 yilcha oldin Agoda bilan bo'lgan intervyumda Agodani senior engineeri mendan: hozirgi ishxonangda testlarni qanday yozaslar deb soragandi. Uhh dedim ichimda, xo'sh testlar yozish nimaligini bilaman, ahamiyatini ham, o'zimcha bir nechta test yozib ko'rganman, lekin baribir ishxonamda yozmaymizku. Aldashni keragi yo'q, deb to'g'risini aytdim. Bizda test yozilmaydi, chunki startup bo'lganimiz uchun vaqtimiz kam (oo ajoyib bahona keltirdim deb o'yladim ichimda). U esa menga kulib, bizni ham vaqtimiz kam, vaqtimiz yana ham kamaymasligi uchun test yozamiz deb javob berdi. Shu suhbatdan keyingina, testlarning haqiqiy ahamiyatini tushundim (shekilli?).

Har qanday ishga tizimli tarzda yondashish doimo yaxshi natija beradi. Testlarni yozishda bunday tizimli yondashuv odatda testlash strategiyasi deb nomlangan bo'lib ular turli test turlarini qanday kombinatsiyalarda bo'lishini muayyan bir qolipga solib tashkillashtirishni anglatadi. Dasturchilar orasida ko'p tarqalgan bunday strategiyalardan biri bu Testing Pyramiddir. Unga ko'ra UI testlar (ba'zida e2e testlar nazarda tutiladi) bu eng qimmat, eng ko'p vaqt talab qiladigan va eng sekin ishlaydigan testlardir, unit testlar esa aksincha eng tez va eng oson yoziladigan, kam mashaqqat talab qiladigan jarayondir.

Unit testlar bu dastur kodining eng kichik va o'zi mustaqil biron amal bajara oladigan bo'lagini testlaydi xuddi funksiya yoki React component kabi. Ularni run qilishimiz uchun bizga browser, server yoki database kerak emas shuning uchun ularni ishlashi juda tez.
UI testlarni (odatda e2e nazarda tutiladi) run qilish uchun esa butun boshli dasturni browserda ishga tushirish kerak bo'ladi, odatda haqiqiy server va database bilan birgalikda, so'ngra esa bu testlar hosil qilgan trash datani tozalalashimiz (o'chirish) kerak. Yuqorida ham aytib o'tilganidek, bu ko'p vaqt oladigan jarayon, va ularni yozish ancha mashaqqatliroq.
Integration testlar esa (service yoki funksional deb ham nomlanadi ba'zida) bu ikki turdagi testlarni orasida joylashgan. Ular dasturning bir nechta o'zaro bo'gliq qismlarini tekshiradi lekin browsersiz va odatda haqiqiy serversiz.

Demak biz ko'plab unit testlar va birozgina UI testlar yozishimiz kerak, shundaymi?

Bu uslub sinalgan va ishlaydigan strategiya bo'lishiga qaramay, frontendga qo'llashda o'ziga yarasha kamchiliklari ham bor, bundan tashqari bu strategiya tanishtirilgan vaqtni ham hisobga olish juda muhim. Ajax revolyutsiyasidan oldin JavaScript odatda formalarni validatsiya qilish va sodda animatsiyalarni hosil qilish kabi oddiy amaliyotlar uchungina ishlatilalardi va u paytlari testing uchun ayniqsa frontendda testlar yozish uchun vositalar kam va imkoniyatlari cheklangan bo'lishiga qaramay o'sha vaqtdagi talab va ehtiyojlariga javob bera olardi. Lekin so'nggi 10 yillikda web va uning atrofidagi texnologiyalarning soni va imkoniyatlari ancha kengaydi bu esa frontendning ancha murakkablashuviga olib keldi. SPA ya'ni client-side routing, client-side state management va client-side rendering kabi texnologiyalar va bular atrofidagi juda ko'plab frameworklar va librarylar web dasturlash olamiga kirib keldi va testlashdagi oldingi usullar, texnologiyalar va vositalar hozirgi kun frontenddagi testlash talablarini va ehtiyojlarini to'liq qondira olmay qoldi. Bunga yana quyidagi sabablarni ham ko'rsatish mumkin:

frontend da UI doimiy o'zgarishda (funksional hech narsa o'zgarmasa ham), bu esa ko'p yozilgan unit testlarni fail bo'lishiga olib kelaveradi va har doim biron styling bilan bog'liq o'zgarish qilganimizda unit testlarni o'zgartirishimizga to'g'ri keladi.
unit testlar qanchalik ko'p bo'lmasin va barchasi muvaffaqiyatli ishlamasin agar ular tasdiqlab bergan dasturning qismlari birgalikda to'g'ri ishlamasa unda ulardan katta naf bo'lmaydi. Buning muqobilida, agar bu qismlar birgalikda to'g'ri ishlasa unda juda ko'p unit testlarni yozishga ham hojat qolmaydi. Chunki shuning o'zi dasturning imkoniyatlari to'g'ri ishlayotgani haqida bizga yetarli confidence ya'ni ishonch darajasini bera oladi.

Balki frontendda test yozishda sal boshqacharoq yondashuv kerakdir?

Frontendda testlashning zamonaviy strategiyalardan biri bu Testing Trophy.

Modern Testing Trophy	Standard Testing Pyramid

Testing Trophy 🏆

Bu strategiya ko'ra eng katta ROI (return on investment) bu integration testlarda.

ROI - sarflangan xarajat yoki mashaqqatlarga nisbatan keltirilgan natija yoki foyda.

Integration testlar dasturning muayyan imkoniyatlarini (feature) yoki butun boshli sahifani to'liq tekshiradi lekin odatda haqiqiy backend va databasega ulanmagan holatda. Masalan, quyidagi auth flow ni misol qilib olishimiz mumkin (Login sahifasini):

Login sahifamizni render qilamiz (oldinlari odatda browsersiz JSDOM kabi headless runtimeda edi hozir esa Cypress kabi zamonaviy testlash vositalari yordamida to'g'ridan to'g'ri browserni o'zida ham render qilsa bo'ladi)
username va password input elementlarini topamiz va kerakli test user credentiallarni kirgazamiz.
Sign In buttonni topamiz va Click.
To'g'ri request yuborilganini tekshiramiz.
Oxirgi bosqich holatga qarab har xil, misol uchun:
- Login sahifasidan dasturning asosiy qismiga redirect qilinganligi va biron textning asosiy sahifada borligini tekshirish yoki...
- SessionId yoki JWT token ni cookie yoki localStoragega yozilganligini tekshiramiz yoki...
- va hokazo

Lekin bu jarayonda network requestlar serverga yetib bormaydi va msw kabi vositalar yordamida bu requestlar intercept qilinib mock natijalar qaytariladi bunga keyinroq to'liqroq misol bilan to'xtalamiz.

Keling endi unit va integration testlarni solishtiramiz:

Unit testlar	Integration testlar
bitta test faqat bitta kichik dastur qisminigina qoplay oladi (e.g. funksiya yoki component) odatda har bir refactoringdan keyin o'zgartirishga to'g'ri keladi. odatda implementation detallaridan holi tarzda testlash qiyin ya'ni testdagi ketma-ketliklar foydalanuvchilarning dasturni ishlatishdagi ketma-ketliklariga mos tushmaydi LOW confidence. 💧	bitta test butun boshli userflow, featureni yoki hatto sahifani ham qoplaydi. odatda refactoringdan o'zgarishsiz chiqadi implementation detallaridan deyarli holi va foydalanuvchilar dasturni ishlatishidagi ketma ketliklarni yaxshi aks ettiradi HIGHER confidence. 💪

Oxirgi farq bu yerda eng muhim jihatlardan biridir ya'ni turli testlar beradigan turli ishonch darajalari (level of confidence)! Integration testlar bizga dasturiy ta'minotimiz kutilganidek ishlayotganiga yetarli darajada ishonch bera oladi. Bu qolgan testlarni yozish kerak emas degani ham emas, shunchaki asosiy vaqt va e'tiborni integration testlarga berish bizga yaxshi natija olib keladi.

user flow - dasturda muayyan natijaga foydalanuvchi qanday erishishini ko'rsatuvchi ketma-ketlikdir (e-commerce appda muayyan mahsulotni topish, uni korzinkaga qo'shish va checkout qilish).

implementatsiya detallari - dasturimizning ichki ishlash mexanizmi bo'lib foydalanuvchilarga ko'rinmaydi va dasturning spesifikatsiyasida ham ko'rsatilmaydi. Dasturchini ishlashi jarayonida hosil bo'lib boradi va odatda vaqt o'tishi bilan o'zgarishlarga mahkum.

Quyida integration testlarni muhimroq ekanligi haqida keltirilgan ajoyib xazilomuz gif (original tweet muallifi Erin McGrath)

expect(umbrellaOpens).toBe(true)

tests: 1 passed, 1 total

**all unit tests passed, hooray**

Demak xulosa:

Xo'sh testlash, testlarning turlari va testlash strategiyasi haqida bilib oldik va Testing Trophy strategiyasini frontend uchun tanlab oldik. Keyingi maqolalarda ularning har bir qatlami bilan alohida alohida tanishib chiqamiz.

Little React productivity boost by 'curried' function

Humoyun Ahmad — Sun, 12 Jun 2022 11:56:15 +0000

Assalom alaykum!

React da ko'pincha ushbu holatdagi event handler larni ishlatilishini guvohi bo'lamiz ya'ni odatda implicit bo'lgan dastlabki event argumentimizga qo'shimcha tarzda 2 - argumentni ham funksiyamizga yuborishga to'g'ri keladi:

const handleChange = (e: Event, type: string) => {
  // input event va type bilan bog'liq kodimiz
}

return (
  <>
    <!-- ... -->
    <input onChange={(e) => handleChange(e, 'line')} />
    <!-- ... -->
    <input onChange={(e) => handleChange(e, 'point')} />
    <!-- ... -->
    <input onChange={(e) => handleChange(e, 'polygon')} />
    <!-- ... -->
  </>
)

Ushbu kod albatta xatosiz ishlaydi lekin bu yerda muammo onChange event handler funksiyamizni yoyishga to'g'ri keladi ya'ni:

onChange={handleChange} => onChange={(e, arg1) => handleChange(e)}

Bundan tashqari kodimiz unchalik ham clean emas. Balki bu usulni bitta joyda ishlatsak uncha bilinmas lekin bu kodimiz bir nechta joyida qayta-qayta ishlatilsa ayniqsa refactor qilishda muammo yaqqol ko'rinadi.

Sodda yechim: curried funksiya bilan kodimizni quyidagi elegant & clean ko'rinishga olib kelishimiz mumkin:

const handleChange = (type: string) => (e: Event) => {
  // input event va type bilan bog'liq kodimiz
}

return (
  <>
    <!-- ... -->
    <input onChange={handleChange('point')} />
    <!-- ... -->
    <input onChange={handleChange('line')} />
    <!-- ... -->
    <input onChange={handleChange('polygon')} />
    <!-- ... -->
  </>
)

Ya'ni funksiya qaytaradigan funksiyani event handler sifatida ishlatamiz.

Curried funksiyalar haqida ushbu linkdan batafsil ma'lumot olishingiz mumkin: https://javascript.info/currying-partials

CI/CD o'zi nima?

Humoyun Ahmad — Fri, 27 May 2022 15:40:01 +0000

Bismillah!

Taxminiy o'qish vaqti: ~6 daqiqa

Assalom Alaykum!

Diskleymer: ba'zi atamalardan shundayligicha foydalanildi, tarjimasi ga'latiroq yoki notanish ko'rinmasligi uchun. Ba'zi iboralar esa ixchamroq ko'rinishga keltrildi, release -> reliz.

Ushbu turkum maqolalardan ko'zlangan asosiy maqsad, web servislarini reliz qilish jarayoni bilan qiynalayotgan, dasturning yangi imkoniyatlarni foydalanuvchilariga ishonchli va tez yetkazishda muammolarga duch kelayotgan jamoalar (team) uchun frontendda qo'llaniladigan keng tarqalgan amaliyotlarni jamlagan muxtasar qo'llanma sifatida yozildi. Maqoladagi ko'rsatmalar asosan kamida 2-4 kishilik jamoa bo'lib ishlayotgan frontend dasturchilar uchun qaratilgan bo'lsada, ba'zi umumiy tushunchalar backend developerlar uchun ham foydali bo'lishi mumkin. Ushbu post juda ko'plab men tanigan va shaxsan tanimagan dasturchilarning tajribalaridan kelib chiqib yozilganiga qaramay albatta xato va kamchiliklardan holi emas. Agar biron xato yoki kamchilik topsangiz albatta sharhlar bandida buni bildiring!

reliz bu muayyan davr (e.g. sprint) mobaynida dasturiy ta'minotga yangi qo'shilgan feature ya'ni imkoniyatlar va bugfix ya'ni dastur xatolariga tuzatmalarning foydalanuvchilarga taqdim etilishidir. Boshqa til bilan aytsak, muayyan dasturiy ta'minotning oxirgi/yangi versiyasini productionga chiqarish.

`CI/CD` o'zi nima?

Dasturiy ta'minotni reliz qilish, agar to'g'ri tashkil etilmasa, bosh-og'riq-beruvchi va ko'p vaqt talab qiladigan jarayon bo'lishi mumkin. Kodni reliz qilishga tayyor bo'lish bilan bog'liq vaqt majburiyatlari ya'ni deadlinelar ( savdo/marketing bo'limlari bosimi ostida) asab torlarini yanada taranglashtiradi. Buni hal qilishni oson yo'li bormi? Albatta bor, CI/CD 🚀

CI ya'ni Continuous Integration: dastur kodiga qo'shilgan har bir o'zgarishni (git commit) dastur kodi joylashgan markaziy repositoryga avtomalashtirilgan shaklda davomiy qo'shib borish
CD ya'ni Continuous Delivery(Deployment): dastur kodini avtomalashtirilgan shaklda doimiy deploy qilish amaliyoti.

CI/CD dasturiy ta'minot ishlab chiqish va shu jarayon bilan bog'liq bo'lgan barcha operativ ishlar o'rtasida ko'prik vazifasini bajaruvchi avtomalashtirilgan amaliyotlar majmuasidir (operativ ishlar: server, DB, OS, virtualization, containerization, dependent libs va boshqa dastur ishlashi uchun zarur bo'lgan vositalarni o'rnatish, boshqarish va davomiy xizmat ko'rsatib turish). Boshqa rakursdan qaraganda esa, CI/CD bu so'nggi 10 yillikda dasturiy ta'minot ishlab chiqishning de-facto standartiga aylangan Agile & DevOps madaniyat/harakatining namoyon bo'lishi ya'ni realizatsiyasidir.

deployment yoki deploy qilish bu dastur kodini ishchi holatga keltirishdir.

CI/CD ko'p IT kompaniyalarda o'z dasturiy mahsulotlarini (webapp, web-service, mobile app va hkz) foydalanuvchilariga qulay, tez va sifatli tarzda yetkazib berishini yangi darajaga olib chiqdi. CI/CD, ya'ni dasturiy ta'minot ishlab chiqish jarayonining barcha bosqichlarini iloji boricha avtomatlashtirish, har qanday jamoaga (kompaniya) quyidagi imkoniyatlarni taqdim etadi:

risklarni kamaytirish: avtomatlashtirilgan testlar dasturiy ta'minotning ishonchliligini yaxshigina kafolatlaydi va keyingi relizlarda ham regressiyalar yuz berish ehtimolini ancha kamaytiradi yoki yo'qotadi.
better code quality: dastur kodininig sifatli bo'lishiga ya'ni uning izchil va muayyan kodlash qoidalariga amal qilinishini osonlashtiradi.
davomiy va bir maromdagi relizlarni chiqarish imkoniyati: dasturning yangi versiyasini deploy qilish anavaviy usullardan ko'ra ancha qulay, oson va tezroq.
bozorga tezroq kirish: CI/CD pipeline dan asosiy ko'zlangan maqsadlardan biri ham tayyor bo'lgan dasturiy mahsulotni, keyinchalik esa uning yangi imokoniyatlarini foydalanuvchilarga tez yetkazib berib turishni ancha osonlashtirishdir.
yangi qo'shilgan lekin muammoli featurelarni tezda va ortiqcha qiyinchiliklarsiz revert ya'ni ortga qaytara olishlik qobilyatini beradi.
dasturchilar va operativ ishchilar (e.g. sysadmin) o'rtasidagi friction ya'ni kelishmovchiliklarni oldini oladi.
dasturchilarning vaqtini tejash: dasturchilarning vaqti juda qimmat, shuning uchun ularning asosiy vaqti kod yozish bilan o'tishi kerak, production ga chiqarilgan relizdagi muammolarni topish bilan emas.

Demak reliz qilishgacha bo'lgan deyarli barcha jarayonlarni avtomatlashtirish ya'ni inson omilini kamaytirish orqali dasturiy ta'minotning iloji boricha xatolardan holi, barqaror va sifatli bo'lishiga olib keladi.

CI/CD pipeline: dastur kodidagi o'zgarishlarni asosiy repoga qo'shishdan tortib to uni reliz qilishgacha bo'lgan barcha ketma-ket o'zaro bog'liq bosqichlarni o'z ichiga olgan jarayonning nomlanishi. Mingta gapdan bitta rasm yaxshiroq.

Jamoa bilan yangi CI/CD pipelineni ishlab chiqar ekanmiz, (yoki allaqachon mavjud bo'lganini takomillashtirish bo'lsin) bu ishda eng muhim jihatlardan biri bu asosiy kuchni qayerga yo'naltirishni aniq qilib olish:

formatlash, linting, unit/integration testlar va code coverage
jamoadagi dasturchilarning muayyan kodlash qoidalariga rioya qilib kod yozishi va doimiy unit/integration testlar yozib turishi jamoani samaradorligini, uzoq muddatli tezligini (lekin boshlanishida ko'proq vaqt oladi) va barqarorligini sezilarli oshiradi. Demak ushbu qismni dasturdagi kichik miqyosli ammo muhim xato va kamchiliklarini aniqlovchi birinchi himoya fronti sifatida ko'radigan bo'lsak, bu yerdagi amaliyotlar asosan muayyan jamoa tarkibidagi dasturchilargagina ta'sir etadi. Bu amaliyotlarning asosiy farqlovchi xususiyati bu tez ishlashi (bir necha soniyalar) va agarda xato topilsa ham tezda fail bo'lishidir. Code coverage esa o'z nomi bilan dasturning qancha qismi testlar bilan qoplanganini aniqlab beruvchi indikatordir.
E2E (end-to-end) testlar, code review va preview branch deploymentlar
himoyaning bu o'rta fronti kross-funksional (ya'ni bir necha jamoalarni qamrab oluvchi) amaliyotlardan tashkil topgan bo'lib odatda ancha ko'proq vaqt oladi. Agar e2e testlarni misol qilib oladigan bo'lsak, bu turdagi testlar frontend va backend jamoa a'zolariga dasturning eng muhim qismlarini (user flow) birgalikda tekshirish imkonini beradi. Code reviewlar esa 1-frontdan o'tib ketgan xatolarni ya'ni asosan dasturning mahtiqiy xatolari, taklif etilgan yechimdagi kamchiliklar, ularning dasturlashdagi ma'lum va mashxur tamoyillarga (DRY, SOLID, KISS, SOC, YAGNI va boshqa umumiy) amal qilingan yoki qilinmaganini aniqlashda, yoki taklif etilgan yechim feature requirement specsga qanchalik to'g'ri kelgan-kelmaganini aniqlashda o'rni beqiyosdir. Va oxirgisi bu har bir PR (Pull Request) uchun alohida preview deploymentlarga ega bo'lish (bunday deploymentlar takrorlanmas URLga ega bo'lishi bilan ajralib turadi). Har bir bunday deployment bu sizning frontend loyihangizning ma'lum bir o'zgarishlarga ega versiyasidir. Bunday deploymentlar nafaqat jamoa ichida code reviewni tezligini oshiradi balki bundan tashqari design va product teamlar siz tanishtirgan o'zgarishlarni (e.g. dasturga yangi qo'shilgan imkoniyatlar) qulay va tezda tasdiqlashini ham osonlashtiradi.
feature flag, accessibility auditlar/testlar, performance testlar va cross-browser testlar
bu esa himoyaning so'nggi fronti bo'lib asosan reliz va relizdan keyingi more-customer-facing amaliyotlardan tashkil topgan. Xususan, feature flaglar bu muayyan dastur imkoniyatini masofadan turib dasturni qayta deploy qilmasdan (ya'ni hech qanday koddagi o'zgarishsiz) o'chirib/yoqib qo'yish imkoniyati yoki biron yangi featureni foydalanuvchilarga ko'rsatmasdan turib deploy qila olishlik imkoniyatini beruvchi vositadir. fflar yordamida canary relizlar, kill switch, A/B testing va bir qancha boshqa ishlarni amalga oshirsa bo'ladi. Accessibility audit/testlar : bularni CI/CD pipelinimizni oxirgi qismi desak ham bo'ladi, lekin shunga qaramasdan eng muhim va eng qiyin bosqichlardan biri chunki odatda frontendimizni 100% accessible qilishni kafolatlash deyarli imkonsiz. Lekin shunga harakat qilinish kerak.

linting bu dastur kodini statik tahlil qilish jarayoni bo'lib, dasturdagi buglar ya'ni xatolar va koddagi stilistik nomutanosibliklarni topishda ishlatiladi.

e2e testlar bu sodda qilib aytganda dasturning butun jabhalarini, database, backend va frontendni qamrab oluvchi va eng qimmat va eng ko'p vaqt talab qiladigan testlar. Ayni paytda, bu turdagi teslarni dastur kodining haqiqatda muammolarsiz ishlayotganini eng to'g'ri ko'rsatib beruvchi indikator deb qarasak ham bo'ladi.

feature requirement specs bu dasturning muayyan featuresini nimaligi, qanday ishlashi va nima natija berishi kerakligi bildiruvchi texnik xujjat, sodda qilib aytsak dasturchilar/proyekt managerlar shunga qarab dasturga yangi imkoniyatlarni qo'shishadi. FRS ni SRS (Software requirements specification) ning kichikroq versiyasi desak ham bo'ladi.

Demak, CI/CD pipelinening har bir bosqichini ta'sir doirasining kengliga qarab shartli 3 guruhga bo'lib olsak bo'ladi:

faqat muayyan jamoa miqyosida
- unit/integration testlar (odatda code coverage bilan), linting, formatlash va type checkerlar
bir necha jamoalarni qamrab oluvchi (ya'ni kompaniya darajasida)
- e2e testlar, code review, preview deploymentlar va avtomatlashtirilgan relizlar
jamoa(lar)ni, kompaniyani va barcha foydalanuvchilarni qamrab oluvchi.
- feature flaglar, accessibility auditlar/testlar va performance testlar.

Kelgusu qismlarda bularning har biri bilan alohida-alohida va chuqurroq tanishib chiqamiz.

Maqsadimiz o'zbek tilida IT bilan bo'gliq sifatli contentni ko'paytirish va ularni hammaga qulay uslubda tarqatishdir. Bunda eng katta muammolarimizdan biri bu sohaga oid inglizcha atamalarni qanday qilib tushinarli tarzda, o'z ma'nosidan chiqib ketmagan holda qisqa va lo'nda shaklda yetkazishdir. Chunki to'g'ridan to'g'ri (direct) tarjima ko'p hollarda haddan tashqari uzun, tushunarsiz va o'zining dastlabki ma'nosidan chiqib ketgan shaklga kelib qolishidir. Shuning uchun sarbast (erkin) uslubni (postimizda boshida ham bu haqida biroz to'xtalgandik) sinab ko'rishga qaror qildik. Haligi aytishgandek: Best of both worlds :) !

JavaScript Evolutsiyasi Qisqa Satrlarda!

Humoyun Ahmad — Thu, 12 May 2022 08:25:00 +0000

Bismillah!

Taxminiy o'qish vaqti: ~9 daqiqa

Diskleymer: ba'zi atamalardan shundayligicha foydalanildi, tarjimasi ga'latiroq yoki notanish ko'rinmasligi uchun. Ba'zi iboralar esa ixchamroq ko'rinishga keltrildi, release -> reliz.

Assalam alaykum! Bugun siz bilan JavaScript (JS) rivojlanish tarixiga biroz nazar tashlaymiz. Hozirgi kunda eng zamonaviy va eng ko'p qo'llaniladigan tillardan hisoblangan JS oldin qanday edi va o'tgan yillar ichida qanchalik o'zgardi va kimlar o'zgartirdi. Bu maqolada JSni boshlanish tarixiga to'xtalib o'tirilmadi, agar bu haqida to'liq bilishni xohlasangiz quyidagi maqoladan o'qib olsangiz bo'ladi: version history of javascript

Ko'p yillar davomida (< 2015 gacha) JS rivojlanishi (tilga yangi imkoniyatlarni qo'shib borish) juda sekin va salmoqsiz edi. Aniqroq gapiradigan bo'lsak, ECMAScript (JS ni spesifikatsiyasiga ma'sul standard) tilni 3.1 versiyasida 2009 dan beri qotib qolgan edi 🔒. Solishtirish uchun ushbu havolaga qaralsin. Keyinchalik bu versiya biz ko'proq tanish bo'lgan ECMAScript 5 yoki ES5 nomi bilan almashtirildi. Keyingi katta relizgacha JS community ancha uzoq kutib qoldi, deyarli 6 yil. Xatto ATM mashinalar ham tezroq yangilanib turiladi.

Bu vaqt mobaynida esa TC39 deb nomlangan JSni stardartlashtirish guruhi bir qancha OpenJS Foundation kabi ochiq jamiyatlar yordamida ECMAScript 2015 yoki ES6 versiyasini ishlab chiqishdi va 2015 yilga kelibgina taqdim etishdi. Bu JS tarixidagi shu paytgacha kirtilgan eng katta va muhim yangilanish edi.

Bu relizda JSga kiritilgan yangi imkoniyatlarning eng asosiylari bilan quyida tanishib chiqamiz. To'liq ma'lumotni esa ushbu havoladan ko'rib olsangiz bo'ladi.

yangi Promise API ⌛
class sintaksisi
yagona modul tizimi 🌕
arrow funksiyalar 🔥
destrukturalash sintaksisi
meta programming 🔧
block scoped ozgaruvchilar
iterator va generatorlar 💪
template literal

Yangi Promise API

Promise obyekti muayyan asinxron operatsiya (serverga http so'rov) bilan ancha qulay tarzda ishlash imkonini beradi. Bu mexanizmdan oldin JSda asinxron kodlar callback lar yordamida amalga oshirilardi lekin noqulayliklari ko'p edi. Bunga yaqqol misol qilib callback hell 😩 keltirish mumkin. Buni quyidagi code-snippet da ko'rishingiz mumkin:

Demak Promiselar bizga quyidagilarni beradi:

Yanada ekspressiv asinxron kod yozish.
Yanada elegant error handling.

ekspressiv - qisqa satrlarda ko'p narsani namoyon eta olish.
elegant - nafis va yoqimli ko'rinish.

Qo'shimcha: ES7 async/await sintaksisi esa asinxron kodingni yanada qulaylashtirdi.

Class sintaksisi

Classlar JSning prototype mexanizmi ustiga qurilgan abstraksiyasidir. Javadagi classlar bilan adashtirilmasin chunki sintaktik bir xil ko'rinishda bo'lsada, ishlash mexamizmlari fundamental darajada bir biridan farqlidir. JSda haqiqiy Prototypal Inheritance (aslida Delegation) ni to'g'ri setup qilish biroz murakkabroq jarayon edi, classlar buni elegant holatga keltirdi.

// classlarsiz
function Person() {...}
Person.prototype.getName = function () {...}

function Student() {}
Student.prototype.getScores = function () {...}
Student.prototype = Object.create(Person.prototype);
Student.prototype.constructor = Student;

// classlar bilan
class Person {
  getName() {...}
}
class Student extends Person {
  getScores() {...}
}

Lekin bu degani classlar yaxshiroq degani emas. Uni o'ziga yarasha kamchililari bor. Bu haqida esa boshqa maqolada bafurja muhokama qilamiz. Shaxsan men uchun classlar JSda obyektlar bilan ishlashga turli tumanlikni olib kirdi va Javaga o'xshash kompilyatorlik tillardan kelgan dasturchilarga visual qulaylik berdi ya'ni syntactic sugar.

Yagona modul tizimi

Har qanday dasturiy ta'minotda dastur kodining yaxshi strukturaviy qismlarga ajratilgani, ham mantiqiy ham jismoniy, bu eng muhim masalalardan biridir. Bunga esa modullar orqali erishiladi. Afsuski, ES6 modul tizimidan oldingi modullash tizimlarida bir qator kamchiliklar mavjud edi, misol uchun server va client uchun universal modul tizimining yo'qligi. Dastlabki modul tizimlaridan farqli o'laroq, yangi ECMAScript Modules (ESM) tizimi statik bog'liqliklardan foydalanish uchun JS sintaksisini yaxshiladi, bu esa 4 ta muhim afzalliklarni berdi:

Dastur kodining statik tahlili, o'lik kodni yo'q qilish (dead-code elimination) va keraksiz kodlarni topish (tree-shaking) kabi bir qancha zamonaviy dasturlash vositalarini ishini ancha samaraliroq qilishga imkon yaratdi.
Server va client uchun modul tizimini birlashtirdi, bu esa platformaga qarab turli xil modul tizimlarini talab qilish muammosini chiroyli hal etdi. (e.g. CommonJS va AMD)
butun dastur bo'ylab kodni qayta-qayta ishlata olishlik imkoniyatini yaxshiladi ya'ni more elegant code sharing.
Kompilyatorlarning kodni tahlil qilish usulini optimallashtirdi.

Yashasin export/import yo'qolsin require/define! (bu albatta xazil edi)

Arrow funksiyalar

Bu yangi standartdan oldin, JSda funksiyalarni yaratish uchun function kalitso'zi ishlatilardi, endi esa funksiyalarni => maxsus arrow sintaksisi yordamida ekspressivroq tarzda e'lon qila olamiz. Arrow funksiyalar Pythondagi lambda funksiyalar kabidir va an'anaviy funksiyalardan bir qancha farqlari bor. Xususan, arrow funksiyalar an'anaviy funksiyalardagi this, arguments yoki super kabi mexanizmlarga ega emas . Bundan tashqari, call, apply va bind kabi scopelarni o'zgartira olishda ishlatiladigan vositalar bilan ishlatila olinmaydi.

// ES6 dan oldin 
function add(num1, num2) {
 return num1 + num2;
}

// ES6 dan keyin 
const addImplicit = (num1, num2) => num1 + num2;

Arrow funksiyalaridan foydalanishning eng katta qulayligi sifatida setTimeout() va EventTarget.addEventListener() kabi metodlar bilan oson ishlatilishini aytish mumkin, chunki ularda odatda funksiyaning tegishli scopeda bajarilishini taʼminlash uchun closure mexanizmini tadbiq qilinishi yoki bind va apply kabi metodlarni ishlatish talab etiladi.

Destrukturalash sintaksisi

Obyektni destrukturalash obyektning propertiylarini qulay tarzda ajratib olishga va ularni o'zgaruvchilarga osonroq o'zlashtirishga imkon yaratadi. Bu esa dastur kodidagi tartibsizliklarni (code clutter) kamaytirishda samarali rol o'ynab kodni yanada ixcham va o'qishli ko'rinishga keltiradi.
Ko'rib o'zingiz baho bering:

const state = {
 name: "Ahmad",
 age: 25,
 address: {
   zipCode: 7711,
   city: "Tashkent"
 }
}

const { name, address: { zipCode } } = state; // cool!
// solishtirish uchun
const zipCode = state.address.zipCode;
const name = state.address.zipCode;

Meta programming

Proxy obyekti sizga dasturni ishlash jarayonida (runtime) meta levelda muayyan operatsiyalarni intersept qila olish va o'ziga qulay shaklga keltira olish imkoniyatlarini taqdim etadi.

intersept qilish - dasturning biron operatsiyasini bajarilish jarayoni orasiga suqulib kirib unga ta'sir o'tkazish, zimdan kuzatish yoki o'zgartira olishlik. (dasturni ishlash jarayoni bu RAMda aktiv ishchi holatda bo'lishlik degani)
meta level - ya'ni runtime vaqtida dasturlash tilining fundamental mexamizmlari ishlashiga aralasha olish yoki o'zgartira olish

Proxylar muayyan turdagi muammolarni hal qilishda juda foydali mexanizm hisoblanadi. Cross cutting aspects bunga yaqqol misol bo'la oladi. Real misol sifatida esa Vue3 ning reaktiv tizimini keltirish mumkin, ular Proxylardan juda samarali foydalanishgan va oldingi versiyadagi hacky yechimni (Object.defineProperties()) Proxylar bilan almashtirishgan. Bu haqida boshqa maqolalarimizda batafsil to'xtalib o'tamiz.

Iterator va generatorlar

ES6 dagi menga eng yoqqan imkoniyatlardan biri

Bular tilning eng kam tilga olinadigan biroq eng ko'p ishlatiladigan imkoniyatlarini asosida yotuvchi mexanizmlardir (Promise, async/await, etc). JSchilar uchun katta imkoniyatlarni ochib beradi. Bular alohida e'tiborga loyiq mazvular bo'lgani uchun ular haqida ham alohida post yozish istagi bor. Hozircha esa quyidagi code-snippet lar bilan cheklanamiz:

// DOM traversal 
const parent = document.createElement("div");
parent.innerHTML = `
  <div id="subTree">  
    <form>    
      <input type="text"/>  
    </form>  
    <p>Paragraph</p>
    <span>Span</span>
  </div>
`;
const subTree = parent;

// recursive yechim
const traverseDOMRecursive = function (elem, cb) {
  cb(elem);
  elem = elem.firstElementChild;
  while (elem) {
    traverseDOMRecursive(elem, cb);
    elem = elem.nextElementSibling;
  }
};
function callback(element) {
  console.assert(element !== null, element.nodeName);
}
traverseDOMRecursive(subTree, callback);

// generatorlar bilan
const traverseDOMGenerator = function* (elem) {
  yield elem;
  elem = elem.firstElementChild;
  while (elem) {
    yield* traverseDOMGenerator(elem);
    elem = elem.nextElementSibling;
  }
};
// for loop ni ichida ishlatilishiga e'tibor bering
for (let element of traverseDOMGenerator(subTree)) {
  console.log("element", element.nodeName);
}

Endi esa iteratorlarga misol:

class Range {
  constructor(...args) {
    this.start = args.length <= 1 ? 0 : args[0];
    this.end = args.length <= 1 ? args[0] || 0 : args[1];
    this.step = args.length <= 2 ? 1 : args[2];
  }
  [Symbol.iterator]() {
    return this;
  }
  next() {
    if (this.end > this.start) {
      const result = { done: false, value: this.start };
      this.start = this.start + this.step;
      return result;
    } else return { done: true, value: undefined };
  }
}

function range(...args) {
  return new Range(...args);
}

// ajoyib emasmi!
console.log([...range(4)]);
console.log([...range(2, 5)]);
console.log([...range(1, 10, 3)]);

Block scoped o'zgaruvchilar

ES6 tilga yangi o'zgaruvchilarni olib kirdi va ular var ni o'rnini deyarli to'liq egalladi. ES6 gacha, JSda faqatgina funksional va global scopelar bor edi, let va const qo'shilishi tufayli JSda endi block scope ham mavjud. var bilan e'lon qilingan o'zgaruvchilarda locality mexanizmi yo'q edi shuning uchun odatda global scope da e'lon qilingan boshqa o'zgaruvchilar bilan to'qnashuv bo'lishini oldini olish qiyin edi. Block scope esa bu muammoni hal qildi.

locality - biron o'zgaruvchining dastur kodining faqat o'ziga tegishli qismidagina {} mavjud bo'la olishi.

let x = 5;

function blockExample() {
 let x = 2 // bu funksional scope
 if(x >= 3) {
   let x = 10; // bu block scope
   console.log(x, "if blokining ichida");
 } else {
   let x = 1;
   console.log(x, "else blokining ichida");
 }
 console.log(x, "funksiyani ichidagi");
}

blockExample();
console.log(x, "global x");

const o'z nomi bilan constanta ya'ni o'zgarmas qiymatni bildiradi va u bilan e'lon qilingan o'zgaruvchilarga yangi qiymat berishga urinilsa dastur xatolik qaytaradi.

Template literal

Stringlar bilan ishlash imkoniyatlarini yanada kengaytirdi. Qulay interpolyatsiya ${} sintaksini olib kirdi.

let name = "Ahmad";
const HOLIDAY = "Iyd al-Fitr"; 
// ES6 dan oldin: 
console.log(name + "ning sevimli bayrami bu " + HOLIDAY);
// ES6 dan keyin:
console.log(`${name}ning sevimli bayrami bu ${HOLIDAY}`);
// yoki
const multiLineString = `Cross-cutting concerns are parts 
of a program that rely on or must affect many other 
parts of the system`

Va hokazo!

Yana bir eng muhim yangilik bu: JS ni reliz sikli (tilga yangi imkoniyatlarni davomiy tarzda qo'shib borish davri) yillik ko'rinishga o'tkazildi.

Biroz TC39 haqida

Endi TC39 haqida bir-ikki luqma gap aytamiz. Bu ishchi guruh yetakchi web kompaniyalar a'zolaridan tashkil topgan bo'lib asosiy maqsadi ECMAScriptni rivojlantirib borishdan iborat, bu esa o'z navbatida JSni standartlashtirib borish degani. Bundan tashqari TC39 JSchilar keng ommasiga tilga o'zlarining takliflarini (proposal) berish imkoniyatini bajaruvchi platforma sifatida ham faoliyat yuritadi. Bu takliflar ochiq shaklda butun dunyodagi webchilar ommasiga qo'yiladi va muayyan vaqt davomida belgilangan struktura bo'yicha bir nechta bosqichlarda muhokama qilinadi. Quyida bu haqida biroz to'xtalamiz.

TC39 bosqichlari

Stage 0 (strawman): Bu norasmiy bosqich bo'lib, taklif har qanday erkin shaklda bo'lishi mumkin, demak hamma ishtirok eta oladi. Taklifingizni kirgazish uchun esa TC39ning a'zosi bo'lishingiz yoki ECMA Internationalga registratsiya qilishingiz talab etiladi. Registratsiyadan so'ng taklifingizni esdiscuss mailing listi orqali bildirishingiz yoki boshqa takliflarni kuzatib borishingiz mumkin.
Stage 1 (proposal): Strawman dan so'ng, biron TC39 a'zosi sizning taklifingiz keyingi bosqichga o'tish uchun qo'llab-quvvatlashi kerak. Bu a'zo berilgan taklif nima uchun foydali ekanligini tushuntirishi va u amalga oshirilganda qanday ishlashi va ko'rinishini tasvirlashi kerak 🐥.
Stage 2 (draft): Bu bosqichda taklifning to'liq spesifikatsiyasi ishlab chiqiladi va eksperimental hisoblanadi (do it at your own risk ☢️ ). Agar taklif bu bosqichga yetib kela olsa, odatda TC39 bu taklifni qachondir JSni spesifikatsiyasiga kiritilishini kutadi.
Stage 3 (candidate): Bu bosqichda berilgan taklif to'liq deb hisoblanadi va imzolanadi. Bu bosqichdan keyin taklifga o'zgartirishlar kiritish juda ham kam bo'lib, faqatgina juda kiritik muammolari topilsagina va ko'p muddatli foydalanishdan so'ngina amalga oshiriladi. Ushbu bosqichda taklifni qo'rqmasdan ishlatsangiz bo'ladi chunki ma'lum muddatdan so'ng, taklif xavfsiz tarzda so'nggi bosqichga o'tkaziladi.
Stage 4 (finished): Bu yakuniy bosqich hisoblanadi. Agar taklif bu bosqichgacha yetib kelsa uni endi bemalol formal tarzda ECMAScript standartining spesifikatsiyasiga qo'shildi desa bo'ladi 🏁.

Bunday sog'lom va dinamik usulda tilga yangi imkoniyatlarni kiritib borish juda ham muhim jarayon hisoblanadi. Buning natijasida JS bugungi dunyoning tez o'zgarib boruvchi va murakkab talablariga labbay deb javob bera oladi.
Quyida ushbu taklif (proposal) lardan ba'zilarini keltirib o'tamiz.

Private class fieldlari va nihoyat classlarda access modifierlarni (private,static) qo'llash imkonini beruvchi sintaksis.
Observablelar streamlarga asoslangan reaktiv dasturlash paradigmasini olib kiradi JSga. Shaxsan menga eng yoqqan takliflardan biri. Bu haqida ham alohida maqola yozish niyat bor. RxJS (Angular) bilan ishlab ko'rganlar bo'lsa buni nimaligini juda yaxshi tushunishadi, endi bu library emas balki native 🚀 !!!
Pipeline operatori UNIXdagi pipe utilitasiga o'xshash asosan funksional tillarga tegishli bo'lgan mexanizmni JS fuksiyalarida ishlatish imkonini beradi.
Yangi bind operatori Function.prototype.bind ni yanada elegant tarzda ishlatish imkonini beruvchi yangi sintaksis

Ushbu maqola Internetdan olingan ma'lumotlar yordamida tayyorlandi. Har qanday taklif va mulozalar bosh ustiga, ularni pastdagi sharhlar bo'limida qoldirishingiz mumkin. Maqsadimiz o'zbek tilida IT bilan bo'gliq sifatli contentni ko'paytirish va ularni hammaga qulay uslubda tarqatishdir. Bunda eng katta muammolarimizdan biri bu sohaga oid inglizcha atamalarni qanday qilib tushinarli tarzda, o'z ma'nosidan chiqib ketmagan holda qisqa va lo'nda shaklda yetkazishdir. Chunki to'g'ridan to'g'ri (direct) tarjima ko'p hollarda haddan tashqari uzun, tushunarsiz va o'zining dastlabki ma'nosidan chiqib ketgan shaklga kelib qolishidir. Shuning uchun sarbast (erkin) uslubni (postimizda boshida ham bu haqida biroz to'xtalgandik) sinab ko'rishga qaror qildik. Haligi aytishgandek: Best of both worlds :) !