Boshlang'ich dasturchi sifatida qilgan xatolarim

Ularni aniqlashni o'rganing, ularni oldini olish uchun odat qiling

jscomplete.com/beginner-mistakes
Yangilanish: Ushbu maqola endi mening "Professional dasturchi" kitobimning bir qismi.
Ushbu tarkibning yangilangan versiyasini va boshqa dasturlarni maslahatlarini jscomplete.com/pro-programmer-da o'qing.

Avval bir narsani aniq aytsam. Agar siz yangi boshlovchi dasturchi bo'lsangiz, ushbu maqola sizni xatolaringiz haqida yomon his qilish uchun emas, balki sizni ular haqida xabardor qilish, ularning belgilarini ko'rishga o'rgatish va ularni oldini olish uchun sizni eslatish uchun emas.

Men ilgari bunday xatolarga yo'l qo'yganman va ularning har biridan saboq olganman. Men ularni oldini olishga yordam beradigan kodlash odatlarini shakllantirganimdan xursandman. Siz ham shunday qilishingiz kerak.

Bu xatolar bu erda biron bir tartibda taqdim etilmagan.

1) Kodni rejalashtirishsiz yozish

Umuman olganda, yuqori sifatli yozma tarkibni yaratish oson emas. Bu ehtiyotkorlik bilan o'ylashni va izlanishni talab qiladi. Yuqori sifatli dasturlar bundan mustasno emas.

Sifatli dasturlarni yozish - bu oqim bilan jarayon:
O'ylab ko'ring. Izlanishlar. Reja. Yozing. Tekshirish O'zgartiring.
Afsuski, buning uchun yaxshi qisqartma yo'q. Ushbu tadbirlarni har doim kerakli hajmda bajarish uchun odat qilish kerak.

Men boshlang'ich dasturchi sifatida qilgan eng katta xatolarim shu zahotiyoq ko'p o'ylamasdan va tadqiq qilmasdan kod yozishni boshlash edi. Bu kichik avtoulov dasturida ishlashi mumkin bo'lsa-da, katta dasturlarga salbiy va salbiy ta'sir qiladi.

Siz afsuslanishingiz mumkin bo'lgan biron bir narsani aytmasdan oldin o'ylashingiz kerak bo'lganidek, siz ham afsuslanishingiz mumkin bo'lgan narsani kodlashdan oldin o'ylashingiz kerak. Kodlash, shuningdek, fikrlaringizni etkazishning bir usuli.

G'azablanganingizda, gapirishdan oldin 10 gacha hisoblang. Agar juda g'azablansa, yuz.
- Tomas Jefferson.

Mana mening ushbu taklifning versiyasi:

Kodni ko'rib chiqayotganda, chiziqni o'zgartirishdan oldin 10 tagacha hisoblang. Agar kod sinovlarga ega bo'lmasa, yuzta.
- Samer Buna

Dasturlash, asosan, oldingi kodni o'qish, nima kerakligini va hozirgi tizimga qanday mos kelishini o'rganish va kichik, sinovli ulanishlar bilan funktsiyalarni yozishni rejalashtirishdan iborat. Kod satrlarining haqiqiy yozilishi, ehtimol, butun jarayonning atigi 10% ni tashkil qiladi.

Dasturlash haqida kod satrlari sifatida o'ylamang. Dasturlash - bu mantiqqa asoslangan ijodkorlik, uni tarbiyalash kerak.

2) Kod yozishdan oldin juda ko'p narsalarni rejalashtirish

Ha. Yozuv kodini kiritishdan oldin rejalashtirish yaxshi narsa, lekin agar siz juda ko'p narsalarni qilsangiz ham yaxshi narsalar sizga zarar etkazishi mumkin. Juda ko'p suv sizni zaharlashi mumkin.

Mukammal rejani qidirmang. Bu dasturlash dunyosida mavjud emas. Ishni boshlash uchun foydalanishingiz mumkin bo'lgan etarlicha etarlicha rejani izlang. Haqiqat shundaki, sizning rejangiz o'zgaradi, lekin bu sizning kodingizda yanada ravshanlikka olib keladigan qandaydir tuzilishga majbur qilishdir. Juda ko'p rejalashtirish shunchaki vaqtni behuda sarflashdir.

Men faqat kichik xususiyatlarni rejalashtirish haqida gapirayapman. Bir vaqtning o'zida barcha xususiyatlarni rejalashtirish shunchaki noqonuniy bo'lishi kerak! Bu biz sharshara yondashuvi deb ataymiz, bu tizimning chiziqli rejasi bo'lib, qadamlar birma-bir bajarilishi kerak. Bunday yondashuvni rejalashtirish qanchalik zarurligini tasavvur qilishingiz mumkin. Bu erda rejalashtirishning turi emas. Ko'pgina dasturiy loyihalar uchun palapartishlik usuli ishlamaydi. Har qanday murakkab narsani faqat haqiqatga tez moslashuv bilan amalga oshirish mumkin.

Dasturlarni yozish mas'uliyatli faoliyat bo'lishi kerak. Siz sharshara rejasida hech qachon o'ylamagan xususiyatlarni qo'shasiz. Siz sharshara rejasida hech qachon o'ylamagan sabablarga ko'ra xususiyatlarni o'chirasiz. Xatolarni tuzatish va o'zgarishlarga moslashish kerak. Siz chaqqon bo'lishingiz kerak.

Biroq, har doim keyingi bir nechta xususiyatlarni rejalashtiring. Buni juda ehtiyotkorlik bilan bajaring, chunki juda oz rejalashtirish va haddan tashqari rejalashtirish ikkalangiz ham sizning kodingiz sifatiga zarar etkazishi mumkin, va sizning kodingiz sifati siz xavf ostiga qo'yadigan narsa emas.

3) Kod sifatining ahamiyatini tushunmaslik

Agar siz yozayotgan kodning faqat bitta jihatiga e'tibor qarata olsangiz, uni o'qish qulay bo'lishi kerak. Noma'lum kod axlat. U hatto qayta ishlanmaydi.

Kod sifatining ahamiyatini hech qachon unutmang. Amaliyotni o'zaro bog'lash uchun kodlash usuliga qarang. Koder sifatida asosiy vazifangiz - siz ishlayotgan har qanday echimning amalga oshirilishini aniq etkazishdir.

Dasturlash to'g'risida mening eng yaxshi tirnoqlardan biri:

O'zingizning kodingizni saqlashni tugatgan odam, qaerda yashayotganingizni biladigan zo'ravon psixopat kabi doim kodlang.
- Jon Vuds

Ajoyib maslahat, Jon!

Kichik narsalar ham muhimdir. Misol uchun, agar siz bosh harfni kiritish va bosh harflarga mos kelmasa, kodni bekor qilish uchun litsenziyangizni yo'qotishingiz kerak.

bu
  BOSHQA muhim
dan ko'proq
         sen o'ylaysan

Yana bir oddiy narsa - uzun chiziqlardan foydalanish. 80 ta belgidan tashqari har qanday narsani o'qish juda qiyin. If-bayonot bloki yanada ko'rinarli bo'lishi uchun siz bir qatorda uzoq shartlarni qo'yishingiz mumkin. Buni qilma. Hech qachon 80 belgidan oshib ketmang.

Bu kabi oddiy muammolarni astarlash va formatlash vositalari bilan osongina echish mumkin. JavaScript-da bizda mukammal ishlaydigan ikkita ajoyib vosita mavjud: ESLint va Prettier. O'zingizga yaxshilik qiling va har doim ulardan foydalaning.

Kod sifati bilan bog'liq yana bir nechta xatolar:

