Жаңадан келген бағдарламашылардың типтік қателіктерін талдау: 1 бөлім

Сәлем Әлем! Сізге қажет нәрсені біліп, тағылымдамадан өтуші немесе кіші қызметкер ретінде жұмысқа қабылданғаннан кейін, сіз демалуға болады, солай ма? Қалай болса да! Бәрі енді ғана басталып жатыр... Айналаңызда көптеген жаңа және түсініксіз нәрселер бар, және дәл осылай қақпадан шығып кетпеу керек пе? Бұл туралы бүгін сөйлесетін боламыз. Бұл мақалада мен жаңадан бастағандар жиі жіберетін қателіктерді қарастырғым келеді және оларды болдырмау туралы өз тәжірибемнен бірнеше кеңестер бергім келеді. Олай болса, көп ұзамай бастайық:

1. Тәжірибелі әріптестерден көмек сұраудан қорқу

Біз бәріміз адамбыз және бәріміз ақымақ болып көрінуден қорқамыз, әсіресе жаңадан шыққан, тәжірибелі әріптестеріміздің көз алдында. Алғашқы жұмысқа орналасқаннан кейін, әзірлеушілер жиі осы қорқынышқа бой алдырады және бәрін өз бетімен анықтауға тырысады. Сонымен қатар, адамды тәжірибелі әріптестері қоршай алады, олар өз кезегінде оны бастапқыда ең дұрыс жолға бағыттай алады, бұл көбірек қателіктер мен қажетсіз «төбелестерден» аулақ болуға көмектеседі. Сондықтан, есіңізде болсын: сұрақ қоюдан қорықпаңыз: сіз бастаушысыз және мұны бәрі жақсы түсінеді. Сұрасаң ешкім таяқпен ұрмайды. Мүмкін бәрі керісінше болуы мүмкін: сіз әріптестеріңізбен тезірек достасасыз және олармен белсендірек араласа бастайсыз. Мен көбірек айтайын: сіз әртүрлі техникалық мәселелерді неғұрлым көп сұрап, талқыласаңыз, соғұрлым сіз жасыл бастаушы аяқ киімнен тезірек шығып, өз ісіңіздің маманы бола аласыз. Және тағы бір кеңес. StackOverFlow параметрін елемеңіз . Осы тұрғыда мен осы ресурс бойынша сұрақтар қоюды айтқым келеді. Бір жағынан сұрағыңызға жауап алу үшін біраз уақыт қажет. Бірақ екінші жағынан, сіз бірден ағымдағы мәселені шешудің бірнеше тәсілдерін біліп, оған сәл басқаша көзқараспен қарауыңыз мүмкін. Сондай-ақ, басқа әзірлеушілерден StackOverFlow бойынша сұрақтарға түсініктемелер-жауаптар жазу, кармадағы плюспен қатар, сұрақтарды нақтылаудың практикалық пайдасы бар: сізде бұл мәселені тереңірек талқылауға және түсінуге мүмкіндік бар екенін атап өткім келеді.

2. Ақпаратты өз бетіңізше іздеуге тырыспаңыз

Мүмкін бұл қате алдыңғының кері жағы болуы мүмкін. Менің айтайын дегенім, сіз әріптестеріңіз бен таныстарыңызды әр мәселеге немесе мәселеге тарта бастағанда. Сұрау жақсы, бірақ сұрақтармен тым алысқа бармау керек, әйтпесе жалықтыруыңыз мүмкін. Егер қандай да бір түсініксіз мәселе туындаса, бірінші нәрсе - іздеу дағдыларыңызды ең жақсы іздеу жүйесінде - Google-да қолдану. Біреу түсініксіз қателердің және басқа мәселелердің басым көпшілігіне тап болды. Егер сіз оны Google арқылы іздесеңіз және осыған ұқсас мәселемен таныс және өз жұмысында қолдануға болатын жан-жақты жауаптар алған адамдардың санын көрсеңіз, таң қаласыз. Осыған сүйене отырып, сіз әріптесіңіздің «Google оны Google» деген сұраққа жауап беретінін жиі естисіз. Бұл жауап сізді ренжітпеу керек, өйткені сіздің әріптесіңіз сіздің жұмыс саласының барлық қыр-сырын жеткізе алатын жеке ұстаз емес. Интернеттің шексіз кеңістігі сізге осындай тәлімгерлікпен көмектеседі. Кейде бағдарламашыны Google іздеуінде қара белбеулі адам деп те атайды . Сондықтан, біз кептеліп қалғанда, біз алдымен мәселені Google-да іздейміз, егер шешімі табылмаса (сирек, бірақ солай болады), содан кейін біз әріптестерімізден сұрай бастаймыз. Қандай да бір ақау немесе түсініксіз қате болған кезде емес, мәселені шешудің тәсілін таңдаған кезде олардан бірден сұраған жөн. Өйткені, олар сіздің көзқарасыңыздан тыс нәрсені көре алады және сол немесе басқа тәсіл ұзақ мерзімді перспективада қалай болатынын бірден айта алады.

