JavaScript yoki TypeScript: Loyiha sifati va tezligi

Asosiy maʼlumotlar

JavaScript va TypeScript dasturchilari statik kodni tekshirib beruvchi vositalar tomonidan yuboriladigan ogohlantiruvchi xabarnomalar va tipografik xatoliklarning koʻpayib ketishiga yoʻl qoʻymasligi kerak. Ulardan mavjud baglarni bartaraf etishda tavsiya sifatida foydalanish mumkin.
Dasturchilarga kodda buzilish yoki ishdan chiqish holatlari yuz berganda foydali fidbek taqdim etadigan avtomatlashtirilgan testlarni ishlab chiqishga ruxsat berish lozim. Shu orqali dasturchilarni yomon holatlarning oldini olishga javobgar qilib qoʻyish kerak.
Yuqori kod sifati qoidalariga ega maxsus perimetrni belgilash va oʻrnatish orqali kodlar bazasining eski qismlari dizayni va kod sifatini bosqichma-bosqich yaxshilash mumkin.
Ishlab chiqarish jarayonidagi barcha bosqichlarni deploy qilib turing. Shuningdek, muqarrar (chetlab oʻtish imkonsiz boʻlgan) hodisalar yuz berganda dasturchilarni qoʻllab-quvvatlang. Har bir hodisadan keyin dasturchilarni muvafaqqiyatsizlik sababini yoritib berishga va ana shunday holatlar uchun uzoq muddatli yechimlar ishlab chiqishga undang.
"Dasturlash jarayonidagi muammoni aniqlash, yechim topish, rejalashtirish va tahlil qilish bosqichlarida mahsulot ishlab chiqaruvchi va dasturlovchi jamoalarning hamkorligiga erishish orqali yuqoridagiga oʻxshash kamchiliklarni bartaraf eting.

JavaScript (hattoki TypeScript yozuv tekshiruvi bilan) nomaʼlum xususiyatlarga egaligi va uslub yetishmasligi sababli baʼzan tanqidga uchraydi. Lekin JavaScript veb brauzerlar uchun kodlash tili sifatida ishlab chiqilganini biladigan odamlarga bu hol ajablanarli emas.

Shunga qaramay, u full stack veb tarmoqlarini ishlab chiqish tili sifatida tanlandi va platformalararo mobil ilovalar uchun ham ommabop variantga aylandi. Xoʻsh, JavaScript/TypeScript kod bazalari eskirishni boshladi va murakkablik darajasi oʻsib bordi, deylik. Bunday vaziyatda dasturchilar resurslar yoʻqotilishini minimallashtirish va ishdan qoniqish hissini taʼminlash uchun nima qila oladi?

Ushbu maqola JavaScript kodlarini yaratishdagi 10+ yillik va JavaScript/TypeScript loyihalarini saqlab qolishdagi 5+ yillik tajribalarimga asoslangan.

JavaScript/TypeScript kod bazalaridagi xavfli jihatlar va sifat qanday baholanadi?
Tiklash kerak boʻlgan qismlar muhimlik darajasiga koʻra qanday tartiblanadi?
JavaScript/TypeScript kod bazalari doimiy tarzda mukammal ishlashi uchun qanday usullardan foydalanish kerak?

Vorkbrenchni toza saqlang

Har bir ogohlantirish xabarnomasi, kiritishdagi xatolik yoki keyingi dasturlarni yuklashda qotib ishlaydigan test tizimi dasturchilarning vaqti, diqqati va energiyasini oʻgʻirlaydi.

Ayniqsa, kod xabarnomalari yomon boʻladi, xuddi hammasi atay qilingandek dasturchilar ham ularni eʼtiborsiz qoldirishga oʻrganib ketgan. Ular tez orada toʻplanib ketadi va kutilmagan xatolik yoki tizimda buzilishlar yuzaga kelgan paytda xabarnomalardagi tavsiyalardan foydalanishni qiyinlashtiradi.

Kiritishdagi xatoliklar bunga yaxshi misol boʻla oladi. Foydalanuvchilar “happy path” boʻylab harakat qilganda bu kabi xatolar baʼzan sezilmasligi mumkin, chunki dasturiy taʼminot kutilganidek ishlayotgan boʻladi. Biz esa @ts-ignoreʼdan foydalangan holda har qanday tasdiqlash yoki yozish orqali xabarnomalarni bekor qilishga berilib ketamiz. Lekin shu zaylda davom etilsa, kun kelib foydalanuvchi boshqa bir usulni tanlaydi va qaysidir bir dasturni ishga tushirish paytida yuzaga keladigan xatolikka uchraydi.

Xullas, dasturchilar oʻzlariga bir necha oy oldin qisqa amal (shortcut, masalan: Ctrl+Y) tanlagani sababli bugun tadqiq etish, nusxa yaratish va tuzatish ishlari olib borish shart boʻlgan yangi bir bag “sotib oladi”. Endilikda agar kodingiz ogohlantirishlar yoki bekor qilishlardan zararlangan boʻlsa, tuzatishga koʻp vaqt ketadi.

Agar mahsulotning database (maʼlumotlar bazasi)da “boʻsh joy yoʻq” xatoligi kelib chiqsa, bu ogohlantirish dasturchilarga holatning sababini aniqlashga yordam berishi mumkin.

Shunga oʻxshash ogohlantirish va kiritishdagi xatoliklar baglar va boshqa kutilmagan holatlar sababini aniqlash uchun tavsiyalar hisoblanadi. Qancha koʻp bekor qilsak (yoki override qilsak), dasturchilar ularni tadqiq qilishga shuncha koʻp vaqt sarflaydi. Ayniqsa, ancha vaqt avval yozib qoʻyilgan kodlarda tuzatish ishlari qiyin boʻladi.

Xoʻsh, biz nima qila olamiz?