- Funktsiyada yoki faylda ko'p satrlardan foydalanish. Siz har doim alohida kodni sinab ko'rish va boshqarish mumkin bo'lgan kichik qismlarga uzun kodni ajratishingiz kerak. Shaxsan men 10 tadan ortiq satrlarga ega bo'lgan har qanday funktsiya juda uzoq deb o'ylayman, ammo bu oddiy qoidadir.

- Ikkilamchi negativlardan foydalanish. Iltimos, bunday qilmang.

Ikkilamchi negativlardan foydalanish juda yomon emas

- Qisqa, umumiy yoki turga asoslangan o'zgaruvchi nomlardan foydalanish. O'zgaruvchilaringizga tavsiflovchi va noaniq nomlar bering.

Kompyuter fanida faqat ikkita qiyin narsa bor: keshni bekor qilish va narsalarni nomlash.
 
 - Fil Karlton

- Qattiq kodlovchi ibtidoiy torlar va raqamlar tavsifsiz. Agar sobit ibtidoiy satr yoki raqam qiymatiga bog'liq mantiqiy yozishni xohlasangiz, bu qiymatni doimiyga qo'ying va unga yaxshi nom bering.

const answerToLifeTheUniverseAndEveryothing = 42;

- Oddiy muammolarga ko'proq vaqt sarflamaslik uchun tezkor yorliqlar va echimlar yordamida. Muammolar atrofida raqsga tushmang. Voqelikka yuzma-yuz qarab turing.

- Uzunroq kod yaxshiroq deb o'ylaysiz. Qisqartirilgan kod aksariyat hollarda yaxshiroqdir. Agar kodni o'qishga imkon beradigan bo'lsa, faqat uzunroq versiyalarini yozing. Masalan, kodni qisqa tutish uchun aqlli bir qatorli va ichki o'rnatilgan iboralarni ishlatmang, lekin kerak bo'lganda kodni qasddan uzoqroq qilmang. Keraksiz kodni o'chirish har qanday dasturda qilishingiz mumkin bo'lgan eng yaxshi narsa.

Dastur taraqqiyotini kod satrlari bilan o'lchash samolyot qurilishi taraqqiyotini vazn bo'yicha o'lchashga o'xshaydi.
 
 - Bill Geyts

- shartli mantiqdan ortiqcha foydalanish. Shartli mantiqqa muhtoj deb o'ylagan narsalarning aksariyati ularsiz bajarilishi mumkin. Barcha alternativalarni ko'rib chiqing va faqat o'qishga asoslangan holda tanlang. O'lchashga qodir bo'lmasangiz, ishlash uchun optimallashtirmang. Tegishli: Yoda shartlari va shartlar ichidagi topshiriqlardan qoching.

4) Birinchi yechimni tanlash

Dasturlay boshlaganimda, biron bir muammoga duch kelganimda, men echimni topib, shu zahotiyoq u bilan shug'ullanishimni eslayman. Men birinchi aniqlangan echimning qiyinchiliklari va mumkin bo'lgan nosozliklari haqida o'ylashdan oldin darhol shoshilardim.

Birinchi echim jozibador bo'lishi mumkin bo'lsa-da, yaxshi echimlar odatda topilgan barcha echimlarni so'roq qilishni boshlaganingizdan so'ng aniqlanadi. Agar siz muammoning bir nechta echimi haqida o'ylay olmasangiz, bu sizning muammoni to'liq tushunmasligingizning belgisidir.

Professional dasturchi sifatida sizning vazifangiz muammoning echimini topish emas. Bu muammoning eng oddiy echimini topishdir. "Oddiy" deb aytamanki, echim to'g'ri ishlashi va etarli darajada bajarilishi kerak, ammo o'qish, tushunish va saqlash uchun etarli darajada sodda.

Dasturiy ta'minot dizaynini yaratishda ikkita usul mavjud. Bitta usul - bu shunchalik sodda qilishki, aniq kamchiliklar yo'q, boshqa yo'l - bu shunchalik murakkablashadiki, aniq kamchiliklar yo'q.
- C.A.R. Xoare

5) Chiqish emas

E'tirof etishdan ko'ra tez-tez qilgan yana bir xato - bu eng oddiy yondashuv bo'lmasligi mumkinligini aniqlaganimdan keyin ham birinchi echimga yopishib qolishdir. Bu, ehtimol, "qoldirmaslik" psixologiyasi bilan bog'liqdir. Aksariyat mashg'ulotlarda bu yaxshi fikrlash qobiliyati, ammo u dasturlash uchun qo'llanilmasligi kerak. Aslida, dasturlarni yozish haqida gap ketganda, to'g'ri aqliy qobiliyat erta va ko'pincha muvaffaqiyatsiz bo'ladi.

Biror yechimga shubha qila boshlagan daqiqada, uni tashlab yuborish va muammoni qayta o'ylab ko'rish kerak. Bu echimga qancha sarmoya kiritganingizdan qat'iy nazar, bu to'g'ri. GIT kabi manbalarni boshqarish vositalari sizga turli xil echimlarni sinab ko'rishga yordam beradi. Buni qo'llang.

Kodni kiritishda unga qancha kuch sarflanganingiz sabab bo'lmasligi kerak. Yomon kodni olib tashlash kerak.

6) Googling emas

Muammoni hal qilish uchun qimmatbaho vaqtimni behuda sarflagan paytlarim bor edi, qachonki uni birinchi marta o'rgangan bo'lsam.

Agar siz qon ketish texnologiyasidan foydalanmasangiz, biron bir muammoga duch kelsangiz, boshqa birovning shu muammoga duch kelishi va uni hal qilish imkoniyatini topish mumkin. O'zingizga biroz vaqt tejang va birinchi navbatda Google It.

Ba'zan Googling siz muammo deb o'ylagan narsa haqiqatan ham emasligini ochib beradi va nima qilishingiz kerak bo'lsa, uni hal qilmang, aksincha uni qabul qiling. Muammoni hal qilish uchun hamma narsani bilasiz deb o'ylamang. Google sizni ajablantiradi.

Biroq, Google uchun nimani xohlayotganingizga e'tibor bering. Yangilikning yana bir belgisi - bu boshqalarning kodini tushunmasdan nusxa ko'chirish va undan foydalanish. Ushbu kod sizning muammongizni to'g'ri hal qilishi mumkin bo'lsa ham, siz hech qachon to'liq tushunmaydigan biron bir kod satridan foydalanmasligingiz kerak.

Agar siz ijodiy koder bo'lishni xohlasangiz, hech qachon nima qilayotganingizni bilasiz deb o'ylamang.

Ijodkor sifatida yuzaga kelishi mumkin bo'lgan eng xavfli fikr bu nima qilayotganingizni bilasiz deb o'ylashdir.
- Bret Viktor

7) Enkapsülasyondan foydalanmaslik

Bu nuqta ob'ektga yo'naltirilgan paradigmani ishlatish bilan bog'liq emas. Kapsülasyon tushunchasidan foydalanish har doim foydalidir. Kapsülasyondan foydalanmaslik ko'pincha parvarish qilinadigan tizimlarga olib keladi.

Ilovada funktsiyalarni bajaradigan faqat bitta joy bo'lishi kerak. Odatda bu bitta ob'ekt uchun javobgar bo'ladi. Ushbu ob'ekt faqat dasturning boshqa ob'ektlaridan foydalanish uchun mutlaqo zarur bo'lgan narsalarni ochib berishi kerak. Bu maxfiylik haqida emas, balki dasturning turli qismlari orasidagi bog'liqlikni kamaytirish tushunchasi haqida. Ushbu qoidalarga rioya qilish sizga katta hajmdagi narsalarni buzishdan qo'rqmasdan sinflar, ob'ektlar va funktsiyalarning ichki qismida ishonchli o'zgarishlarni amalga oshirishga imkon beradi.

