Ajam dasturchilarning odatiy xatolarini tahlil qilish: 1-qism

Salom Dunyo! Sizga kerak bo'lgan hamma narsani o'rganganingizdan va nihoyat stajyor yoki kichik o'quvchi sifatida ishga kirganingizdan so'ng, dam olishingiz mumkin, shunday emasmi? Qanday bo'lmasin! Hammasi endi boshlanmoqda... Atrofingizda juda ko'p yangi va tushunarsiz narsalar bor va qanday qilib to'g'ridan-to'g'ri darvozadan chiqib ketmaslik kerak? Bugun biz bu haqda gaplashamiz. Ushbu maqolada men yangi boshlanuvchilar tomonidan yo'l qo'yiladigan keng tarqalgan xatolarni ko'rib chiqmoqchiman va ularni qanday qilib oldini olish bo'yicha o'z tajribamdan ba'zi maslahatlar bermoqchiman. Shunday ekan, keling, ortiqcha gapsiz boshlaylik:

1. Ko'proq tajribali hamkasblardan yordam so'rashdan qo'rqish

Biz hammamiz insonmiz va hammamiz ahmoq bo'lib ko'rinishdan qo'rqamiz, ayniqsa yangi zarb qilingan, tajribali hamkasblarimizning ko'ziga. Birinchi ish joyiga ega bo'lgandan so'ng, ishlab chiquvchilar ko'pincha bu qo'rquvga berilib, hamma narsani o'z-o'zidan tushunishga harakat qilib, o'zlariga chekinadilar. Shu bilan birga, odamni tajribali hamkasblar o'rab olishlari mumkin, ular o'z navbatida uni dastlab eng to'g'ri yo'lga yo'naltira oladilar, bu esa ko'proq xatolar va keraksiz "zarbalar" ning oldini olishga yordam beradi. Shuning uchun, esda tuting: savol berishdan qo'rqmang: siz yangi boshlovchisiz va hamma buni juda yaxshi tushunadi. Siz so'rasangiz, hech kim sizni tayoq bilan urishmaydi. Ehtimol, bu hatto aksincha: siz hamkasblaringiz bilan tezroq do'stlashasiz va ular bilan faolroq muloqot qilishni boshlaysiz. Men ko'proq aytaman: turli xil texnik masalalarni qanchalik ko'p so'rasangiz va muhokama qilsangiz, yashil boshlang'ich poyafzalidan tezroq chiqib, o'z sohangizning mutaxassisi bo'lishingiz mumkin. Va yana bir maslahat. StackOverFlow ni e'tiborsiz qoldirmang . Shu nuqtai nazardan, men ushbu manba bo'yicha savollar berishni nazarda tutyapman. Bir tomondan, savolingizga javob olish uchun biroz vaqt kerak bo'ladi. Ammo boshqa tomondan, siz darhol mavjud muammoni hal qilishning bir nechta yondashuvlarini bilib olishingiz va unga biroz boshqacha nuqtai nazardan qarashingiz mumkin. Shuni ham ta'kidlashni istardimki, sharhlar-javoblar yozish, boshqa ishlab chiquvchilarning StackOverFlow bo'yicha savollariga aniqlik kiritish, karmadagi plyusdan tashqari, amaliy foyda keltiradi: sizda bu masalani chuqurroq muhokama qilish va tushunish imkoniyati mavjud.

2. O'zingiz ma'lumot izlashga urinmang