Dasturchilar ishlab chiqish jarayonida yuqorida aytilgan ogohlantirish va xatolik xabarnomalariga imkon qadar tezroq eʼtibor qaratishi kerak. Qiyinchiliklarsiz. Iloji boʻlsa IDE (integratsiyalashgan rivojlanish operatsion tizimi)ni dasturga kiritish kerak.
Ogohlantirish va xatoliklarni bekor qilishni taqiqlash lozim. Ularni joyida bartaraf qilish kerak.
Signal ovozini yuqori qilib qoʻying. Agar jamoa bildirishnomalar yoki kiritishdagi xatoliklarga sabab boʻladigan biror qoidani keraksiz deb topsa, uni ham bekor qiling.
Agar kodning aniq bir qismidagi qandaydir qoidani bekor qilishga (@ts-ignore yoki boshqa belgi orqali) ishonchingiz komil boʻlsa, nega oʻchirganingiz sababini hujjatning izohlar qismiga yozib keting.
Ish jarayoni vaqtida dasturlash xatolarini (masalan, loyihangiz mantigʻida kutilmagan qiymatlar) toʻxtatish uchun “try-catch” bloklarini qoʻshmang. Ularni tashqi tizimlarda uchrashi mumkin boʻlgan nosozliklar (masalan, input/output kabi istisno holatlar, tekshirish va operatsion tizim muammolari)ni bartaraf etish uchun qoʻllang. Dasturlash xatoliklarini kodning statik tahlili va birlik testlardan foydalangan holda loyihani ishlab chiqish paytidayoq aniqlash kerak.
Ogohlantirishlar va kiritish xatoliklari mavjud kodni loyihaga kiritmang. Bu qoidani bekor qilish uchun doimiy integratsiyalovchi payplayn operatoridan foydalaning.

Tayp cheker loyihada rejalashtirilgan qaysidir qism tushib qolgani toʻgʻrisida xabarnoma yuborishi mumkin. Buni eʼtiborsiz qoldirish orqali esa keyinchalik tuzatishga bir necha oy sarflanadigan nomuvofiq maʼlumotning saqlanib qolishi xavfini qabul qilgan boʻlasiz.

Bu kabi holatlarni qanday instrumentlar yordamida bartaraf eta olamiz?

Ixtiyorimizda koʻplab statik kodni tahlil qiluvchi vositalar mavjud boʻlib, eng keng tarqalganlari quyidagilardir:

ESLint. Koddagi sintaksis xatolar va anti-patternʼlarni aniqlaydi.
Standart formatdagi fayllar yoki JSDoc annotatsiyalarida matn yozishdagi xatolarni aniqlash uchun TypeScript (qatʼiy qoidalar bilan yaratilgan) mavjud.
Yuqoridagilarga qoʻshimcha ravishda SonarCloud, SourceGraph, Codacy yoki shunga oʻxshash onlayn vosita xizmatlari ham bor. Ular umumiy kodlar bazasida bir nechta kod sifati koʻrsatkichlarining evolyutsiyasini kuzatishda qoʻl kelishi mumkin.

Ogohlantirishlar boshqa vositalardan ham kelishi mumkin: birini oʻrnatganingizda toʻliq ishlashi uchun yana boshqa birini talab qiluvchi tobe programmalar (masalan, npm, yarn) mavjud. Yoki JavaScript kodlarini yaratish va boshqarishda yordam beruvchi vosita – bundler (masalan, webpack), kod protsessorlari (babel, scss) va ijro etuvchi operatsion tuzilmalar (CI runner). Ularga befarq boʻlmang.

Agar ushbu tavsiyalar bilan yozayotgan kodingiz juda murakkablashib ketsa, unga qaytadan ishlov berish mumkin.

 "scripts": {
    "lint": "eslint .",
    "lint:fix": "eslint . --fix",
    "lint:errors": "eslint . --quiet",
    "lint:typescript": "tsc --noEmit --skipLibCheck",
    "lint:jsdoc-typing": "tsc --noEmit --allowJs `find ./ -name '*.js' -name '*.d.ts'`"
  },

Statik kod analizatorlari va npm skriptlari dasturchilarga muammoli kodlarni oson va tez aniqlashga yordam beradi.

Xoʻsh, bu qanday boʻladi?

Statik kodni tahlil qiluvchi instrumentlarni oʻrnatish va sozlash — birinchi qadam. Lekin buning oʻzi yetarli boʻlmaydi.

Muvaffaqiyatning uzoq davom etishi ishchi guruhning quyidagi harakatlarni amalga oshirishiga bogʻliq:

dasturlashda chidab boʻlmas darajada xatoliklari bor kodni oʻzgartirish. Shuningdek, foydalanuvchilarga qulay boʻlishi uchun dasturlash tizimidan loyihaning operatsion tizimiga olib oʻtish kerakligini bilish;
TypeScript qanday ishlashini yaxshi tushunish; (solishtiring, TypeScript: Qoʻllanma)
muntazam ravishda ogohlantirishlar va kiritish xatoliklari bilan shugʻullanish;
ushbu harakatlarda davomiy boʻlish.

Bu yerda foydasi tegishi mumkin boʻlgan bir qator taktikalar berilgan:

Ragʻbatlantirish maqsadida kod sifatini oshirishga qoʻshgan hissalari uchun dasturchilarni mukofotlang. Buning uchun dasturchilar kodlash tizimiga kiritgan har bir oʻzgarishni (masalan, SonarCloud yoki Codacy) kod sifati evolyutsiyasiga qanday taʼsir etishini kuzatadigan davomiy integratsiya payplayniga ulanadigan instrumentdan foydalaning.
Dasturchilardan biriga kod sifatini doimiy saqlash masʼuliyatini yuklang.
Boshqa dasturchiga esa bogʻlanishlar doimiy ravishda yangilanib turishini taʼminlash vazifasini bering. Bu orqali jamoa logik va xavfsiz tuzatishlardan foydalana olsin.

Nima uchun har bir vazifaga alohida bir odam tayinlanishi kerak?

Agar masʼuliyat maʼlum bir kishiga biriktirilmay, jamoa zimmasida qolsa, oʻsha vazifa boshqa muhimroq ishlarning “soyasida” bajarilmay qolib ketadi. Masalan, ogohlantirish xabarini bekor qilib, uni hal qilish kerak boʻlgan vaqtda loyihaga yangi “ficha” qoʻshish kabi.

Ishchilar doimiy ravishda motivatsiyaga toʻlib, ishga diqqat qilishi uchun ularning vazifalarini oʻzaro almashtirib turish kerak.

Loyihadagi eng muhim biznes logikalarni (munosib turdagi) testlar bilan qamrab oling.