Mantiq va davlatning kontseptual birliklari o'zlarining darslarini olishlari kerak. Sinf bo'yicha, men reja shablonini nazarda tutyapman. Bu haqiqiy Class ob'ekti yoki Funktsiya ob'ekti bo'lishi mumkin. Siz shuningdek uni Modul yoki Paket sifatida aniqlashingiz mumkin.

Mantiqlar sinfida o'z-o'zidan berilgan vazifalar o'zlarining usullarini olishlari kerak. Usullar bitta narsani amalga oshirishi va buni yaxshi bajarishi kerak. Shunga o'xshash sinflar bir xil usul nomlaridan foydalanishlari kerak.

Yangi boshlovchi dasturchi sifatida men har doim kontseptual birlik uchun yangi sinfni boshlash instinktiga ega bo'lmadim va ko'pincha o'z-o'zim tarkibiga kiradigan narsalarni aniqlay olmadim. Agar siz "Util" sinfini ko'rsangiz, unda bir-biriga bog'liq bo'lmagan ko'p narsalar uchun axlatxona sifatida ishlatilgan - bu yangi kodning belgisidir. Agar siz oddiy o'zgarishni amalga oshirsangiz va keyin bu o'zgarish kaskadli ta'sirga ega ekanligini bilib olsangiz va boshqa joyda ko'p o'zgarishlar qilishingiz kerak bo'lsa, bu yangi kodning yana bir belgisidir.

Sinfga usul qo'shishdan yoki usulga ko'proq javobgarlikni qo'shishdan oldin, instinktlaringizni o'ylab ko'ring va savol bering. Bu erda sizga vaqt kerak. O'tkazib yubormang yoki keyinroq uni o'zgartirasiz deb o'ylamang. Buni birinchi marta to'g'ri bajaring.

Bu erda katta g'oya shundan iboratki, sizning kodingiz yuqori birlik va past ulanishga ega bo'lishni xohlaysiz, bu shunchaki istalgan atama bo'lib, tegishli kodni birga saqlashni (sinfda) va turli sinflar orasidagi bog'liqlikni kamaytirishni anglatadi.

8) Noma'lumlarni rejalashtirish

Ko'pincha siz yozayotgan echimdan tashqarida o'ylash vasvasasi paydo bo'ladi. Siz yozgan har bir kod satriga ega bo'lgan har qanday if boshingiz ichiga tushadi. Bu eng yangi holatlarni sinab ko'rish uchun juda yaxshi narsa, lekin potentsial ehtiyojlar uchun haydovchi sifatida foydalanish noto'g'ri.

Ushbu ikkita asosiy toifadan qaysi biriga tegishli bo'lganingizni aniqlab olishingiz kerak. Sizga bugun kerak bo'lmagan kodni yozmang. Noma'lum kelajak uchun reja tuzmang.

Agar kelajakda sizga kerak bo'lishi mumkin deb o'ylaganingiz uchun biron bir xususiyatni yozish shunchaki noto'g'ri. Buni qilma.

Amalga oshirayotgan echim uchun har doim sizga kerak bo'lgan minimal kodni yozing. Ishonch hosil qiling, lekin chekka xususiyatlarni qo'shmang.

O'sish uchun o'sish saraton hujayralarining mafkurasi.
- Edvard Abbey

9) To'g'ri ma'lumot tuzilmalaridan foydalanmaslik

Suhbatga tayyorgarlik ko'rayotganda, yangi boshlanuvchilar odatda algoritmlarga juda ko'p e'tibor berishadi. Yaxshi algoritmlarni aniqlash va kerak bo'lganda ularni ishlatish yaxshi, lekin ularni yodlash, ehtimol sizning dasturiy dahoingizga hech qachon tegishli bo'lmaydi.

Biroq, sizning tilingizda foydalanishingiz mumkin bo'lgan turli xil ma'lumotlar tuzilmalarining kuchli va zaif tomonlarini yodlab olish, shubhasiz, sizni yanada yaxshi rivojlantiradi.

Noto'g'ri ma'lumotlar strukturasidan foydalanish bu erda yangi kodni qichqiradigan katta va kuchli yoritilgan taxtali belgi.

Ushbu maqola ma'lumotlar tuzilmalari haqida sizga ma'lumot berish uchun mo'ljallanmagan, lekin bir nechta tezkor misollarni aytib o'tishga ijozat bering:

- Yozuvlarni boshqarish uchun xaritalar (ob'ektlar) o'rniga ro'yxatlardan (massivlardan) foydalanish

Ma'lumotlarning tuzilishidagi eng ko'p uchraydigan xato - bu yozuvlar ro'yxatini boshqarish uchun xaritalar o'rniga ro'yxatlardan foydalanish. Ha, ro'yxat yozuvlarini boshqarish uchun siz MAP-dan foydalanishingiz kerak.

E'tibor bering, men bu erda yozuvlar ro'yxati haqida gaplashmoqdaman, bu erda har bir yozuvda ushbu yozuvni qidirish uchun ishlatiladigan identifikator mavjud. Ro'yxatlarni skalyar qiymatlar uchun ishlatish yaxshi va ko'pincha tanlash yaxshidir, ayniqsa agar diqqat markazida bu qiymatlarni ro'yxatga kiritish bo'lsa.

JavaScript-da, eng keng tarqalgan ro'yxat tuzilmasi - bu massiv va eng keng tarqalgan xarita tuzilmasi - bu ob'ekt (zamonaviy JavaScript-da xarita tuzilishi ham mavjud).

Yozuvlarni boshqarish uchun xaritalar orqali ro'yxatlarni ishlatish ko'pincha noto'g'ri. Garchi bu nuqta haqiqatan ham katta to'plamlarga tegishli bo'lsa-da, men har doim unga rioya qilaman, deyman. Buning muhim sababi shundaki, chunki identifikatorlardan foydalanib yozuvlarni qidirishda xaritalar ro'yxatlarga qaraganda ancha tezroq bo'ladi.

- Steklardan foydalanmaslik

Rekursionning biron bir shaklini talab qiladigan har qanday kodni yozishda har doim oddiy rekursiv funktsiyalardan foydalanish istagi paydo bo'ladi. Ammo, ayniqsa, bitta tishli muhitda rekursiv kodni optimallashtirish qiyin.

Rekursiv kodni optimallashtirish qaysi rekursiv funktsiyalarning qaytishiga bog'liq. Masalan, ikki yoki undan ortiq qo'ng'iroqlarni o'ziga qaytaradigan rekursiv funktsiyani optimallashtirish, bitta qo'ng'iroqni o'ziga qaytaradigan rekursiv funktsiyani optimallashtirishga qaraganda ancha qiyin.

Biz yangi boshlanuvchilar sifatida e'tibordan chetda qoldiradigan narsa shundaki, rekursiv funktsiyalardan foydalanishga alternativa mavjud. Siz shunchaki Stack tuzilishini ishlatishingiz mumkin. "O'zingizni to'plash" funksiyasiga qo'ng'iroq qiling va siz qo'ng'iroqlarni qaytarishga tayyor bo'lganingizda ularni chiqarishni boshlang.

10) Mavjud kodni yomonroq qilish

Tasavvur qiling, sizga shunday tartibsiz xonani berishdi:

Keyin sizdan xonaga buyum qo'shish so'raldi. Bu allaqachon katta tartibsizlik bo'lganligi sababli, siz uni biron bir joyga qo'yishingiz mumkin. Siz vazifangizni bir necha soniya ichida bajarishingiz mumkin.