Ehtimol, bu xato avvalgisining teskari tomonidir. Har bir muammo yoki muammo bilan hamkasblaringiz va tanishlaringizga tortishni boshlaganingizda aytmoqchiman. So'rash yaxshi, lekin siz savollar bilan uzoqqa bormasligingiz kerak, aks holda siz shunchaki zerikishingiz mumkin. Agar biron bir tushunarsiz nuqta paydo bo'lsa, qilish kerak bo'lgan birinchi narsa, qidiruv qobiliyatingizni eng yaxshi qidiruv tizimida - Googleda qo'llashdir. Kimdir allaqachon tushunarsiz xatolar va boshqa muammolarning aksariyatiga duch kelgan. Va agar siz uni Google orqali qidirsangiz va shunga o'xshash muammo bilan tanish bo'lgan va o'z ishlarida foydalanish uchun to'liq javoblarni olgan odamlar sonini ko'rsangiz, hayron qolasiz. Shunga asoslanib, siz tez-tez hamkasbingizning "Google uni" degan savoliga javob berishini eshitishingiz mumkin. Bu javobdan xafa bo'lmaslik kerak, chunki sizning hamkasbingiz sizning faoliyat sohangizning barcha nozik tomonlarini etkazishi kerak bo'lgan shaxsiy o'qituvchi emas. Internetning cheksiz kengliklari sizga bunday maslahat bilan yordam beradi. Ba'zan dasturchi Google qidiruvida qora kamarli odam deb ham ataladi . Shuning uchun, biz tiqilib qolganimizda, biz birinchi navbatda muammoni Google-da qidiramiz va agar yechim topilmasa (kamdan-kam hollarda, lekin shunday bo'ladi), keyin biz hamkasblarimizdan so'rashni boshlaymiz. Ulardan qandaydir nosozlik yoki tushunarsiz xatolik yuz berganda emas, balki muammoni hal qilish uchun yondashuvni tanlashda darhol so'rashga arziydi. Axir, ular siznikidan tashqarini ko'rishlari mumkin va u yoki bu yondashuv uzoq muddatda qanday bo'lishi mumkinligini darhol aytishlari mumkin.

3. Blind copy-paste

Ammo muammoni googling va shunga mos ravishda uning yechimi o'z tuzoqlariga ega. Masalan, ko'r-ko'rona nusxa ko'chiring . Bu odatda shunga o'xshash muammoni topsangiz (lekin aynan bir xil emas) va uning ostida, masalan, StackOverFlow-da yechim mavjud. Siz ushbu yechimni olasiz, ko'p tafsilotlarga kirmasdan, uni o'zingiz nusxa ko'chiring va joylashtiring. Va keyin siz yoki loyiha hamkasblaringiz ba'zi g'alati xatolarni yoki funksionalligingizning noto'g'ri xatti-harakatlarini topasiz. Va darhol hech kim oyoqlarning qaerdan kelganini bilmaydi. Shunda, albatta, ushbu kodga ega joy topiladi va siz bu qaroringiz uchun maqtovga sazovor bo'lmaysiz. Shuning uchun, siz StackOverFlow-da (yoki boshqa joyda) tayyor echimni topsangiz, birinchi navbatda uni batafsil tahlil qilishingiz kerak, bu nima, qanday va nima uchun. Ehtimol, ushbu funksiyani Google orqali qidirib toping va buning uchun hujjatlarni ko'rib chiqing. Va shundan keyingina uni loyihangizga kiriting.

4. Noto'g'ri yechimni tashlash

Yechim yozayotganda, ba'zida u tobora murakkablashib, oxir-oqibat boshi berk ko'chaga etib boradi. Va siz boshqa, samaraliroq muqobil qidirish o'rniga, ushbu yondashuvdan foydalanib, bu muammoni qandaydir tarzda hal qilish uchun uni tobora murakkablashtirmoqchisiz. Ehtimol, siz shunchaki sarflagan kuchingiz va vaqtingiz uchun afsuslanasiz va shuning uchun siz qaror qilasiz: nima bo'lishidan qat'iy nazar, taslim bo'lmang, balki muammoni shu tarzda hal qiling. Bu mutlaqo to'g'ri yondashuv emas. Hech bo'lmaganda dasturlashda. Boshqa yondashuvni qanchalik tezroq sinab ko'rsangiz, shuncha ko'p vaqtni tejaysiz. Shuning uchun tajriba qilishdan qo'rqmang va bunga qancha vaqt sarflagan bo'lsangiz ham, boshqa yondashuvlarni sinab ko'ring. Bundan tashqari, bu sizning tajribangiz uchun nuqta bo'ladi, chunki siz bir nechta yondashuvlarni sinab ko'rasiz va bu sohani yaxshiroq o'rganasiz.