Ayni paytda bizda kodlar bazasini tartibli saqlashga bir jamoa biriktirib qoʻyilgani sababli foydalanuvchilarimiz programmalashtirishda hech qanday nosozlikka duch kelmasligiga ishonchimiz komil.

Biznes logikadagi xatolarda-chi?

Misol uchun, yangi qoʻshilgan ficha boshqa birini ishdan chiqarsa nima boʻladi? Birinchi navbatda, dasturchilarning oʻzi ushbu ficha qanday ishlashi kerakligini tushunishmasa-chi? Va nihoyat, ana shu xatolik katta yoʻqotishlarga sabab boʻlsa-chi?

Dasturlashdagi xatoliklar kabi biznes logikadagi nosozliklar ham loyiha foydalanuvchilari tomonidan aniqlanishi mumkin, lekin biz ularni ertaroq bilishni afzal koʻramiz. Shuning uchun dasturiy taʼminotimizni avtomatlashtirilgan yoki manual testlar bilan tekshirib turish muhim ahamiyatga ega hisoblanadi.

Biznes nuqtai nazaridan testlar ikki xil vazifa bajaradi:

Funksional talablarga amal qilish: har bir fichani joriy etish u uchun ishlab chiqilgan ehtiyojlarni toʻldiradi.
Regressiyalarni aniqlash: kodga maʼlum bir oʻzgartirish kiritilgandan keyin barcha mavjud fichalar kutilganidek ishlashda davom etadi.

Aksariyat ahamiyatli biznes fichalar funksional testlar (“qabul qilish/aʼzo boʻlish” testlari) bilan, eng muhim texnik komponentlar esa komplekt yoki integratsion testlar bilan qamrab olinganiga ishonch hosil qiling. Bundan tashqari, ushbu testlardan biri ishdan chiqqanda uzluksiz integratsiya dasturchilarga amaliy fikr-mulohazalarni taqdim etishini kafolatlang.

Test oʻtkazishni boshqa shaxsga (masalan, loyiha egasi yoki sifatni nazorat qilish jamoasiga) topshirish baʼzi dasturchilar uchun yaxshidek tuyulishi mumkin. Aslida har bir yangi ficha ishlab chiqilganidan soʻng uni amalda qoʻllash, funksional talablarga mos kelishiga ishonch hosil qilish va uni bajarish uchun sinab koʻrilsa, mantiqiy boʻlar edi.

Lekin regressiyalarni aniqlashni boshqasiga yuklash yaxshi fikr emas, bunga bir qator sabablar mavjud:

Kodlarni birlashtirish va deploy qilish orasidagi kechikish uzayib ketishi mumkin.
Regressiyani aniqlash va uni bartaraf etish orasidagi uzilishlarning koʻpayib ketishi ehtimoli ortadi.
Ushbu funksional koʻlamning oʻsishi hisobiga regressiyalarni aniqlashga ketadigan vaqt ham cheksiz tarzda koʻpayadi. Agar ana shu testlar uchun masʼul shaxs ularni avtomatlashtirmagan boʻlsa, koʻplab testlar oʻtkazib yuborilishi mumkin. Shu tariqa aniqlanmay qolib ketgan regressiyalarning ortib borish xavfi qisqa vaqt mobaynida yuqori darajaga chiqadi.

Regressiyalar bilan turli vazifalar boʻyicha hamkorlik qilish talab qilinsa (masalan, loyiha egasi + dasturchilar), shugʻullanish qiyin va katta ehtimol bilan qimmatga tushadigan “boshogʻriq” boʻladi. Regressiya testlarini avtomatlashtirish koʻp vaqt tejaydi va dasturchilar ana shunday testlar yoza oladi. Buni inobatga olgan holda boshqa xodimlarni jalb qilmasdan ham regressiyalarni aniqlash masʼuliyatini zimmasiga olish dasturchilarning manfaatlariga mos keladi.

Bartaraf etilishi kerak boʻlgan regressiyalar keng qamrovli boʻlsa-chi, unda nima qila olamiz?

Bunday holatda eng muhimlaridan boshlash kerak. Oʻzingizdan “Loyihaning narxlar rezolyutsiyasida sodir boʻlishi mumkin boʻlgan eng yomon holat qaysi?” savolini soʻrashingiz mumkin.

Masalan, e-commerce veb-sayti quyidagicha javob beradi:

Loyihaga elektron toʻlov tizimi orqali buyurtma berish daqiqasiga ~1000$ foyda keltiradi.
Agar sotuvchilar CTO (Texnologiyalar boʻyicha bosh direktor)dan ularni maʼlumotlar bazasiga qoʻlda qoʻshishni soʻrasa, katalogga mahsulotni qoʻshish soatiga ~ 500$ turadi.
Agar buyurtmalar mijozlarni qoʻllab-quvvatlash guruhimiz tomonidan amaliy bajarilishi kerak boʻlsa, u holda bizga kuniga ~500$ ga tushadigan buyurtmani qaytarish uchun shtrix-kodni print qilish kerak boʻladi.

Yuqoridagi kabi eng muhim biznes keyslarni inobatga oladigan boʻlsak, ular uchun boshidan oxirigacha avtomatlashtirilgan testlarni yozishdan boshlash toʻgʻri qadam boʻladi.

Testlar qachon ishga tushirilishi kerak?

Kodlar har safar loyihada deploy qilinishidan avval yo yangilanadi (update), yo kod bazaga qoʻshib qoʻyiladi.

Har bir topshiriqni amalga oshirishda test oʻtkazish uchun git skriptlariga tayanish yetarli boʻlishi mumkin. Chunki u ishonchli ishlaydi va uning davomiyligi dasturchilarni testlarni kam miqdorda ishlab chiqishga undamaydi.

Git skriptlaridan foydalanasizmi yoki yoʻq, lekin har safar ishlab chiqarishga tayyor kod bosilganda testlar qayerdadir bajarilishiga ishonch hosil qiling. Masalan, iloji boʻlsa, doimiy integratsiya dasturiy taʼminotida.

Kod tekshiruvlari va avtomatik testlar har bir vazifa uchun uzluksiz integratsiya dasturiy taʼminotida ishga tushiriladi.