Buni notinch kod bilan qilmang. Buni yomonlashtirmang! Kodni har doim u bilan ishlay boshlaganingizdan ko'ra ozroq toza holda qoldiring.

Yuqoridagi xonaga to'g'ri keladigan narsa yangi narsalarni kerakli joyga joylashtirish uchun kerak bo'lgan narsalarni tozalashdir. Masalan, agar kiyim shkafga joylashtirilishi kerak bo'lgan kiyim-kechak bo'lsa, siz o'sha shkafga boradigan yo'lni tozalashingiz kerak. Bu sizning vazifangizni to'g'ri bajarishning bir qismi.

Kodni odatdagidan kattaroq tartibsizlikka aylantiradigan bir nechta noto'g'ri ishlar: (to'liq ro'yxat emas):

  • Kodni nusxalash. Agar shunchaki shundan keyin satrni o'zgartirish uchun kod bo'limidan nusxa ko'chirsangiz / qo'ysangiz, siz shunchaki kodni ko'paytirasiz va katta xatoga yo'l qo'yasiz. Yuqoridagi tartibsiz xona misolida, bu balandligi sozlanadigan yangi stulga mablag 'qo'yish o'rniga, pastki bazasi bo'lgan boshqa stulni kiritish kabi bo'ladi. Har doim abstraksiya tushunchasini yodingizda saqlang va iloji bo'lsa, undan foydalaning.
  • Konfiguratsiya fayllaridan foydalanilmayapti. Agar siz turli muhitlarda yoki har xil vaqtda turli xil bo'lishi mumkin bo'lgan qiymatdan foydalanishingiz kerak bo'lsa, u qiymat konfiguratsiya fayliga tegishli. Agar kodingizni bir nechta joyida qiymatdan foydalanishingiz kerak bo'lsa, u qiymat konfiguratsiya fayliga tegishli. Kodni yangi qiymatini kiritishda doimo o'zingizga ushbu savolni bering: bu qiymat konfiguratsiya fayliga tegishli bo'ladimi? Javob, ehtimol, ha bo'ladi.
  • Keraksiz shartli gaplar va vaqtinchalik o'zgaruvchilardan foydalanish. Har bir if-ifoda kamida mantiqiy sinovdan o'tishi kerak bo'lgan mantiqiy tarmoqdir. O'qish qobiliyatini yo'qotmasdan shartli shartlardan qochishingiz mumkin bo'lsa, kerak. Buning asosiy muammosi boshqa funktsiyani kiritish o'rniga filial mantig'i bilan funktsiyani kengaytirishdir. Har safar sizga if-ifo yoki yangi funktsiya o'zgaruvchisi kerak deb o'ylaganingizda, o'zingizdan so'rab ko'ring: men kodni kerakli darajada o'zgartiryapmanmi yoki muammo haqida yuqoriroq darajada o'ylab ko'rishim kerakmi?

Keraksiz if-bayonotlar mavzusida ushbu kod haqida o'ylang:

funktsiya isOdd (number) {
  if (% 2 === 1 soni) {
    haqiqiy qaytish;
  } else {
    return false;
  }
}

Yuqoridagi isOdd funktsiyasi bir nechta muammolarga ega, ammo eng aniqini ko'rayapsizmi?

U keraksiz if-bayonotdan foydalanadi. Mana ekvivalent kod:

funktsiya isOdd (number) {
  qaytish (% 2 === 1 raqami);
};

11) Aniq narsalar haqida sharhlar yozish

Imkoniyat bo'lsa sharhlar yozmaslik uchun qiyin usulni o'rgandim. Ko'pgina sharhlar sizning kodingizdagi yaxshi nomlangan elementlar bilan almashtirilishi mumkin.

Masalan, quyidagi kod o'rniga:

// Ushbu funktsiya massivda faqat toq sonlarni yig'adi
const sum = (val) => {
  val.reduce qaytish ((a, b) => {
    if (b% 2 === 1) {// Agar joriy raqam g'alati bo'lsa
      a + = b; // Joriy raqamni akkumulyatorga qo'shing
    }
    qaytish a; // Akkumulyator
  }, 0);
};

Xuddi shu kodni sharhlarsiz yozish mumkin:

const sumOddValues ​​= (qator) => {
  return array.reduce ((akkumulyator, currentNumber) => {
    if (isOdd (currentNumber)) {
      qaytish akkumulyatori + currentNumber;
    }
    qaytish akkumulyatori;
  }, 0);
};

Vazifalar va dalillar uchun shunchaki yaxshi nomlardan foydalanish shunchaki ko'p sharhlarni keraksiz qiladi. Har qanday sharh yozishdan oldin buni yodda saqlang.

Biroq, ba'zida siz kodga qo'shishingiz mumkin bo'lgan yagona aniqlik sharhlar orqali amalga oshiriladigan vaziyatlarga tushasiz. Aynan shu vaqtda ushbu kod nima uchun amalga oshirilayotganiga emas, NEGA ushbu kod savoliga javob berish uchun sharhlaringizni tuzishingiz kerak.

Agar siz kodni aniqlashtirish uchun WHAT izohini yozishga shoshilmoqchi bo'lsangiz, iltimos, shunchaki aniq ishora qilmang. Kodga shovqin qo'shadigan ba'zi foydasiz sharhlarning namunasi:

// o'zgaruvchini yarating va uni 0 ga boshlang
ruxsat etilgan summa = 0;
// Massiv ustidan pastadir
qator.forEach (
  // Massivdagi har bir raqam uchun
  (raqam) => {
    // Joriy raqamni summa o'zgaruvchisiga qo'shing
    sum + = raqam;
  }
);

Bu dasturchi bo'lmang. Bu kodni qabul qilmang. Agar ular bilan muomala qilish kerak bo'lsa, ushbu kabi sharhlarni olib tashlang. Eng muhimi, bu kabi yomon sharhlar yozadigan dasturchilarni tarbiyalash. Agar siz yuqoridagi kabi sharhlar yozadigan dasturchilarni ish bilan ta'minlayotgan bo'lsangiz, ularga bu haqda ishdan bo'shatishlari mumkinligini xabar bering. Ha ... qanchalik yomon bo'lsa.

12) Yozma testlar

Men bu fikrni sodda tutmoqchiman. Agar siz o'zingizni tajribali dasturchi deb hisoblasangiz va bu fikrlash sizga kodni testsiz yozishga ishonch bag'ishlasa, siz mening kitobimdagi yangiliksiz.

Agar siz testlarni kod orqali yozmasangiz, ehtimol sizning dasturingizni boshqa usulda qo'lda sinab ko'rishingiz mumkin. Agar siz veb-ilovani yaratayotgan bo'lsangiz, kodning har bir satridan keyin siz tetiklashtirasiz va dastur bilan aloqada bo'lasiz. Men ham buni qilaman. Kodni qo'lda sinashda hech qanday muammo yo'q. Biroq, avtomatik ravishda sinovdan o'tkazish usulini aniqlash uchun kodni qo'lda sinab ko'rish kerak. Agar siz o'zingizning dasturingiz bilan o'zaro aloqani muvaffaqiyatli sinab ko'rsangiz, kod muharririga qaytib, keyingi safar loyihaga qo'shimcha kod kiritganingizda, xuddi shu o'zaro ta'sirni avtomatik ravishda bajarish uchun kodni yozishingiz kerak.

Siz odamsiz. Har bir kod o'zgargandan keyin siz oldin barcha muvaffaqiyatli tasdiqlashni sinab ko'rishni unutasiz. Kompyuterni buni o'zingiz uchun qiling!