3. Соқыр көшіріп қою

Бірақ проблеманы іздеудің және сәйкесінше оның шешімін табудың өз қателері бар. Мысалы, соқыр көшіріп қою . Бұл әдетте ұқсас проблеманы тапқанда болады (бірақ дәл солай емес) және оның астында, мысалы, StackOverFlow бағдарламасында шешім бар. Сіз бұл шешімді қабылдап, тым көп егжей-тегжейлі айтпай, оны өзіңіз көшіріп, қойыңыз. Содан кейін сіз немесе жоба әріптестеріңіз кейбір оғаш қателерді немесе функционалдықыңыздың дұрыс емес әрекетін табасыз. Аяқтардың қайдан келетінін бірден ешкім білмейді. Сонда, әрине, осы codeпен орын табылады және бұл шешіміңіз үшін сізді мақтауға болмайды. Сондықтан, сіз StackOverFlow (немесе басқа жерде) дайын шешімді тапқан кезде, ең алдымен оны егжей-тегжейлі талдауыңыз керек, бұл не, қалай және неге. Мүмкін бұл функцияны Google іздеп, оның құжаттамасын қараңыз. Содан кейін ғана оны жобаңызға енгізіңіз.

4. Қате шешімді лақтыру

Шешімді жазғанда кейде ол күрделеніп, ақырында тұйыққа тіреледі. Сіз басқа, тиімдірек балама іздеудің орнына осы тәсілді пайдаланып, бұл мәселені қандай да бір жолмен шешу үшін оны барған сайын қиынdateға тырысасыз. Бәлкім, сіз жұмсаған күш пен уақыт үшін өкінетін шығарсыз, сондықтан сіз шешім қабылдадыңыз: ештеңеге қарамастан, бас тартпаңыз, бірақ мәселені осылай шешіңіз. Бұл мүлдем дұрыс көзқарас емес. Кем дегенде бағдарламалауда. Басқа тәсілді неғұрлым тезірек қолдансаңыз, соғұрлым көп уақытты үнемдейсіз. Сондықтан тәжірибе жасаудан қорықпаңыз және оған қанша уақыт жұмсағаныңызға қарамастан, басқа тәсілдерді қолданып көріңіз. Сонымен қатар, бұл сіздің тәжірибеңіз үшін ұпайлар болады, өйткені сіз бірнеше тәсілдерді қолданып, осы саланы жақсырақ зерттейсіз.

5. Ағымдағы тапсырма бойынша сұрақ қоюдан қорқу

Жоба бойынша жұмыс әдетте кейбір тапсырмаларды (Тапсырмалар) орындауға келеді. Мысалы, Джирада . Және бұл міндеттер әрқашан егжей-тегжейлі және анық сипатталмайды. Оларды әдетте топ жетекшілері жазады, бұл да адамдар, егер бірдеңе болса. Олар сондай-ақ бірдеңе қосуды ұмытып кетуі мүмкін немесе сіз осы немесе басқа функционалдықпен жақсы таныс емес екеніңізді ескермейді. Немесе сізде жобаға кіру рұқсаты жоқ (мысалы, дерекқорға, журнал serverіне және т.б.). Енді тапсырманы алып, оны бір-екі сағаттан астам зерттеп, сіз әлі таңырқай отырып экранға қарайсыз. Және бұл нәтиже бермеуді жалғастырудың орнына, осы тапсырманы жасаушыға жетекші/нақтылау сұрақтарын қоюды бастау керек. Айталық, сіз топта (мысалы, Microsoft Teams) байланыс үшін пайдаланатын қолданбада немесе осы тапсырма бойынша тікелей түсініктеме ретінде. Бір жағынан, егер сіз жеке хабарламада сұрақ жазсаңыз, жауап жылдамырақ болуы мүмкін, өйткені адам сұрақты бірден көреді. Екінші жағынан, Jira-да сұрақ қою арқылы сізде бірдеңе істеп жатқаныңызға, атап айтқанда мәселені талдауға дәлел болады. Бұл процесті жылдамdateдың бір жолы бар: Jira-да түсініктеме ретінде сұрақ қойыңыз және жеке хабарламада осы түсініктемеге сілтемені қарауды сұраумен жіберіңіз.