5. Hozirgi vazifa haqida savol berishdan qo'rqish

Loyiha ustida ishlash odatda ba'zi vazifalarni bajarishga to'g'ri keladi (Vazifalar). Masalan, Jirada . Va bu vazifalar har doim ham batafsil va aniq tasvirlangan emas. Ular odatda jamoa etakchilari tomonidan yoziladi va agar bu sodir bo'lsa, bular ham odamlardir. Ular, shuningdek, biror narsa qo'shishni unutishlari yoki u yoki bu funksionallik bilan unchalik tanish emasligingizni hisobga olmasliklari mumkin. Xo'sh, yoki sizda loyihaga kirish imkoni yo'q (masalan, ma'lumotlar bazasiga, jurnal serveriga va boshqalarga kirish). Va endi, topshiriqni qabul qilib, uni bir necha soatdan ko'proq vaqt davomida o'rganib chiqib, siz hali ham hayratda o'tirasiz va ekranga qaraysiz. Va buni behuda tushunishda davom etishning o'rniga, siz ushbu vazifani yaratuvchiga etakchi/aniqlashtiruvchi savollar berishni boshlashingiz kerak. Aytaylik, siz jamoada muloqot qilish uchun foydalanadigan dasturda (masalan, Microsoft Teams) yoki to'g'ridan-to'g'ri ushbu vazifa ostida sharh sifatida. Bir tomondan, agar siz shaxsiy xabarda savol yozsangiz, javob tezroq bo'ladi, chunki odam savolni darhol ko'radi. Boshqa tomondan, Jirada savol berish orqali siz biror narsa qilayotganingiz, ya'ni muammoni tahlil qilayotganingiz haqida dalillarga ega bo'lasiz. Bu jarayonni tezlashtirishning bir usuli bor: Jira-da sharh sifatida savol bering va qarash so'rovi bilan shaxsiy xabarda ushbu sharhga havolani yuboring.

6. Jamoa yetakchisidan juda ko‘p narsa kutish

Shunga qaramay, bu avvalgi nuqtaning teskari tomoni. Jamoa rahbari - bu rivojlanish guruhining rahbari bo'lgan shaxs. Qoida tariqasida, bunday jamoa a'zosining ko'p vaqti turli xil aloqa turlariga sarflanadi. Va shu bilan birga, u nima ekanligini unutmaslik uchun kod yozadi. Xo'sh, siz tushunganingizdek, bu juda band belgi. Va har bir aksirish uchun haddan tashqari tebranish uni baxtli qilmaydi. Tasavvur qiling-a, har bir jamoa a'zosi uni bir nechta savollar bilan bombardimon qilgan bo'lsa. Shunday qilib, siz aqldan ozishingiz mumkin, shunday emasmi? Va sizning ko'plab savollaringiz bilan u sizga uzoq vaqt javob berishi ajablanarli emas. Jamoa rahbariga savollar sonini kamaytirish uchun nima qilishingiz mumkin:

• Ko'r joylar sonini kamaytirish uchun ushbu loyihaning hujjatlarini chuqurroq o'rganing.
• Boshqa jamoa a'zolariga savollar bering. Ehtimol, ular ushbu funktsiyani etakchi kabi yoki undan ham ko'proq bilishadi, chunki ulardan biri bu funksiyani yozgan.

Shu bilan bir qatorda, IDE-da siz izohlarni ko'rishingiz mumkin: ma'lum bir satrda kodni kim va qachon oxirgi marta o'zgartirgan. Shu tarzda biz bu savolni kim to'g'ri berishini bilib olamiz. Siz allaqachon tushunganingizdek, jamoa rahbariga savollar berishda, shuningdek, hamkasblarga savol berishda siz oltin o'rtachani saqlashga harakat qilishingiz kerak - savol berishdan qo'rqmang, balki ularni ortiqcha raqam bilan bezovta qilmang.

7. Kodni ko'rib chiqishdan qo'rqish