Iloji bo'lsa, tasdiqlash yoki kodni loyihalashdan, ularni qondirish uchun kodni yozishdan oldin boshlang. Sinov asosida ishlab chiqish (TDD) bu shunchaki farasingiz emas. Bu sizning xususiyatlaringiz haqida fikr yuritishingizga va ular uchun yaxshiroq dizaynni qanday topishga ijobiy ta'sir qiladi.

TDD hamma uchun emas va har bir loyiha uchun yaxshi ishlamaydi, lekin agar siz uni (hatto qisman) ham ishlata olsangiz, buni mutlaqo qilishingiz kerak.

13) Agar narsalar ishlayapti deb faraz qilsak, unda ishlar to'g'ri

SumOddValues ​​xususiyatini amalga oshiradigan ushbu funktsiyani ko'rib chiqing. Nimadir yomonmi?

const sumOddValues ​​= (qator) => {
  return array.reduce ((akkumulyator, currentNumber) => {
    if (currentNumber% 2 === 1) {
      qaytish akkumulyatori + currentNumber;
    }
    qaytish akkumulyatori;
  });
};
 
 
konsol.assert (
  sumOddValues ​​([1, 2, 3, 4, 5]) === 9
);

Tasdiq o'tadi. Hayot go'zal. To'g'ri, O'ng

Yuqoridagi kod bilan bog'liq muammo shundaki, u to'liq emas. U bir nechta ishlarni to'g'ri hal qiladi (va tasdiqlash ushbu holatlardan biri bo'ladi), ammo bundan tashqari ko'plab muammolar mavjud. Meni ulardan bir nechtasini o'tishga ijozat bering:

- №1 muammo: Bo'sh kirish uchun ishlov berish yo'q. Funktsiya biron bir dalilsiz chaqirilganda nima bo'lishi kerak? Ayni paytda, bu sodir bo'lganda funktsiyaning bajarilishini aniqlaydigan xato paydo bo'ladi:

TypeError: "Belgilanmagan" xususiyatini o'qib bo'lmadi.

Odatda bu ikkita asosiy sababga ko'ra yomon kodning belgisidir.

  • Sizning funktsiyangiz foydalanuvchilari bu haqda amalga oshirish tafsilotlariga duch kelmasliklari kerak.
  • Xato foydalanuvchi uchun foydali emas. Sizning vazifangiz shunchaki ular uchun ishlamadi. Ammo, agar xato foydalanish muammosi haqida aniqroq bo'lsa, ular funktsiyani noto'g'ri ishlatganliklarini bilishadi. Masalan, foydalanuvchi tomonidan aniqlanadigan istisnoni quyidagicha tashlash funktsiyasini tanlashingiz mumkin:
TypeError: Bo'sh ro'yxat uchun funktsiyani bajarib bo'lmadi.

Balki xato qilishning o'rniga bo'sh funktsiyani e'tiborsiz qoldirish va 0 miqdorini qaytarish uchun o'z funktsiyangizni loyihalashingiz kerak bo'ladi.

- №2 muammo: noto'g'ri kiritilgan ma'lumotlarga ishlov berish yo'q. Agar funktsiya qator bilan emas, butun son yoki ob'ekt qiymati bilan chaqirilsa nima bo'lishi kerak?

Endi funktsiya endi otadigan narsasi:

sumOddValues ​​(42);
TypeError: array.reduce bu funktsiya emas

Yaxshisi, bu omadsiz, chunki array.reduce albatta vazifa!

Funktsiya argument massivini nomlaganimiz sababli, siz funktsiyani chaqirgan har qanday narsa (yuqoridagi misolda 42) funktsiya ichida massiv sifatida belgilanadi. Xato asosan 42.reduce funktsiyasi emasligini aytadi.

Siz bu xatoning qanday chalkashligini ko'rasiz, to'g'rimi? Ehtimol ko'proq foydali xato bo'lgan bo'lishi mumkin:

TypeError: 42 bu massiv emas, do'stim.

№1 va 2-sonli muammolar ba'zan "eng katta holatlar" deb nomlanadi. Bular rejalashtirish uchun ba'zi bir keng tarqalgan holatlar, ammo ular haqida kamroq o'ylashingiz kerak bo'lgan kam aniq holatlar mavjud. Masalan, salbiy raqamlardan foydalansak nima bo'ladi?

sumOddValues ​​([1, 2, 3, 4, 5, -13]) // => baribir 9

Xo'sh, -13 - bu g'alati raqam. Ushbu funktsiyani siz xohlagan xatti-harakatlarmi? Xato qilish kerakmi? U manfiy sonlarni yig'indisiga qo'shishi kerakmi? Yoki shunchaki hozirgi kabi salbiy raqamlarni e'tiborsiz qoldirishi kerakmi? Ehtimol, siz funktsiyani sumPositiveOddNumbers deb nomlash kerakligini tushunasiz.

Ushbu masala bo'yicha qaror qabul qilish juda oson. Eng muhimi shundaki, agar siz o'zingizning qaroringizni hujjatlashtirish uchun test yozmasangiz, salbiy raqamlarni e'tiborsiz qoldirgan bo'lsangiz, sizning funktsiyangizni kelajakda qo'llab-quvvatlovchilar hech qanday ma'lumotga ega bo'lmaydi.

Bu xato emas. Bu o'ziga xos xususiyat.
- Sinovni unutgan kimdir

- Muammo # 3: Hamma ham yaroqli holatlar tekshirilmaydi. Masofaviy ishlarni unuting, bu funktsiya qonuniy va juda oddiy holatga ega, u to'g'ri ishlamaydi:

sumOddValues ​​([2, 1, 3, 4, 5]) // => 11

Yuqoridagi 2 bo'lmasligi kerak bo'lgan summaga kiritildi.

Yechish oddiy, qisqartirish akkumulyator uchun boshlang'ich qiymat sifatida ishlatilishi kerak bo'lgan ikkinchi dalilni qabul qiladi. Agar ushbu dalil taqdim etilmasa (yuqoridagi kod kabi), qisqartirish akkumulyator uchun boshlang'ich qiymati sifatida to'plamdagi birinchi qiymatdan foydalanadi. Shuning uchun yuqoridagi sinov holatidagi birinchi juft qiymat yig'indiga kiritildi.

Agar siz ushbu muammoni darhol payqagan bo'lsangiz yoki kod yozilgan bo'lsa, uni ochib bergan ushbu test holati avval sinovlarga qo'shilishi kerak edi va boshqa ko'plab test holatlari singari juft raqamlar ro'yxati. unda 0 mavjud va bo'sh ro'yxat.

Agar siz ko'p holatlarga ishlov bermaydigan yoki eng kichik ishlarni e'tiborsiz qoldiradigan minimal sinovlarni ko'rsangiz, bu yangi kodning yana bir belgisidir.

14) Mavjud kodni so'roq qilmaslik

Agar siz har doim yakka o'zi ishlaydigan super koder bo'lmasangiz, hayotingizda biron bir ahmoqona kodga duch kelishingizga shubha yo'q. Yangi boshlanuvchilar buni tan olmaydilar va odatda u yaxshi kod deb o'ylashadi, chunki u ishlayotganga o'xshaydi va uzoq vaqtdan beri kod bazasining bir qismi bo'lib kelgan.

Eng yomoni shundaki, agar yomon kod yomon amaliyotdan foydalansa, yangi boshlanuvchilar bu yomon amaliyotni kodlar bazasida takrorlashlari mumkin, chunki ular buni yaxshi kod deb o'ylaganlaridan bilib olishdi.