6. Топ басшысынан тым көп нәрсені күту

Тағы да, бұл алдыңғы тармақтың екінші жағы. Топ жетекшісі - әзірлеу тобының басшысы болып табылатын адам. Әдетте, мұндай команда мүшесінің уақытының көп бөлігі әртүрлі байланыс түрлеріне жұмсалады. Сонымен бірге ол мұның не екенін ұмытпау үшін code жазады. Түсінгеніңіздей, бұл өте бос кейіпкер. Әр түшкіру үшін шамадан тыс тербелу оны бақытты етпейтіні анық. Команданың әрбір мүшесі оны көптеген сұрақтармен бомбалағанын елестетіп көріңіз. Сонымен, сіз жынды бола аласыз, солай ма? Сіздің тарапыңыздан көптеген сұрақтармен ол сізге ұзақ уақыт жауап беруі таңқаларлық емес. Топ жетекшісіне қойылатын сұрақтар санын азайту үшін не істей аласыз:

• Соқыр дақтардың санын азайту үшін осы жобаның құжаттамасын тереңірек зерттеңіз.
• Басқа топ мүшелеріне сұрақтар қойыңыз. Олар бұл функциямен жетекші сияқты немесе одан да көп таныс болуы әбден мүмкін, себебі олардың біреуі бұл функцияны жазған болуы мүмкін.

Сонымен қатар, IDE-де сіз annotationларды көре аласыз: белгілі бір жолдағы codeты кім және қашан өзгерткені. Осылайша біз бұл сұрақты кім дұрыс қоятынын анықтаймыз. Сіз түсінген боларсыз, топ басшысына сұрақ қойғанда, сондай-ақ әріптестерге сұрақ қойғанда, сіз алтын ортаны сақтауға тырысуыңыз керек - сұрақ қоюдан қорықпаңыз, сонымен қатар оларды шамадан тыс санмен ренжітпеңіз.

7. Кодты шолудан қорқу

Кодты қарап шығу немесе codeты қарап шығу - бұл жалпы қолданбаға (жалпы фorалға, мысалы, негізгі немесе әзірлеушіге) codeты жүктеп салу алдындағы кезең. Бұл тексеруді осы тапсырмаға қатысы жоқ әзірлеуші ​​жүзеге асырады, ол жаңа көзқараспен әзірлеудің бастапқы кезеңінде байқалмай қалған code стиліндегі қателерді, дәлсіздіктерді немесе кемшіліктерді таба алады. Түсініктемелер болса, олар codeтың белгілі бір бөлімдеріне түсініктеме ретінде қалдырылады. Бұл жағдайда осы тапсырманы орындаған әзірлеуші ​​шолуға сәйкес қателерді түзетуі керек (немесе оның шешімдерін рецензентпен талқылауы, мүмкін оны өз шешімінің дұрыстығына сендіру). Содан кейін оны қайта қарауға жіберіңіз және т.с.с. шолушы ешқандай түсініктеме бермейінше. Тексеруші codeты жүктеп салмас бұрын «сүзгі» ретінде қызмет етеді. Сонымен, көптеген жаңадан келген бағдарламашылар codeты қарауды сын мен айыптау ретінде қабылдайды. Олар оны бағаламайды және одан қорқады, бұл дұрыс емес. Бұл codeты жақсартуға мүмкіндік беретін codeты шолу. Өйткені, біз нені дұрыс істемейміз және не нәрсеге назар аударуымыз керек екендігі туралы маңызды ақпарат аламыз. Әрбір codeты шолуды оқудың бір бөлігі ретінде қарастыру қажет, бұл сізге жақсартуға көмектеседі. Адам сіздің codeыңызға түсініктеме қалдырғанда, ол сізбен тәжірибесімен, ең жақсы тәжірибесімен бөліседі. Маған келетін болсақ, сіз codeты тексерусіз жақсы бағдарламашы бола алмайсыз. Өйткені сіз өзіңіздің codeыңыздың қаншалықты жақсы екенін және сырттан тәжірибелі адамның көзқарасы бойынша қателер бар-жоғын білмейсіз.

8. Абструздық шешімдерге бейімділік