Qanday turdagi testlar yaratishimiz mumkin?

Samaradorlikni imkon qadar oshirish uchun quyidagi oʻzgaruvchilarga eʼtibor qaratish maqsadga muvofiqdir:

Testlar qamrab olgan funksional va texnik qamrovning oʻlchami.
Testlardan olinadigan fidbeklar uchun sarflanadigan vaqt.
Amalga oshmay qolgan testlarda maʼlum boʻlgan xatoliklarni tuzatishga ketadigan vaqt.

Xato testlar (yaʼni tasodifiy sabablarga koʻra muvaffaqiyatsizlikka uchragan testlar) sababli boy berilgan vaqt.

Agar jamoangizdagi xodimlarda avtomatik testlar, sinovdan oʻtkaziladigan kodlar yozish boʻyicha tajriba kam boʻlsa, ishni bir nechta end-to-end (E2E) testlardan boshlang. Keyin esa testni asta-sekinlik bilan kodning boshqa kichik birliklari uchun tatbiq eting. Bu orqali dasturchilaringizni tekshirishga oson boʻlgan kodlar yaratishga ragʻbatlantirgan boʻlasiz. Masalan, vazifalarni taqsimlab berish orqali biznes logikani sof funksiyalar sifatida yozishni toʻxtatasiz. Bunga erishishda bogʻliqlik inversiya tamoyiliga amal qiluvchi loyihalashtirish modelini qabul qilish yaxshi usul hisoblanadi (qarang: Hexagonal Architecture yoki Clean Architecture).

3-partiya APIʼlarini sinab koʻrishimiz (mock qilishimiz) kerakmi?

Odatda Facebook, Google va Twitter kabi kompaniyalar tomonidan taqdim etilgan APIʼlar boʻladi.

Avtomat testlar (ushbu maqolada tasvirlanganidek) 3-partiya emas, balki jamoalarning funksional doirasidagi regressiyalarni aniqlashga moʻljallangan. Shunga asoslanadigan boʻlsak, testlaringizda 3-partiya APIʼlarini qoʻllab koʻrishingiz ahamiyatli boʻlishi mumkin.

Shunga koʻra:

Mockʼlar har doim APIʼning hozirgi faoliyatiga yoki holatiga mos boʻlishi kerak. Bundan anglashiladiki, dasturchilar uzluksiz ravishda APIʼlardagi oʻzgarishlarni kuzatib borishi va mockʼlarni shunga mos tartibda yangilab turishi kerak boʻladi.
API kutilganidek harakat qilmasa, bu haqida ogohlantirish xabari olishni xohlashingiz tabiiy.

Kodingizdagi va 3-partiya APIʼlaridagi nosozliklarni aniqlash bir xil shaklda kechmaydi:

Har safar kodingiz almashganda dastur qamrovi (scope) test qilinishi kerak.
3-partiya dastur doirasi ularning kodlari oʻzgarganda doimo tekshirilishi kerak. Yaʼni siz har safar kod almashtirganingizda uchinchi tomonda test oʻtkazishingiz mantiqqa toʻgʻri kelmaydi.

Uchinchi tomon provayderlari kutilganidek ishlayotganini muntazam kuzatib borishni xohlaysiz. Biroq xatoliklarini aniqlashingiz shart emas. Aksincha, dasturchilar har safar kodga oʻzgartirish kiritganidan koʻra doimiy ravishda monitoring qilib turish maʼquldir.

Binobarin, ikkita maxsus payplayn ishlab chiqilgan:

Sizga tegishli CI payplayn kodlaringiz oʻzgarganda dastur qamrovingizni tekshiradi.
Alohida ajratilgan CI payplayn esa uchinchi tomonni kuzatadi.

Uzoq muddat eng foydali va mustahkam ishlaydigan testlar ishlab chiqish uchun F.I.R.S.T. tamoyillariga amal qilishni tavsiya etaman. Shu oʻrinda, dasturchilar mockʼlarni notoʻgʻri qoʻllamasliklariga ahamiyat bering.

Kod bazalarining yangi va modernizatsiya qilingan qismlarini oʻrnating.

Faraz qilaylik, bir necha yillar davomida ishlab chiqqan va rivojlantirgan kod bazangiz yillar oʻtishi barobarida uslub va sifat jihatdan oʻz darajasini yoʻqotadi. Eng yomoni, texnik qarz, testlar yetishmasligi yoki favqulodda yuz beradigan murakkabliklar toʻplanishi natijasida baʼzi qismlarini saqlab qolish qiyinlashadi.

Bunday vaziyatda, yuqorida eslatib oʻtilganidek, butun bir kod bazada kod sifati boʻyicha kutilmalarning yaxlit darajasini tatbiq etish murakkab boʻlishi mumkin. Va bu yaxshi holat.

Siz istamaydigan narsa — kutilmalarni umumiy miqdorga qadar kamaytirishdir. Buning oʻrniga, kod bazasini perimetrlarga boʻlish va ularning har biri uchun alohida moslashtirilgan kutilma belgilashingiz mumkin.

Masalan, bir dasturlovchi jamoa oʻzining e-commerce (elektron tijorat) veb-saytiga yangi ficha kiritmoqchi, deb oʻylaylik. Ular bu ficha kod bazaning qolgan qismlariga qaraganda mustahkamroq va uni saqlab qolish osonroq boʻlishini istaydi. Bunga erishish uchun statik kod analizator (masalan, ESLint va TypeScript)larini kod bazaning boshqa talablaridan koʻra qatʼiyroq qoidalar bilan moslashtiradi. Buning uchun ular ushbu ficha uchun maxsus yaratilgan katalogga xos bekor qilish buyruqlaridan (koʻproq qoidalardan foydalanishga imkon beradi) foydalanadi. Shu zaylda jamoa kod bazasining almashtirish qiyin boʻlgan qismini modernizatsiya qilishga shoshilmasdan yangi yaratilgan kod sifatini oshirish imkoniga ega boʻladi.