Ba'zi kod yomon ko'rinadi, lekin uning atrofida maxsus holat bo'lishi mumkin, bu uni ishlab chiqaruvchini shunday yozishga majbur qiladi. Bu yangi boshlanuvchilarga ushbu holat haqida va nima uchun kod shunday yozilganligi haqida batafsil ma'lumot berish uchun yaxshi joy.

Yangi boshlanuvchi sifatida siz tushunmagan barcha hujjatsiz kodlar yomon bo'lish uchun nomzod deb taxmin qilishingiz kerak. Savol bering. Bu haqda so'rang. uni ayblash!

Agar kod muallifi allaqachon o'tib ketgan bo'lsa yoki eslay olmasa, kodni o'rganing va u haqida hamma narsani tushunishga harakat qiling. Kodni to'liq tushunganingizdan keyingina uning yomon yoki yaxshi ekanligi to'g'risida xulosa chiqarishingiz mumkin. Undan oldin hech narsa deb o'ylamang.

15) Eng yaxshi amaliyotlar haqida obzor

Menimcha, "eng yaxshi amaliyot" atamasi zararli. Bu qo'shimcha tadqiqotlar kerak emasligini anglatadi. Mana bu eng yaxshi amaliyot. Bunga shubha qilmang!

Eng yaxshi amaliyotlar yo'q. Ehtimol, bugungi kunda va ushbu dasturlash tili uchun yaxshi amaliyotlar mavjud.

Biz ilgari dasturlashda eng yaxshi tajriba sifatida aniqlagan ba'zi narsalar bugungi kunda yomon amaliyot deb nomlanadi.

Agar etarli vaqt sarflasangiz, har doim yaxshiroq tajribalarni topishingiz mumkin. Eng yaxshi amaliyotlar haqida tashvishlanishni to'xtating va nima qila oladiganingizga e'tibor qarating.

Biror joyda o'qiyotganingiz uchun yoki boshqa birov buni qilganini ko'rganingiz uchun yoki kimdir buni eng yaxshi amaliyot deb aytgani uchun biror narsa qilmang. Bu mening ushbu maqolada bergan barcha maslahatlarimni o'z ichiga oladi! hamma narsaga savol bering, barcha nazariyalarga qarshi turing, barcha imkoniyatlaringizni biling va faqat ma'lumotli qarorlar qabul qiling.

16) Ishlash haqida kuzatish

Erta optimallashtirish dasturlashdagi barcha yovuzlikning (yoki hech bo'lmaganda uning aksariyat qismi) ildizidir
- Donald Knut (1974)

Donald Knut yuqoridagi bayonotni yozgandan beri dasturlash sezilarli darajada o'zgargan bo'lsa-da, menimcha, bugungi kunda u qimmatli maslahatlarga ega.

Shuni yodda tutish kerak bo'lgan yaxshi qoida: agar siz kod bilan ishlashda shubhali muammoni o'lchay olmasangiz, uni optimallashtirishga urinmang.

Agar siz kodni ishlatishdan oldin optimallashtirsangiz, siz uni muddatidan oldin bajarayotgan bo'lishingiz mumkin. Vaqtingizni sarflayotgan optimallashtirish umuman keraksiz bo'lib qolishi mumkin.

Albatta, yangi kodni kiritishdan oldin har doim e'tiborga olish kerak bo'lgan aniq optimallashtirishlar mavjud. Masalan, Node.js-da, voqealar qatorini to'ldirmaslik yoki qo'ng'iroqlar to'plamini bloklamaslik juda muhimdir. Bu har doim yodda tutishingiz kerak bo'lgan erta optimallashtirishning misoli. O'zingizdan so'rang: Men o'ylayotgan kod qo'ng'iroqlar blokini blokirovka qiladimi?

Mavjud har qanday kodda o'lchovlarsiz amalga oshiriladigan har qanday noaniq optimallashtirish zararli deb hisoblanadi va undan qochish kerak. Ishlash samaradorligi oshishi mumkin deb o'ylagan narsalar, agar amalga oshirilsa, yangi, kutilmagan xatolarga olib kelishi mumkin.

Belgilanmagan ishlash muammolarini optimallashtirishga vaqtni isrof qilmang.

17) Yakuniy foydalanuvchi tajribasini maqsad qilmaslik

Ilovaga xususiyat qo'shishning eng oson usuli qanday? O'zingizning nuqtai nazaringizdan yoki joriy foydalanuvchi interfeysiga qanday mos kelishini ko'rib chiqing. To'g'ri? Agar xususiyat foydalanuvchi tomonidan biron-bir ma'lumotni yozib olish uchun bo'lsa, uni o'zingiz kiritgan shaklga qo'shib qo'ying. Agar bu xususiyat sahifaga havolani qo'shish bo'lsa, uni allaqachon mavjud bo'lgan havolalar menyusiga qo'shing.

Bu dasturchi bo'lmang. O'zlarini oxirgi foydalanuvchilarning poyabzaliga qo'yadigan professionallardan biri bo'ling. Ular ushbu xususiyatdan foydalanuvchilar nimaga muhtojligini va o'zlarini qanday tutishlari mumkinligini tasavvur qilishadi. Ular ushbu xususiyatni kashf etilishi va foydalanishga yaroqliligi haqida hech qanday tasavvurga ega bo'lmasdan, dasturda bu xususiyatni biron bir tarzda mavjud bo'lishining oson usuli haqida emas, balki foydalanuvchilar uchun bu xususiyatni topish va foydalanishni osonlashtirish usullari haqida o'ylashadi.

18) Ish uchun to'g'ri vositani tanlamaslik

Har kim o'zlarining dasturlash bilan bog'liq aktivlashtirishlarida yordam beradigan sevimli vositalarining ro'yxatiga ega. Ba'zi vositalar juda yaxshi, ba'zilari esa yomon, ammo aksariyat vositalar bitta narsa uchun juda yaxshi va boshqalari uchun unchalik yaxshi emas.

Bolg'a - mixni devorga ulash uchun ajoyib vosita, ammo bu vida bilan ishlatishda eng yomon vositadir. Vintlarda bolg'ani ishlatmang, chunki bu bolg'ani "sevganingiz" uchun. Vida bolg'ani ishlatmang, chunki bu Amazonda 5.0 foydalanuvchi sharhiga ega eng mashhur bolg'a.

Muammoga qanchalik mos kelmasin, vositaning mashhurligiga ishonish haqiqiy yangilikning belgisidir.

Ushbu masala bo'yicha bitta muammo shundaki, siz ma'lum bir ish uchun "yaxshiroq" vositalarni bilmasligingiz mumkin. O'zingizning mavjud bilimlaringiz ichida ushbu vosita siz biladigan eng yaxshi vosita bo'lishi mumkin. Ammo, boshqa variantlar bilan solishtirganda, u eng yaxshi ro'yxatni yaratmaydi. Siz foydalanishingiz mumkin bo'lgan vositalar bilan tanishib chiqishingiz va foydalanishni boshlashingiz mumkin bo'lgan yangi vositalar haqida ochiq fikr bildirishingiz kerak.

Ba'zi kodlovchilar yangi vositalardan foydalanishni rad etishadi. Ular o'zlarining mavjud vositalaridan foydalanishlari uchun qulaydir va ular ehtimol yangi narsalarni o'rganishni xohlamaydilar. Men buni tushunaman va men bunga aloqador bo'lishim mumkin, lekin bu noto'g'ri.

Siz ibtidoiy asboblar yordamida uy qurib, shirin vaqtingizni sarflashingiz yoki yaxshi vositalarga bir oz vaqt va pul sarflab, yaxshiroq uyni tezroq qurishingiz mumkin. Asboblar doimiy ravishda takomillashib bormoqda va siz ular haqida ma'lumot olish va ulardan foydalanishda qulay bo'lishingiz kerak.