Kodni ko'rib chiqish yoki kodni ko'rib chiqish - bu kodni umumiy dasturga (umumiy filialga, masalan, master yoki dev) yuklashdan oldingi bosqich. Ushbu tekshirish ushbu vazifaga aloqador bo'lmagan ishlab chiquvchi tomonidan amalga oshiriladi, u yangi ko'rinish bilan rivojlanishning dastlabki bosqichida sezilmagan kod uslubidagi xatolar, noaniqliklar yoki kamchiliklarni aniqlay oladi. Agar sharhlar mavjud bo'lsa, ular kodning ma'lum bo'limlariga sharh sifatida qoldiriladi. Bunday holda, ushbu vazifani bajargan ishlab chiquvchi ko'rib chiqishga muvofiq xatolarni tuzatishi kerak (yoki uning qarorlarini sharhlovchi bilan muhokama qilish, ehtimol uni qarorining to'g'riligiga ishontirish). Shundan so'ng, uni qayta ko'rib chiqish uchun yuboring va sharhlovchida hech qanday izoh bo'lmaguncha davom eting. Kodni yuklashdan oldin sharhlovchi "filtr" vazifasini bajaradi. Shunday qilib, ko'plab yangi dasturchilar kodni ko'rib chiqishni tanqid va qoralash deb bilishadi. Ular uni qadrlamaydilar va undan qo'rqishadi va bu noto'g'ri. Bu kodni ko'rib chiqish bizga kodimizni yaxshilashga imkon beradi. Axir, biz nima noto'g'ri qilayotganimiz va nimalarga e'tibor berishimiz kerakligi haqida muhim ma'lumotlarni olamiz. Har bir kodni ko'rib chiqishni o'rganishning bir qismi sifatida ko'rish kerak, bu sizni yaxshilashga yordam beradi. Biror kishi sizning kodingizga sharh qoldirganda, u siz bilan o'z tajribasi, eng yaxshi amaliyotlari bilan o'rtoqlashadi. Menga kelsak, siz kodni ko'rib chiqmasdan turib yaxshi dasturchi bo'lolmaysiz. Chunki siz o'zingizning kodingiz qanchalik yaxshi ekanligini va u erda tashqaridan tajribali odam nuqtai nazaridan xatolar bor-yo'qligini ham bilmaysiz.

8. Mavhum yechimlarga moyillik

Ko'pincha turli vazifalar/muammolar bir nechta turli xil echimlarga ega bo'lishi mumkin. Va mavjud bo'lgan barcha echimlardan yangi boshlanuvchilar odatda eng murakkab va "abstruse"lardan foydalanadilar. Va bu haqiqat: agar yangi boshlanuvchi dasturchi kechagina juda ko'p turli xil algoritmlarni, naqshlarni, ma'lumotlar tuzilmalarini o'rgangan bo'lsa, qo'llari ulardan birini amalga oshirishga qichishadi. Ha, va men o'zimni e'lon qilishni xohlayman. Ishoning, men o'zim ham shunday bo'lganman va nima haqida gapirayotganimni bilaman :) Menda juda va juda murakkab bo'lgan bitta funktsiyani yozishga uzoq vaqt sarflaganim bor edi. Keyin u Senior+ darajadagi dasturchi tomonidan qayta yozilgan. Albatta, men uni nimani va qanday o'zgartirganini ko'rishga qiziqdim. Men uning amalga oshirilishini ko'rib chiqdim va bu qanchalik soddalashtirilganiga hayron bo'ldim. Va kod uch baravar kamroq bo'ldi. Va shu bilan birga, ushbu funksionallik uchun testlar o'zgarmadi va muvaffaqiyatsiz bo'lmadi! Ya'ni, umumiy mantiq bir xil bo'lib qoladi. Bundan men shunday xulosaga keldim: eng aqlli echimlar har doim oddiy . Ushbu amalga oshirilgandan so'ng, kod yozish ancha osonlashdi va u sezilarli darajada yuqori bo'ldi. Xo'sh, qachon naqsh va algoritmlardan foydalanishga arziydi, deb so'rayapsizmi? Keyin ularni ishlatishda eng oddiy va ixcham usul bo'ladi.