Көбінесе әртүрлі тапсырмалар/проблемалар бірнеше түрлі шешімдерге ие болуы мүмкін. Барлық қол жетімді шешімдердің ішінде жаңадан бастағандар әдетте ең күрделі және «абструктивтік» шешімдерді пайдаланады. Бұл рас: егер жаңадан келген бағдарламашы кеше ғана әртүрлі алгоритмдерді, үлгілерді, деректер құрылымдарын зерттеген болса, олардың біреуін жүзеге асыру үшін оның қолдары қышиды. Иә, мен, былайша айтқанда, өзімді жария еткім келеді. Маған сеніңіз, мен де солай болдым және мен не туралы айтып жатқанымды білемін :) Менде өте күрделі болып шыққан бір функционалдылықты ұзақ уақыт жазуға кеткен жағдай болды. Содан кейін оны Senior+ деңгейіндегі әзірлеуші ​​қайта жазды. Әрине, оның нені және қалай өзгерткенін көру мені қызықтырды. Мен оның орындалуына қарап, оның қаншалықты қарапайым болғанына таң қалдым. Ал code үш есе азайған. Сонымен қатар, бұл функционалдылыққа арналған сынақтар өзгермеді және сәтсіздікке ұшырамады! Яғни, жалпы логика сол күйінде қалады. Осыдан мен мынадай қорытындыға келдім: ең тапқыр шешімдер әрқашан қарапайым . Бұл іске асырылғаннан кейін code жазу әлдеқайда жеңіл болды және ол айтарлықтай жоғары деңгейге жетті. Олай болса, үлгілер мен алгоритмдерді қашан пайдалану керек деп сұрайсыз ба? Содан кейін, оларды пайдалану кезінде ең қарапайым және ең жинақы әдіс болады.

9. Велосипедтердің өнертабысы

Бұл тұжырымдама дөңгелектің өнертабысы ретінде де белгілі. Оның мәні әзірлеуші ​​​​бағдарламашы ойлап тапқаннан бірнеше есе жақсы шешімдер бар мәселеге өз шешімін жүзеге асыруында жатыр. Әдетте, өзіңіздің велосипедіңізді ойлап табу уақытты жоғалтуға және әзірлеушінің жұмысының тиімділігінің төмендеуіне әкеледі, өйткені ең жақсыдан алыс шешім табылмауы немесе мүлде табылмауы мүмкін. Сонымен қатар біз тәуелсіз шешім қабылдау мүмкіндігін жоққа шығара алмаймыз. Бағдарламашы дайын шешімдерді қолдана отырып немесе өз бетінше ойлап табу арқылы оларды сауатты және дер кезінде шешу үшін оның алдында пайда болуы мүмкін тапсырмаларды дұрыс бағыттауы керек. Бір жағынан, университеттерде және курстарда бізге велосипедтерді жасауға көмектесетін әртүрлі тапсырмалар беріледі. Бірақ бұл бірінші көзқараста ғана. Шындығында, мұның мақсаты – алгоритмдік ойлауды дамытып, тіл синтаксисін тереңірек меңгеру. Сондай-ақ мұндай тапсырмалар алгоритмдерді/құрылымдарды жақсы түсінуге көмектеседі және қажет болған жағдайда оларға озық аналогтарын енгізу дағдыларын береді (бірақ бұл өте сирек қажет). Нақты өмірде, көп жағдайда, өз дөңгелегін ойлап табудың қажеті жоқ, өйткені біздің қажеттіліктерімізді қанағаттандыратын аналогтар бұрыннан бар. Мүмкін, тәжірибеңіздің арқасында сіз өзіңізге қажетті осы немесе басқа функционалдылықтың іске асырылуының бар-жоғын білмеуіңіз мүмкін. Бұл жерде сіз осы мақаланың бірінші тармағын пайдалануыңыз керек, атап айтқанда, тәжірибелі әріптестерден көмек сұраңыз. Олар сізге бағыт-бағдар бере алады (мысалы, Google-ге қай бағытта кеңес береді) немесе нақты енгізуді (белгілі бір кітапхана) ұсына алады.

10. Тесттерді жазбаңыз