19) Kod muammolarini tushunmaslik ma'lumotlar bilan bog'liq muammolarni keltirib chiqaradi

Ko'pincha ma'lumotlarning ba'zi bir shakllarini boshqarish dasturning muhim jihati hisoblanadi. Dastur yangi yozuvlarni qo'shish, eskisini o'chirish va boshqalarni o'zgartirish interfeysi bo'ladi.

Dastur kodidagi eng kichik xatoliklar ham uni boshqaradigan ma'lumotni oldindan aytib bo'lmaydigan holatga olib keladi. Bu, ayniqsa, agar ma'lumotlardagi barcha tasdiqlash to'liq bir xil ishlamaydigan dastur orqali amalga oshirilsa, to'g'ridir.

Yangi boshlanuvchilar kod-ma'lumotlar aloqasi haqida gap ketganda, darhol nuqta bilan bog'lanmasliklari mumkin. Ular ishlab chiqarishda ba'zi bir buggy kodni ishlatishda davom etishlari mumkin deb o'ylashlari mumkin, chunki ishlamayotgan X xususiyati juda muhim emas. Muammo shundaki, buggy kod birinchi bo'lib aniq ko'rinmaydigan ma'lumotlar uzluksiz ravishda doimiy ravishda kiritilishi mumkin.

Eng yomoni, xatolarni tuzatgan yuk kodi, ushbu xatolar tufayli kelib chiqqan nozik muammolarni hal qilmasdan, "qayta tiklanmaydigan darajadagi" yorlig'iga olib keladigan ma'lumotlarning ko'pgina muammolarini keltirib chiqaradi.

Bunday muammolardan o'zingizni qanday himoya qilasiz? Siz shunchaki ma'lumotlar yaxlitligini tekshirishning bir necha qatlamlaridan foydalanishingiz mumkin. Yagona foydalanuvchi interfeysiga ishonmang. Oldingi, orqa, tarmoq aloqalari va ma'lumotlar bazalarida tekshiruvlarni yarating. Agar bu tanlov bo'lmasa, unda siz hech bo'lmaganda ma'lumotlar bazasi darajasidagi cheklovlardan foydalanishingiz kerak.

Ma'lumotlar bazasiga cheklovlar bilan tanishib chiqing va ma'lumotlar bazasiga ustunlar va jadvallarni qo'shganda ulardan foydalaning:

  • Ustundagi NULL cheklov bu ustun uchun nol qiymatlar rad etilishini bildiradi. Agar sizning arizangiz ushbu maydon uchun qiymat mavjudligini taxmin qilsa, uning manbai sizning ma'lumotlar bazangizda nol bo'lmagan deb aniqlanishi kerak.
  • Ustundagi UNIQUE cheklovi bu jadval butun jadvalda takroriy qiymatlarga ega bo'lolmaslik degan ma'noni anglatadi. Masalan, bu foydalanuvchi stolidagi foydalanuvchi nomi yoki elektron pochta maydoni uchun juda yaxshi.
  • CHECK cheklovi bu qabul qilinadigan ma'lumotlarning haqiqiyligini baholashi kerak bo'lgan odatiy ibora. Masalan, normal qiymat ustuni 0 dan 100 gacha bo'lishi kerak bo'lsa, siz buni cheklash uchun cheklash vositasidan foydalanishingiz mumkin.
  • PRIMARY KEY cheklovi ustunning qiymatlari ham nol va noyob emasligini anglatadi. Ehtimol siz bundan foydalanyapsiz. Ma'lumotlar bazasidagi har bir jadval o'z yozuvlarini aniqlash uchun birlamchi kalitga ega bo'lishi kerak.
  • XORIJIY KEYINGIZNI cheklash degani, ustunning qiymatlari boshqa jadval ustunidagi qiymatlarga mos kelishi kerak, bu odatda birlamchi kalit hisoblanadi.

Ma'lumotlarning yaxlitligi bilan bog'liq yana bir yangi muammo - bu bitimlar nuqtai nazaridan fikrlashning etishmasligi. Agar bir nechta ma'lumot bir xil ma'lumot manbasini o'zgartirishi kerak bo'lsa va ular bir-biriga bog'liq bo'lsa, ushbu operatsiyalardan biri muvaffaqiyatsiz bo'lganda orqaga qaytarilishi mumkin bo'lgan operatsiyani bajarish kerak.

20) G'ildirakni yangilash

Bu qiyin nuqta. Dasturlashda ba'zi g'ildiraklar shunchaki ixtiro qilishga arziydi. Dasturlash aniq belgilangan domen emas. Shunday qilib, ko'p narsalar juda tez o'zgaradi va yangi talablar har qanday jamoaning qo'lidan kelmaydigan tezroq kiritiladi.

Masalan, sizga kunning vaqtiga qarab turli xil tezliklarda aylanadigan g'ildirak kerak bo'lsa, biz hammamiz bilamiz va sevamiz g'ildirakni sozlash o'rniga, ehtimol uni qayta ko'rib chiqishimiz kerak. Ammo, agar sizga odatiy dizaynida ishlatilmaydigan g'ildirak kerak bo'lsa, uni qayta ixtiro qilmang. Faqat la'natlangan g'ildirakdan foydalaning.

Ba'zida mavjud bo'lgan ko'plab variantlar orasida kerakli g'ildirakning markasini tanlash qiyin. Bir oz tadqiqot olib boring va sotib olishdan oldin sinab ko'ring! Dastur "g'ildiraklari" ning yoqimli jihati shundaki, ularning aksariyati bepul va ularning ichki dizaynini ko'rish uchun sizga ochiqdir. Siz kodlash g'ildiraklarini ichki dizayn sifati bilan osongina hukm qilishingiz mumkin. Iloji bo'lsa, ochiq manbali g'ildiraklardan foydalaning. Ochiq manbali paketlarni tuzatish va osongina o'rnatish mumkin. Ular, shuningdek, osongina almashtirilishi mumkin. Bundan tashqari, ularni uyda qo'llab-quvvatlash osonroq.

Biroq, sizga g'ildirak kerak bo'lsa, butunlay yangi mashina sotib olmang va o'zingiz saqlayotgan mashinani o'sha yangi mashinaning ustiga qo'ying. Biror funktsiyani yoki undan ikkitasini ishlatish uchun butun kutubxonani kiritmang. Eng yaxshi misol bu JavaScript-dagi lodash kutubxonasi. Agar siz faqat massivni aralashtirishingiz kerak bo'lsa, aralashtirish usulini import qiling. Lodash kutubxonasini butunlay import qilmang.

21) Kodni ko'rib chiqishda noto'g'ri munosabatda bo'lish

Yangilarni kodlashning belgilaridan biri shundaki, ular ko'pincha kodlarni o'rganishga tanqid sifatida qarashadi. Ularga yoqmaydi. Ular buni qadrlamaydilar. Ular hatto ulardan qo'rqishadi.

Bu noto'g'ri. Agar siz shunday his qilsangiz, darhol bu munosabatni o'zgartirishingiz kerak. Har bir kodni o'rganishga o'rganish imkoniyati sifatida qarang. Ularni kutib oling va ularni qadrlang. Ulardan o'rganing. Va eng muhimi, sizga biror narsani o'rgatganda, sharhlovchilaringizga rahmat.

Siz abadiy kodni o'rganuvchisiz. Buni qabul qilishingiz kerak. Ko'pgina kod sharhlari sizga bilmagan narsalarni o'rgatadi. Ularni o'quv manbai sifatida tasniflang.