9. Velosipedlarning ixtirosi

Ushbu kontseptsiya g'ildirak ixtirosi sifatida ham tanilgan. Uning mohiyati shundan iboratki, ishlab chiquvchi yechimlari allaqachon mavjud bo'lgan muammoga o'z yechimini amalga oshiradi va dasturchi tomonidan ixtiro qilinganidan bir necha baravar yaxshiroq. Qoidaga ko'ra, o'z velosipedingizni ixtiro qilish vaqtni yo'qotish va ishlab chiqaruvchining ishi samaradorligini pasayishiga olib keladi, chunki eng yaxshisidan uzoq bo'lgan yechim topilmasligi yoki umuman topilmasligi mumkin. Shu bilan birga, mustaqil qaror qabul qilish imkoniyatidan voz kechib bo'lmaydi. Dasturchi o'z oldida paydo bo'lishi mumkin bo'lgan vazifalarni to'g'ri va o'z vaqtida hal qilish, tayyor echimlardan foydalanish yoki o'zini ixtiro qilish uchun to'g'ri yo'naltirishi kerak. Bir tomondan, universitetlarda va kurslarda bizni velosipedlarni yaratishga yordam beradigan turli xil vazifalar qo'ymoqda. Ammo bu faqat birinchi qarashda. Darhaqiqat, bundan maqsad algoritmik tafakkurni rivojlantirish va til sintaksisini chuqurroq egallashdir. Va bunday vazifalar, shuningdek, algoritmlarni/tuzilmalarni yaxshiroq tushunishga yordam beradi va agar kerak bo'lsa, ularga ilg'or analoglarini amalga oshirish ko'nikmalarini beradi (lekin bu juda kamdan-kam hollarda kerak). Haqiqiy hayotda, aksariyat hollarda, o'z g'ildiragini ixtiro qilishning hojati yo'q, chunki bizning ehtiyojlarimizni qondiradigan analoglar uzoq vaqtdan beri mavjud. Ehtimol, tajribangiz tufayli siz o'zingizga kerak bo'lgan u yoki bu funksiyalarning amalga oshirilishi haqida bilmay qolasiz. Bu erda siz ushbu maqolaning birinchi nuqtasidan foydalanishingiz kerak, ya'ni tajribali hamkasblardan yordam so'rang. Ular sizga yo'l-yo'riq ko'rsatishi mumkin (masalan, Google-ga qaysi yo'nalishda maslahat berish) yoki muayyan dasturni taklif qilishlari mumkin (ma'lum kutubxona).

10. Testlarni yozmang

Hamma yangi boshlanuvchilar test yozishni yoqtirmaydi. Yangi boshlanuvchilar haqida nima deyish mumkin: yangi boshlanuvchilar ham test yozishni yoqtirmaydilar, lekin ular nima uchun kerakligini yaxshiroq tushunishadi. Siz butunlay yashil bo'lganingizda, o'ylaysiz: nega ularni yozasiz? Hammasi ishlaydi va hech qanday xato bo'lishi mumkin emas. Ammo sizning o'zgarishlaringiz tizimning boshqa qismida biror narsani buzmasligiga qanday ishonch hosil qilishingiz mumkin? Hamkasblaringiz foydadan ko'ra ko'proq xalaqit beradigan o'zgarishlarni amalga oshirsangiz, buni qadrlashmaydi. Bu erda sinovlar yordamga keladi. Ilova testlar bilan qanchalik ko'p qamrab olinsa, shuncha yaxshi (qamrov foizi deb ham ataladi). Agar ilova testlar bilan yaxshi qamrab olingan bo'lsa, ularning barchasini ishga tushirish orqali siz o'zgartirishlaringiz buzilishi mumkin bo'lgan joylarni topishingiz mumkin. Va yuqoridagi misolda aytganimdek, funksionallikni qayta tiklashda testlar muvaffaqiyatsiz bo'lmadi va barchasi umumiy mantiq o'zgarmaganligi sababli. Bu shuni anglatadiki, testlar ma'lum bir funktsiyaning mantig'i o'zgargan yoki o'zgarmaganligini ham ko'rsatishi mumkin. Shunday ekan, agar siz test yozishni yoqtirmasangiz ham, ulardan shubhasiz foyda bor va ular ularga sarflangan vaqtga arziydi.