"rules": {
    "prettier/prettier": "error",
    "deprecation/deprecation": "warn"
  },
  "overrides": [
    {
      // Tolerate warnings on non critical issues from legacy JavaScript files
      "files": ["*.js"],
      "rules": {
        "prefer-const": "warn",
        "no-inner-declarations": ["warn", "functions"],
        "@typescript-eslint/ban-ts-comment": "warn",
        "@typescript-eslint/no-var-requires": "off"
      }
    },
    {
      // Enforce stricter rules on domain / business logic
      "files": ["app/domain/**/*.js", "app/domain/**/*.ts"],
      "extends": ["async", "async/node", "async/typescript"],
      "rules": {
        "prefer-const": "error",
        "no-async-promise-executor": "error",
        "no-await-in-loop": "error",
        "no-promise-executor-return": "error",
        "max-nested-callbacks": "error",
        "no-return-await": "error",
        "prefer-promise-reject-errors": "error",
        "node/handle-callback-err": "error",
        "node/no-callback-literal": "error",
        "node/no-sync": "error",
        "@typescript-eslint/await-thenable": "error",
        "@typescript-eslint/no-floating-promises": "error",
        "@typescript-eslint/no-misused-promises": "error",
        "@typescript-eslint/promise-function-async": "error"
      }
    }
  ]

Bekor qilish buyruqlariga koʻra, turlicha perimetrlar uchun har xil ESLint qoidalari mavjud.

Xuddi shunga oʻxshab, agar butun boshli kod bazangizni modernizatsiya qilmoqchi boʻlsangiz, uni asta-sekin amalga oshiring. Eng avval qatʼiy nizomlar jamlangan katalog tuzing. Keyin koddagi ogohlantirishlar va kiritishdagi xatoliklarni bartaraf etish bilan birga eskirgan kodni bosqichma-bosqich oʻsha katalogga oʻtkazing.

Qayerdan boshlash kerak?

Yaxshisi, funksional scopeʼning eski qismini bosqichma-bosqich yaxshiroq dizaynga koʻchirish kerak. Masalan, avtomatlashtirilgan testlarni yozish qiyin boʻlgan fichani tanlab, uni amalga oshirishni hexagonal architecture modeliga oʻtkazish kerak. Bu modelda biznes/domen logika kiruvchi buyruqlar (a.k.a. “API”) va yon taʼsirlardan (a.k.a. “SPI”) ajratilgan boʻladi. Oʻzingiz xohlagan avtomatik testlarni ishlab chiqish va yangi dasturni qatʼiyroq statik kod analizatori qoidalariga ega boʻlgan maxsus katalogga joylashtirish orqali ushbu migratsiyani boshqaring.

import { makeFeatures } = from './domain/features';
import { userCollection } from './infrastructure/mongodb/UserCollection';
import { ImageStorage } from './infrastructure/ImageStorage.js';


/** @type {import('./domain/api/Features').Features} Features*/
const features = makeFeatures({
  userRepository: userCollection,
  imageRepository: new ImageStorage(),
});