Ba'zan, taqrizchi xato qiladi va ularga biron bir narsani o'rgatish sizning navbatingiz bo'ladi. Ammo, agar bu narsa faqat sizning kodingizdan aniq bo'lmasa, unda sizning kodingizni o'zgartirish kerak bo'lishi mumkin. Va agar biron-bir holatda sizning sharhlovchingizga nimanidir o'rgatish kerak bo'lsa, shuni bilingki, o'qitish dasturchi sifatida qila oladigan eng foydali ishlardan biridir.

22) Manba boshqaruvidan foydalanmaslik

Yangi boshlanuvchilar ba'zan yaxshi manba / tuzatish nazorati tizimining kuchini kam baholaydilar va yaxshi tomoni bilan Gitni aytmoqchiman.

Resursni boshqarish shunchaki o'zgartirishlaringizni boshqalarga kerak va kuchaytirishga majburlamaydi. Bu juda katta. Manba nazorati aniq tarix haqida. Kod so'roq qilinadi va ushbu kodning rivojlanish tarixi ba'zi qiyin savollarga javob berishga yordam beradi. Shuning uchun biz xabarlarni yuborish haqida qayg'uramiz. Ular sizning amaliyotlaringiz haqida xabar berishning yana bir kanalidir va ularni mayda-chuyda narsalar bilan ishlatish kelajakda kodni ushlab turuvchilarga kod hozirgi paytda qanday bo'lganligini aniqlashga yordam beradi.

Ko'pincha topshiriq bering va ertaroq bajaring va izchillikni sevish uchun hozirgi mavzu fe'lida hozirgi zamon fe'llaridan foydalaning. O'zingizning xabarlaringizni batafsil ko'rib chiqing, ammo shuni yodda tutingki, ular xulosa bo'lishi kerak. Agar ularga bir nechta satrlar kerak bo'lsa, bu sizning majburiyatingiz juda uzoq ekanligidan dalolatdir. Rebase!

O'zingizning xabarlaringizga keraksiz narsalarni qo'shmang. Masalan, qo'shilgan, o'zgartirilgan yoki o'chirilgan fayllarni ro'yxat qilmang. Ushbu ro'yxat buyruq ob'ektining o'zida mavjud va ba'zi Git buyruq argumentlari bilan osongina namoyish etiladi. Xulosa xabarida shunchaki shovqin bo'lishi mumkin. Ba'zi jamoalar har bir fayl uchun har xil xulosa chiqarishni yaxshi ko'rishadi va men buni majburiyatning yana bir belgisi sifatida juda katta ekanligini bilaman.

Manba nazorati, shuningdek, kashf qilinadigan narsadir. Agar siz biron bir funktsiyaga duch kelsangiz va uning ehtiyojlari yoki dizayniga savol berishni boshlasangiz, siz uni kiritgan majburiyatni topishingiz va ushbu funktsiyaning kontekstini ko'rishingiz mumkin. Majburiyatlar hatto dasturga xato kiritgan kodni aniqlashga yordam beradi. Git hatto xato sodir etgan yagona aybdorni topish uchun (bisect buyrug'i) buyruqlar ichida ikkilik qidiruvni taklif qiladi.

O'zgarishlar rasmiy kuchga kirishidan oldin ham manbalarni boshqarish ajoyib usullarda qo'llanilishi mumkin. O'zgarishlarni sahnalashtirish, saralash, saralash, sozlash, o'zgartirish, qo'llash, farqlash, orqaga qaytarish va boshqalar kabi xususiyatlardan foydalanish sizning kodlash oqimingizga bir qancha boy vositalarni qo'shadi. Ularni tushuning, o'rganing, foydalaning va ularni qadrlang.

Git xususiyatlari qancha kam bo'lsa, siz mening kitobimda shunchalik ko'p yangilik borligini bilasiz.

23) Ortiqcha ishlatiladigan umumiy holat

Bu yana boshqa paradigmalarga nisbatan funktsional dasturlash borasida nuqta bo'lmaydi. Bu boshqa maqola uchun mavzu.

Bu shunchaki umumiy muammo muammolar manbai ekanligi va iloji bo'lsa, ularni oldini olish kerakligi haqida. Agar buning iloji bo'lmasa, umumiy holatdan foydalanish mutlaq minimal darajada saqlanishi kerak.

Men boshlang'ich dasturchi sifatida tushunmadim, biz belgilaydigan har bir o'zgaruvchi umumiy holatni anglatadi. Unda ushbu o'zgaruvchini bir xil doiradagi barcha elementlar o'zgartirishi mumkin bo'lgan ma'lumotlar mavjud. Ushbu miqyos global miqyosda kengaygan sari, ushbu umumiy davlatning chegarasi shunchalik yomonlashadi. Kichik o'lchamdagi yangi holatlarni saqlashga harakat qiling va ularning yuqoriga oqib chiqmasligiga ishonch hosil qiling.

Birgalikda ishlatiladigan holat bilan bog'liq katta muammo bir nechta manbalar ushbu holatni bir xil voqea qatorida (voqea-hodisaga asoslangan muhitda) birgalikda o'zgartirish kerak bo'lganda yuzaga keladi. Irqiy shartlar ro'y beradi.

Gap shundaki, yangi kelgan kishi ushbu umumiy davlat poygasi muammosi uchun echim sifatida taymerdan foydalanish vasvasasiga tushishi mumkin, ayniqsa, agar ular ma'lumotlar bloklanishi muammosiga duch kelsa. Bu katta qizil bayroq. Buni qilma. Uni tomosha qiling, kod sharhlarida ko'rsatib qo'ying va hech qachon qabul qilmang.

24) Xatolar haqida noto'g'ri munosabatda bo'lish

Xatolar yaxshi narsa. Bu sizning muvaffaqiyatga erishayotganingizni anglatadi. Bu sizning oldinga siljish uchun oson o'zgartirishlar kiritilishini anglatadi.

Mutaxassis dasturchilar xatolarni yaxshi ko'radilar. Yangi boshlanuvchilar ularni yomon ko'rishadi.

Agar siz ushbu ajoyib qizil xatolar haqidagi xabarlarni ko'rib chiqsangiz, sizni bezovta qilsangiz, bu munosabatni o'zgartirishingiz kerak. Siz ularga yordamchi sifatida qarashingiz kerak. Siz ular bilan shug'ullanishingiz kerak. Rivojlanish uchun siz ulardan foydalanishingiz kerak.

Ba'zi xatolarni istisnolardan yaxshilash kerak. Istisnolar bu siz rejalashtirishingiz kerak bo'lgan foydalanuvchi tomonidan aniqlangan xatolar. Ba'zi xatolar yolg'iz qolishi kerak. Ular dasturni buzishi va undan chiqishini ta'minlashi kerak.

25) Tanaffuslar qilmaslik

Siz odamsiz va miyangiz tanaffuslarga muhtoj. Tana tanaffuslarga muhtoj. Siz tez-tez zonada bo'lasiz va tanaffus qilishni unutasiz. Men bunga yangilarning yana bir belgisi sifatida qarayman. Bu siz murosa qiladigan narsa emas. Sizni tanaffus qilishga majbur qilish uchun ish oqimiga biror narsani qo'shing. Qisqa tanaffuslarni ko'p qiling. Kreslodan chiqib, qisqa yurish qiling va bundan keyin nima qilishingiz kerakligi haqida o'ylash uchun foydalaning. Kodni yangi ko'zlar bilan qaytaring.

Bu uzoq xabar edi. Siz tanaffusga loyiqsiz.

O'qiganingiz uchun rahmat. Hayot haqida umumiy maslahat olish uchun men yozgan yana bir O'rta maqolani ko'rib chiqing.