Барлық жаңадан бастағандар тест жазуды ұнатпайды. Жаңадан бастаушылар ше: жаңадан басталмағандар да тест жазуды ұнатпайды, бірақ олар оның не үшін қажет екенін жақсы түсінеді. Сіз толығымен жасыл болған кезде, сіз ойлайсыз: неге оларды жазу керек? Мұның бәрі жұмыс істейді және қателер болуы мүмкін емес. Бірақ өзгертулер жүйенің басқа бөлігінде бірдеңені бұзbyteынына қалай сенімді бола аласыз? Әріптестеріңіз оларға пайдасынан гөрі кедергі келтіретін өзгерістерді итермелесеңіз, оны бағаламайды. Бұл жерде сынақтар көмекке келеді. Қолданба сынақтармен қаншалықты қамтылса, соғұрлым жақсы (қамту пайызы деп те аталады). Қолданба сынақтармен жақсы қамтылған болса, олардың барлығын іске қосу арқылы өзгертулеріңіз бұзылуы мүмкін орындарды таба аласыз. Жоғарыдағы мысалда айтқанымдай, функционалдылықты қайта өңдеу кезінде сынақтар сәтсіздікке ұшыраған жоқ және барлығы жалпы логика өзгермегендіктен. Бұл тесттер белгілі бір функцияның логикасы өзгерген-өзгермегенін де көрсете алады дегенді білдіреді. Сондықтан тест жазуды ұнатпасаңыз да, олардан сөзсіз артықшылықтар бар және олар оларға жұмсалған уақытты қажет етеді.

11. Шамадан тыс түсініктеме беру

Көптеген әзірлеушілер перфекционизмнен зардап шегеді, ал жаңадан бастағандар да ерекшелік емес. Бірақ кейде бұл тілектің жанама әсері олардың барлығына және бәріне түсініктеме бере бастайды. Тіпті қажет емес нәрсе, өйткені бұл өте айқын:

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

Барлық жаңадан келген бағдарламашылар түсініктеме беру codeы әрқашан жақсы нәрсе емес екенін бірден түсінбейді, өйткені code әлдеқайда күрделі және оқуға қиын болады. Егер code өзгертілсе, бірақ оған түсініктеме болмаса ше? Ол бізді алдап, тек шатастырады екен. Онда неге мұндай пікір қалды? Әдетте, жақсы жазылған code түсініктеме беруді қажет етпейді , өйткені ондағы бәрі түсінікті және оқуға болады. Егер сіз түсініктеме жазсаңыз, бұл codeтың оқылуын бұзып қойғаныңызды және жағдайды қандай да бір жолмен реттеуге тырысып жатқаныңызды білдіреді. Ең жақсы әдіс бастапқыда түсініктемелермен толықтырылмайтын оқылатын codeты жазу болады. Мен сондай-ақ әдістердің, айнымалылардың және сыныптардың дұрыс аталуын, атап айтқанда, мен ұстанатын ережені айта алмадым: Ең жақсы түсініктеме - түсініктеменің болмауы, ал оның орнына - осы немесе басқаны анық сипаттайтын дұрыс атау қолданбаңыздағы функционалдылық.

12. Нашар атау

Көбінесе жаңадан бастағандар сыныптардың, айнымалылардың, әдістердің және т.б. атауларын бұрмалайды. Мысалы, аты оның мақсатын мүлде сипаттамайтын класс жасағанда. Немесе айнымалы қысқа атаумен жасалады, мысалы , x сияқты нәрсе және n және y деп аталатын тағы екі айнымалы жасалғанда, x не істейтінін есте сақтау өте қиын болады . Мұндай жағдайларда code туралы мұқият ойластырып, онда не болып жатқанын түсіну үшін микроскоптың (мүмкін отладчикті пайдалануы мүмкін) осы функционалдылықты зерттеу керек. Міне, мен жоғарыда айтқан codeтағы дұрыс атау бізге көмекке келеді. Дұрыс атаулар codeтың оқылуын жақсартады, сәйкесінше танысу уақытын үнемдейді, өйткені атау оның функционалдығын шамамен сипаттайтын әдісті пайдалану әлдеқайда оңай. Кодта барлығы атаулардан тұрады (айнымалылар, әдістер, сыныптар, файлдық нысандар және т.б.), бұл нүкте дұрыс, таза codeты құру кезінде өте маңызды болады. Атаудың мағынасын беруі керек екенін есте ұстаған жөн: мысалы, айнымалы неліктен бар, ол не істейді және қалай қолданылады. Мен айнымалыны сипаттау үшін ең жақсы түсініктеме оның дұрыс атауы екенін қайта-қайта атап өтемін. Түсініктемелерді тереңірек зерттеу және дұрыс атау үшін мен сізге ескірмейтін классиканы оқуға кеңес беремін: «Таза code. Жасау, талдау және рефакторинг», Роберт Мартин . Осы жазбамен осы мақаланың бірінші бөлімі (ой толғаулары) аяқталды. Жалғасы бар…