routes.post('/avatar', (request, response) => {
  features
    .setAvatar(request.session.userId, request.files[0])
    .then(
      () => response.json({ ok: true },
      (error) => response.json({ ok: false })
    );
});

SetAvatar fichasi bogʻlanish inversiyasi yordamida izolyatsiyada test qilinishi oson boʻlishi uchun qaytadan ishlab chiqilgan. Fichani boshqa tizimga qanday olib oʻtishni bilish uchun → playlist deletion.

Agar ushbu usulga amal qilmoqchi boʻlsangiz, bir qator tavsiyalar berib oʻtamiz:

Agar jamoangiz yangilanishi kerak boʻlgan fichalarni qayta loyihalash borasida tajribasiz boʻlsa, siz bu faoliyatni kichik va oson boʻlgan qismlaridan boshlang. Yoki boʻlmasa, kelgusi haftalar yoki oylarda ishlab chiqilishi zarur boʻlgan fichalarni tanlashingiz ham mumkin.
Kodlashni amalga oshirishdan avval dastur qamrovini, biznes faoliyatni va qoʻllab-quvvatlash yoʻllarini aniqlashtirib oling. Masalan, siz domen ekspertlari (cheklangan doirada) bilan event storming tashkillash orqali qayta loyihalashtirishni maqsad qilishingiz mumkin.
Migratsiya qilish doirasining joriy modelini koʻz oldingizga keltiring, masalan, ARKit, Dependency-Cruiser yoki shunga oʻxshash bogʻliqlikni tahlil qiluvchi analizatorlardan foydalaning. Shuningdek, maqsadli modelingizda qayta takrorlashni xohlamagan muammolaringizni roʻyxatini tuzib oling, shunda hadeb bir xil xatoliklarga duch kelmaysiz.
Ikkilansangiz, sequence diagram, state machine diagram va ADR kabi dasturiy taʼminotni loyihalashtiruvchi vositalardan foydalangan holda tegishli dizayn ustida hamkorlikda ishlang.

Har bir cheklangan kontekstni bir tizimdan boshqasiga koʻchirganingizdan keyin kodlar 100% aniqlikda va qatʼiy qoidalarga muvofiq tekshiriladigan bazaga ega boʻlasiz.

Har kuni deploy qilib turing, lekin bir xatoni ikki marta takrorlamang

Kamchiliklarni aniqlash uchun statik kod analizatorlaridan va regressiyalarni topish uchun avtomatik testlardan foydalanilsa-da, mijozlaringiz baʼzan loyihada kamchiliklarga uchraydi. Bundan qochib qutulishning iloji yoʻq. Biroq shu kabi holatlarni va jamoangizning ularni bartaraf etishga sarflaydigan vaqtini kamaytirishning yoʻli bor, albatta. Buning uchun:

Har kuni deploy qilib turing (shu orqali nosozlik ehtimoli past ekaniga ishonch hosil qilasiz);
Bir xil xatolikni ikkinchi marta takrorlamang.

Nima uchun har kuni deploy qilish kerak?

Oson javob: chunki DORA tadqiqot loyihasi samarali faoliyat olib borayotgan jamoalar har kuni yoki kuniga bir necha marotaba deploy qilishini aniqladi.

Amaliy javoblar:

Chunki deploy qilish dasturchilarga loyihada paydo boʻlayotgan yangi bagni kelib chiqish negizini topishni tezlashtirib beradi. Yaʼni deployment qanchalik tez-tez amalga oshirilsa, oxirgi va kelgusi deploymentlar oraligʻida nosozliklar miqdori kamayadi.
Chunki yuqoridagi sabablarga koʻra, keyingisi kutganingizdek ishlamasa, avvalgi versiyaga qaytish (avval qilingan tuzatishlar hisobiga) arzonroqqa tushadi.
Bu esa jamoangizni oʻz ishlarini kichikroq va xavfsizroq bosqichlarga boʻlishga ragʻbatlantiradi. DORA maʼlumotlariga koʻra, bu usul eng yaxshi natijalarga erishgan guruhlar qoʻllaydigan amaliyotdir.

Bir xatoni ikki marta takrorlamaslik borasida nima deya olasiz?

Loyihada kutilmagan nosozliklarning aniqlanishini tushunsa boʻladi. Bir tomondan, bu juda yaxshi holat deya olamiz.

Ana shunday favqulodda uchraydigan holatlar loyiha moliyasi va dasturlovchi jamoaga qimmatga tushsa (masalan, taʼminotda uzilish boʻlib, veb-saytingiz bir necha soat ishlamasa), dasturchilar keyingi safar bu kabi nosozliklar yuzaga kelmasligini oldini oladigan boʻladi.

Loyihadagi muammolar qanday aniqlanadi?

Muammolarni topishni bir necha usullari mavjud:

Ideal holat: dasturchi muammoni aniqlaydi va darhol bartaraf qiladi.
Standart holat: xodim xatolikni topadi va bu haqida dasturlovchi jamoaga xabar beradi.
Yomon holat: xatolik haqida dasturlovchi jamoaga mijozning oʻzi xabar qiladi.
Eng yomon holat: mijoz kamchilikka duch keladi, lekin bu haqida jamoaga xabar qilmaydi.

Qaysi holatda boʻlsa ham dasturchiga muammo nimada ekani, u aniq qanday holatda (masalan, xato xabar) namoyon boʻlishi, uni qanday qilib qayta ishlab chiqish (yaʼni environment + procedure), foydalanuvchining asosiy maqsadi va kutilmasi qandayligi haqida maʼlumot kerak boʻladi.

Lekin eng yomon holatlarda bunday maʼlumotlarni qanday topish mumkin? Ularni xatoliklarni kuzatib boruvchi (error monitoring) instrumentlar (masalan, Sentry) koʻrsatib beradi. Ularni loyihada ishlab chiqilayotgan mahsulotga joriy etsak, jarayondagi xatoliklarni aniqlaydi. Xatoliklar dasturchilar tomonidan bartaraf etilmaguncha instrumentlar ularni roʻyxat boʻyicha sintez qiluvchi tekshiruv vazifasini bajaradi. Bunga qoʻshimcha ravishda ushbu instrumentlar dasturchilar xatolikni qayta ishlab chiqishiga yordam berish uchun xatolik konteksti haqidagi maʼlumotlar (masalan, foydalanuvchi agenti, amaldagi dasturiy taʼminot versiyalari, operatsion tizim, aniq vaqt belgilari kabilar)ni yetkazib beradi.

Afsuski, xuddi statik kod analizatorlari kabi bu instrumentlar xatoliklarni tuzatmaydi. Shuning uchun ham xuddi ogohlantirishlar va kiritish xatoliklariga oʻxshab, har bir kamchilikka imkon qadar tezroq eʼtibor qaratilishiga ahamiyatli boʻling. Jamoa ularning qanchalik koʻp toʻplanib ketishiga yoʻl qoʻysa, bu kabi instrumentlarni ishlatish shunchalik samarasiz boʻladi.

Shuningdek, bu kabi monitoring vositalaridan foydalanganda shaxsiy yoki maxfiy maʼlumotlar tizimdan “sizib chiqmasligiga” ishonch hosil qiling.

Taktik jihatdan muvaffaqiyat qozonishning koʻplab usullari mavjud. Masalan, siz bir dasturchiga loyihadagi nosozliklarni bartaraf etishni asosiy vazifa etib belgilashingiz mumkin. Har bir dasturlovchi mustahkamroq kodlar yaratishiga ilhomlanishi uchun ularning vazifalari muntazam (masalan, har kuni) almashtirib turilishi kerak. Yoki yangi xatoliklar har kungi yigʻilishda koʻngilli dasturchilarga yuborilishi mumkin.

Qaytalanish xavfini qanday kamaytirsa boʻladi?

Vahimaga hojat yoʻq. Loyihada biror favqulodda vaziyat yuzaga kelsa, quyidagi ketma-ketlikka amal qiling:

Loyiha muvaffaqiyatsizligi sabablarini yoritishda yordam berishi uchun voqeadan avval, oʻsha vaqtda va keyin nimalar sodir boʻlganini yozib saqlab qoʻying. Eslatma: favqulodda holat yuzaga kelishidan avval maqbul monitoring va maʼlumotlar yigʻish tugallangan boʻlishi kerak.
Voqea tafsilotlari haqida ichki va tashqi tomon bilan fikr almashing.
Ishlab chiqarishni barqarorlashtiring. Masalan, ishlab turgan avvalgi versiyaga qayting.
Muammoni bartaraf qiladigan muqobil variantni ishlab chiqing va deploy qiling.
Asosiy sabablarni aniqlab, yechim toping va profilaktika choralarini koʻring.

Eng oxirgi variant bir xil xatoni ikkinchi marta takrorlamaslikka kalit boʻla oladi.

Shuningdek, bu koʻpincha eʼtibordan chetda qoladigan jarayon hisoblanadi. Chunki jamoada hech kim bu ishga oʻzini masʼul deb bilmaydi. Koʻp hollarda loyiha rahbari (yoki loyiha jamoasi) dasturchilarni mavjud kodni xavfsiz saqlash yoki kodlash jarayonini sozlashdan koʻra rejalashtirilgan fichalarni ishlab chiqishga koʻproq ahamiyat berishlari uchun bosim oʻtkazadi. Baʼzida esa dasturchilarning oʻzlari xatoliklar takrorlanishini oldini olish oʻrniga loyihaga koʻproq fichalar yuklashni afzal koʻradi.

Favqulodda yuz bergan nosozliklarning tub ildizini topish paytidagi qaydlar.

Nosozlikning tub sababini qanday aniqlash kerak?

Bunda “5WHYs” texnikasi qoʻl keladi. Masalan:

NEGA loyiha ishlashdan toʻxtadi? Chunki tizimda roʻyxatdan oʻtmagan foydalanuvchi B sahifaga kirdi.
NEGA ushbu foydalanuvchi B sahifaga kira oldi? Chunki asosiy sahifaga kiruvchi havola qoʻyilgan edi.
"
NEGA foydalanuvchi B sahifaga kirmoqchi boʻlayotganda login pageʼni koʻrmadi? Chunki sahifa ishga tushirilayotganda login holati bekend tomonidan maʼlum qilinmagan edi."
NEGA sahifa ishga tushirilayotgan paytda login holati maʼlum boʻlmadi? Chunki session management serveri sekin ishlaydi va holat maʼlum boʻlgunicha kutish veb-samaradorlik koʻrsatkichlarini ancha pasaytiradi.
NEGA session management serveri sekin ishlaydi? Chunki u yangilanmagan database (maʼlumotlar bazasi)dan foydalanadi.

Yuqorida berilgan misolda asosiy sabab sifatida butun veb-sayt session management serveridan foydalanilishi koʻrsatilgan. Yaʼni navigatsiyani oldindan bildirmaydigan qilib, ishlab chiqarishda baʼzan nosozliklarga olib keladigan eski serverdan foydalanilgan. Shunday qilib, agar dasturlovchi jamoa oʻsha eski serverni yangilamasa, ish jarayonida shunga oʻxshash holatlar yana takrorlanishi mumkin. Xoʻsh, jamoa oʻsha serverni hoziroq yangilashi shartmi? Ehtimol, shart emas. Ammo ular ushbu natijani koʻrsatadigan tuzatish rejasini ishlab chiqishi kerak.

Quyi darajali avariya holati bilan amalda qanday qilib kunlik deploymentʼlarni amalga oshirish mumkin?

Loyihada favqulodda nosozliklar (masalan, ish paytidagi xatoliklar, baglar, buzilish)ni iloji boricha tezroq aniqlash, ularni darhol bartaraf etish va bu kabi muammolarning kelgusida takrorlanishini oldini olish choralarini koʻrishni dasturchilardan birining zimmasiga yuklang.

Shunday qilib, ushbu dasturchi oʻz vazifasini yaxshi sharoitda bajarish uchun oʻzida kuch borligini his qiladi. Masalan, maqbul monitoring tashkillash va roʻyxatga olish orqali buzilish holatidan keyin foydali hisobot yozilishiga ishonch hosil qiladi va profilaktika choralarini koʻradi.

Ishonchlilik yuqori darajaga koʻtarilgach, deploymentʼlar chastotasi ham asta-sekin oshib boradi.

Frontend - ReactJS

Mohirdev platformasiga kiring. Frontend–ReactJS kursimizda JavaScript, TypeScript, ReactJSʼni oʻrganasiz va toza kod yozishni boshlaysiz. Bundan tashqari, kurs yakunida sizni ishga kirishga tayyorlaymiz. Kurs oʻqituvchisi – dunyoning eng sara 3% dasturchilari qatoriga kirgan xalqaro mutaxassis.

Loyihani dasturlovchi jamoani oʻz oʻrnida ragʻbatlantirib ham turing.

Ana shunda dasturchilar sifatli dasturiy taʼminot ishlab chiqish va kamchiliklarni imkon qadar tezroq aniqlash uchun “qurollanadi”. Ular ishlab chiqarish jarayonidan koʻra koʻproq loyihalash va uni tatbiq etish jarayonida muhimroqdir. Ular loyihadagi kamchiliklarni tezlik bilan aniqlaydi va tuzatadi. Shuningdek, bir xil xatolarni ikkinchi marta takrorlamaydi. Kod va dasturlash jarayoniga boʻlgan ishonch loyihani kundan-kunga yaxshilash imkonini beradi. Bulardan tashqari, ular ishlab chiqargan dasturiy taʼminotlarining funksional doirasiga kutilgan rivojlanishlarni amalga oshirish bilan bir qatorda, kod bazasining eng eskirgan qismlarining dizayni va sifatini bosqichma-bosqich yaxshilab boradi. Natijada kod bazalar sogʻlom, mustahkam va uzoq muddat saqlab turish oson boʻlgan holatda turadi.

Baxtga qarshi, oʻsha balansning yoʻqotilishi ham oson. Masalan, bunga quyidagi holatlar sabab boʻlishi mumkin:

Agar dasturchilar kodning dizayn standartlari yoki sifatini uzoq vaqt saqlab turishga boʻlgan motivatsiyasini yoʻqotsa;
Agar ayrim dasturchilar jamoaning sifat boʻyicha tartib-qoidalarini buzsa va bu sistematik tarzda qayta ishlash, asablar taranglashuvi va kechikishlarga sabab boʻlsa;
Agar dasturchilar uzoq vaqt davom etadigan texnik majburiyatlar evaziga loyihaga funksional talablari notoʻgʻri tushunilgani uchun kutilganidek natija bermaydigan fichalarni kiritishga shoshilsa;
Agar kimdir (menejer, loyiha rahbari yoki boshqalar) dasturchiga har hafta koʻproq fichalarni ishlab chiqishni yuklasa yoki tigʻiz dedlaynlar qoʻysa;
Agar dasturchilarni ragʻbatlantirish/mukofotlash kriteriyalari kodning mustahkamligi va uzoq muddatli sifati kabi oʻlchovlarga asoslanmasa. Masalan, bonuslar haftasiga nechta ficha ishlab chiqishiga asoslanib berilsa, yuqorida aytib oʻtilganidek, kodning sifat nazorati balansi izdan chiqish ehtimoli vujudga keladi.

Bu kabi holatlarni oldini olish va bartaraf etish mushkul boʻlishi mumkin, chunki buni qilish uchun rahbardan yaxshigina boshqaruv faoliyati va softskillar talab qilinadi.

Yana bir keng tarqalgan xatolik — dasturchilar ular uchun muhim boʻlgan, rejalashtirilgan va loyihalashtirilgan fichalarni ishlab chiqishi kerak qabilidagi yondashuvning shakllanishidir.

Bu hal qilinishi qiyin boʻlgan masala, chunki:

Bu dasturchilarni dasturiy taʼminotda qilishlari kerak boʻlgan har qanday oʻzgartirishlarni joriy qilish uchun aniq-tiniq koʻrsatma berilishini kutish holatiga solib qoʻyadi. Bu katta ehtimol bilan ana shu parametrlarni ishlab chiqishda masʼullar bilan ikki tomonlama hamkorlik qilish evaziga boʻladi. Ayniqsa, kun boʻyi yolgʻiz ishlashni yoqtiradigan dasturchilar uchun.
Bu narsa dasturchilarni shunday holatga solib qoʻyadiki, uning funksional yoʻl xaritasiga bevosita hissa qoʻshmaydigan ishlab chiqish harakatlariga sarflagan vaqti oʻzini oqlashi qiyin boʻlib qoladi. Bu harakatlarga bogʻlanishlarni yangilash, kod sifatini oshirish, yaxshiroq dizayn va kodlash texnikalari boʻyicha treninglar oʻtkazish kiradi.
Bu esa barqaror ishlab chiqish amaliyotiga sarmoya kiritishni kamaytiradigan koʻrsatkichlar (user story (mijoz hikoyasi)ni ishlab chiqishdagi tezlik)ga asoslanib dasturchilar faoliyatini kuzatishga qiziqishni oshirishi mumkin: bularga kod sifati, regressiyalarning oldini olish va xatolar ustidan boshqaruv kiradi.

Yuqorida sanab oʻtilgan xatoliklarni chetlab oʻtishingiz uchun bir qancha tavsiyalarni eʼtiboringizga havola etamiz:

Biznes muammolarga yechim ishlab chiqishda loyihalash jarayoniga hech boʻlmaganda bitta dasturchini jalb qiling. Bu esa topilgan muammoga yaxshi yechim tatbiq etishda ularning masʼuliyatini oshiradi. Baʼzan dasturchilar hozirda loyihalar qanday modellashtirilgani va tatbiq qilinayotganini tushunganliklari bois qoʻyilgan talablarni bajargan holda ishlab chiqish vaqtini tejashga imkon beradigan muqobil yechimlar taklif qilishi mumkin.
Loyihaviy va texnik vakillar funksional va texnikaviy mahsulotlarning ustuvorligi va rejalashtirilishini ochiqlik va xayrixohlik bilan muhokama qilishiga ishonch hosil qiling. Masalan, dasturchilar kod bazaning bir qismiga qaytadan ishlov berishi kerak. Ular bu keyingi fichalarni ishlab chiqishda qanday qulayliklar yaratishi va loyihaning kechikishi qanday xavf va xarajatlar keltirib chiqarishini tushuntirish orqali boshqalarni koʻndirishdan manfaatdor boʻladi. Ayni shu tavsiya loyiha menejerlariga ishlab chiqilishi kerak boʻlgan rivojlanish qadamlarini ustuvorlashtirish va rejalashtirish boʻyicha dasturlash guruhini ishontirish va harakatga jalb qilishda qoʻl keladi. Bu tavsiyalarga amal qilish fichalar ishlab chiqish va ularni tatbiq etishda ishtirok etadigan barcha ishchilarning ishonchini, hamkorligini va faolligini oshiradi.
Menejment boʻlimida esa “har hafta iloji boricha koʻproq fichalar yuklash”ga berilib ketilmasligiga ishonch hosil qiling. Dasturchilarning karyeraviy maqsadlarini jamoaning qisqa muddatli va uzoq muddatli kutilmalari bilan uygʻunlashtiruvchi muvaffaqiyat yoʻlini toping. Bundan asosiy maqsad — dasturchi faqatgina qisqa muddatli rivojlantirishlar ustida ishlashni haqli ravishda oqlay olishi mumkin boʻlgan vaziyatlarning oldini olishdir.
Va nihoyat, dasturchilar oʻzlarining hardskil va softskillarini uzluksiz rivojlantirib borishlarida kerak boʻlgan resurs va qoʻllanmalar bilan taʼminlanishiga eʼtibor bering. Ularga malaka oshirish va qoʻshimcha darslar taqdim eting. Ularni topshiriqlar ustida birgalikda, juft boʻlib yoki butun jamoa bir boʻlib ishlashga ragʻbatlantiring. Bundan tashqari, ularni boshqa xodimlar (dasturchi boʻlmagan) bilan, masalan, domen ekspertlar, loyiha rahbarlari, loyiha dizaynerlari, mijozlarni qoʻllab-quvvatlash jamoasi va foydalanuvchilar bilan yaxshi hamkorlik qilishga chaqiring.

Xulosa

JavaScript dasturlash tili va paketlarining oʻzgaruvchan ekotizimi, amaliyotlari kod bazalarini saqlashni qiyinlashtirishi mumkin. Dasturlash tezligi va kod sifatini yoʻqotishning oldini olish ishlarini, ushbu maqolada muhokama qilganimizdek, hammasini noldan boshlamasdan yoki yangi xususiyatlarni ishlab chiqishni toʻxtatmasdan turib ham amalga oshirsa boʻladi.

Ushbu tavsiyalarni TypeScript va JavaScriptʼda qanday qoʻllash boʻyicha koʻproq amaliy maslahatlar olish uchun men Yoni Goldbergning eng yaxshi amaliyotlar roʻyxatini koʻrib chiqishingizni soʻrayman. Ular Node.js (bekend) loyihalari uchun yozilgan, lekin koʻpchiligini frontend kod bazalar uchun ham qoʻllash mumkin.

Manba: How to Sustain Quality and Velocity in a JavaScript or TypeScript Project?

JavaScript va TypeScript dasturlash tili siz uchun qiziq boʻlsa, Mohirdev platformasiga kiring. Frontend–ReactJS kursimizda JavaScript, TypeScript, ReactJSʼni oʻrganasiz va toza kod yozishni boshlaysiz. Bundan tashqari, kurs yakunida sizni ishga kirishga tayyorlaymiz. Kurs oʻqituvchisi – dunyoning eng sara 3% dasturchilari qatoriga kirgan xalqaro mutaxassis.

JavaScript yoki TypeScript loyihalarda sifat va tezlikni qanday taʼminlash mumkin?