11. Ortiqcha fikr bildirish

Ko'pgina ishlab chiquvchilar perfektsionizmdan aziyat chekmoqda va yangi boshlanuvchilar bundan mustasno emas. Ammo ba'zida bu istakning yon ta'siri shundaki, ular hamma va hamma narsani sharhlay boshlaydilar. Hatto nima kerak emas, chunki bu juda aniq:

Cat cat = new Cat(); // cat Object

Kodni sharhlash har doim ham yaxshi narsa emasligini hamma yangi boshlovchi dasturchilar darhol anglamaydilar, chunki kod yanada chalkash va o'qish qiyinroq bo'lib chiqadi. Agar kod o'zgartirilsa-chi, lekin unga hech qanday izoh berilmagan bo'lsa? Ma'lum bo'lishicha, u bizni aldaydi va faqat bizni chalg'itadi. Nega unday izoh? Odatda, yaxshi yozilgan kod izohga muhtoj emas , chunki undagi hamma narsa allaqachon aniq va o'qilishi mumkin. Agar siz sharh yozsangiz, bu siz allaqachon kodning o'qish qobiliyatini buzganingizni va qandaydir tarzda vaziyatni yumshatishga harakat qilayotganingizni anglatadi. Eng yaxshi yondashuv dastlab sharhlar bilan to'ldirilishi shart bo'lmagan o'qilishi mumkin bo'lgan kodni yozish bo'ladi. Usullar, o'zgaruvchilar va sinflarning to'g'ri nomlanishini, ya'ni men o'zim amal qiladigan qoidani ham eslatib o'tolmadim: Eng yaxshi sharh - bu sharhning yo'qligi va buning o'rniga - u yoki bu narsani aniq tasvirlaydigan to'g'ri nom. ilovangizdagi funksionallik.

12. Noto'g'ri nomlash

Ko'pincha, yangi boshlanuvchilar sinflar, o'zgaruvchilar, usullar va boshqalar nomlarini soxtalashtiradilar.Masalan, nomi uning maqsadini umuman tasvirlamaydigan sinfni yaratganda. Yoki o'zgaruvchi qisqa nom bilan yaratiladi, x kabi narsa va yana ikkita n va y nomli o'zgaruvchilar yaratilganda, x nima qilishini eslab qolish juda qiyin bo'ladi . Bunday hollarda siz kod haqida yaxshilab o'ylab ko'rishingiz va u erda nima sodir bo'layotganini tushunish uchun ushbu funksiyani mikroskop ostida o'rganishingiz kerak (ehtimol, tuzatuvchi yordamida). Bu erda yuqorida aytib o'tgan koddagi to'g'ri nom bizga yordam beradi. To'g'ri nomlar kodning o'qilishini yaxshilaydi, shunga mos ravishda tanishish vaqtini tejaydi, chunki nom uning funksionalligini taxminan tavsiflaydigan usuldan foydalanish ancha oson. Kodda hamma narsa nomlardan iborat (o'zgaruvchilar, usullar, sinflar, fayl ob'ektlari va boshqalar), bu nuqta to'g'ri, toza kod yaratishda juda muhim bo'ladi. Esda tutish kerakki, ism ma'noni anglatishi kerak: masalan, o'zgaruvchi nima uchun mavjud, u nima qiladi va qanday ishlatiladi. Va yana va yana bir bor ta'kidlaymanki, o'zgaruvchini tavsiflash uchun eng yaxshi sharh uning to'g'ri nomidir. Sharhlarni chuqurroq o'rganish va to'g'ri nomlash uchun men sizga abadiy klassikani o'qishni maslahat beraman: "Toza kod. Yaratish, tahlil qilish va qayta ishlash”, Robert Martin . Ushbu eslatma bilan ushbu maqolaning birinchi qismi (mulohazalar) nihoyasiga yetdi. Davomi bor…