Анализ на често срещаните грешки, допускани от начинаещи програмисти, т. 1

Здравей свят! След като научите всичко, което трябва да знаете и най-накрая започнете да работите като стажант or младши разработчик, вероятно можете да се отпуснете, нали? не Всичко тепърва започва за вас... Заобиколени сте от много ново и неразбираемо. Как да не го прецакаш още от портата? За това ще си говорим днес. В тази статия искам да анализирам често срещаните грешки на новобранците и да дам някои съвети, базирани на моя собствен опит, How да ги избягвам. И така, нека започнем без повече шум:

1. Страх от търсене на помощ от по-опитни колеги

Всички сме хора. Всички се страхуваме да не изглеждаме глупави, особено в очите на нашите нови, по-опитни колеги. Когато разработчиците поемат първата си работа, те често се ръководят от този страх и с тежко чуване се затварят в себе си, опитвайки се да разберат всичко сами. Освен това някой може да бъде заобиколен от по-опитни колеги, които от своя страна са в състояние да го насочат в най-обещаващата посока, помагайки да се избегнат повече грешки и ненужни „удари по главата“. Така че запомнете: не се страхувайте да задавате въпроси. Вие сте начинаещ и всички го разбират прекрасно. Когато поискаш, никой няма да те бие с тояги. Може би дори ще се случи обратното: ще станете приятели с колегите си по-бързо и ще започнете да се радвате на по-активно общуване с тях. аз Ще кажа още повече: колкото повече питате и обсъждате различни технически проблеми, толкова по-бързо ще можете да свалите зелената си нова кожа и да израснете в експерт във вашата област. И още един съвет. Не бъди непознатStackOverflow . Говоря специално за задаването на въпроси на този ресурс. От една страна, отнема известно време, за да получите отговор на въпроса си. Но от друга страна, може бързо да научите множество подходи за решаване на проблема си и да го погледнете от малко по-различен ъгъл. Също така искам да отбележа, че има практически ползи от писането на коментари/отговори и писането на изясняващи въпроси по въпроси на StackOverflow от други разработчици: получавате шанс да обсъждате и да се задълбочите в проблемите, да не говорим за повишаване на кармата.

2. Да не се опитвате да търсите информация сами

Тази грешка може да се счита за обратната страна на предишната.Тук имам предвид, когато започнете да досаждате на колегите и познатите си за всеки проблем or хълцане, които срещнете. Питането е хубаво, но не прекалявайте с въпросите. В противен случай хората може просто да ви намерят за досадни. Ако се объркате за нещо, първото нещо, което трябва да направите, е да упражните уменията си за търсене в най-добрата търсачка — Google. Някой друг вече се е сблъсквал с огромното мнозинство от неразбираеми грешки и други проблеми. И ще бъдете доста изненадани, ако потърсите въпроса си в Google и видите броя на хората, които са запознати с подобен проблем и които вече са получor изчерпателни отговори, които можете да приложите в собствената си работа. Ето защо често ще чуете вашите колеги да отговарят с „Гугъл“. не Не се обиждайте от този отговор - вашият колега не е ваш личен учител, който трябва да предаде всички тънкости на вашата сфера на работа. Безкрайните простори на интернет ще бъдат ваш ментор. Понякога програмистите също се наричатхора с черен колан в Google търсене . Така че, ако имаме "хълцане", първо търсим проблема в Google. Ако не може да се намери решение (това е рядко, но се случва), едва тогава започваме да питаме колегите. Незабавните въпроси са за получаване на съвет относно подхода, който трябва да изберете за разрешаване на проблем, повече от това, което бихте направor, когато ударите неравномерна неравномерност or неразбираемо съобщение за грешка. В края на краищата те може да са в състояние да видят отвъд предпочитания от вас подход и незабавно да предскажат докъде ще доведе даден подход в дългосрочен план.

3. Сляпо копиране и поставяне

Но проблемите с гугъл и техните решения имат своите клопки. Например сляпо копиране и поставяне .Това обикновено се случва, когато намерите подобен проблем (но може би не точно същия) и свързано решение, например в StackOverflow. Вземате това решение и го копирате и поставяте, без да се задълбочавате повече в подробностите. И тогава вие or вашите колеги откривате някои странни грешки or неправилно поведение във вашия code. И никой не може веднага да познае откъде са дошли. В крайна сметка, разбира се, мястото с копирания code ще бъде намерено и определено няма да бъдете похвалени за вашето решение. Следователно, когато намерите готово решение в StackOverflow (or където и да е другаде), първо трябва да разберете напълно Howво, How и защо. Може би потърсете в Google съответната функционалност и прочетете documentацията за нея. И едва след като го направите, трябва да го добавите към вашия проект.

4. Придържане към грешното решение

Когато пишете решение, понякога ще откриете, че то непрекъснато става все по-сложно и накрая стига до задънена улица. И тогава се опитвате да направите решението още по-сложно, за да го накарате няHow да работи, instead of да търсите друга, по-подходяща алтернатива. Може би чувствате, че сте инвестирали много време и усorя и затова сте решor, че Howвото и да става, няма да се откажете и ще разрешите проблема със съществуващия си подход. Това не е съвсем правилно отношение. Поне в програмирането. Колкото по-рано опитате различен подход, толкова повече време ще спестите в крайна сметка. Така че не се страхувайте да експериментирате и да опитате други подходи, независимо от времето, което сте инвестирали в настоящия си. Нещо повече, като изпробвате множество подходи и се потопите по-задълбочено в темата, вие

5. Страх от задаване на въпроси относно текущата ви задача

Работата по проект за разработка на софтуер обикновено се свежда до изпълнение на конкретни задачи. Например в Jira. Тези задачи не винаги са очертани ясно и подробно. Описанията на задачите обикновено се пишат от ръководители на екипи, които също са простосмъртни. Може да забравят да добавят нещо or да не отчетат факта, че не сте запознати с тази or онази функционалност. Или може би нямате ниHowъв достъп до проекта (например достъп до базата данни, регистрационния сървър и т.н.). И сега, вие сте получor задачата, изучавали сте я повече от няколко часа, но все още седите там и се взирате в екрана с недоумение. Вместо да продължавате безуспешно да се опитвате да разберете това, трябва да започнете да поискате разяснение or насоки от този, който е създал задачата. Например в приложението, което вашият екип използва за комуникация (например Microsoft Teams), можете да задавате въпроси or да правите директен коментар относно задачата. От една страна, ако напишете въпроса си в лично съобщение, вероятно ще получите отговор по-бързо, тъй като човекът ще види въпроса ви веднага. От друга страна, задавайки въпрос в Jira, установявате доказателство, че правите нещо, а именно анализирате проблема. Има начин да ускорите този процес: задайте въпроса си в коментар в Jira и след това в DM, пуснете връзка към коментара си и помолете да погледнете.

6. Поставяне на нереалистично високи очаквания към ръководството на екипа

Отново, това е обратната страна на предишната точка. Ръководителят на екипа е ръководител на екип за разработка. По правило ръководителят на вашия екип прекарва по-голямата част от времето си в различни видове комуникация. И все пак той or тя също пише code, за да не забравя всичко за програмирането. Както можете да разберете, животът на ръководител на екип е много натоварен. Да дърпате ръководителя на екипа си за ръкава всеки път, когато трябва да кихнете, очевидно няма да ви е приятно. Представете си, че всеки член на екипа бомбардира водещия с куп въпроси. Това може да подлуди всеки, нали? И ако натрупате много въпроси, тогава ръководителят на вашия екип ще трябва да отдели много време, за да ви отговори. Какво може да се направи, за да се намали броят на въпросите, насочени към ръководителя на екипа:

• Проучете по-задълбочено проектната documentация, за да намалите броя на слепите петна.
• Насочете въпросите си към другите членове на вашия екип. Те може да са толкова запознати с тази функционалност, колкото и водещият, or дори повече, тъй като функционалността най-вероятно е написана от един от тях.

Като алтернатива можете да разгледате анотациите в IDE за това кой и кога codeът в конкретен ред е бил последно променен. Точно така можете да разберете кой е най-подходящият човек, който да зададе вашия въпрос. Както вероятно вече разбирате, когато става въпрос за въпроси към ръководителя на екипа, точно Howто при въпроси към колеги, трябва да се опитате да намерите щастлива среда – не се страхувайте да задавате въпроси, но също така не задавайте твърде много от тях.

7. Страх от прегледи на codeове

Преглед на codeае такъв етап, който се случва преди да изпратите codeа си към общо приложение (към споделен клон, например master or dev). Тази проверка се извършва от разработчик, който не участва в задачата, чиито свежи очи могат да открият грешки, неточности or недостатъци във вашия стил на code, които са останали незабелязани, когато първоначално сте написали своя code. Ако има критики, те се оставят като коментари към определени части от codeа. В този случай програмистът, който е написал codeа, трябва да коригира грешките, идентифицирани в рецензията (or да обсъди решенията си с рецензента, като евентуално го убеди, че са правилни). След това codeът се изпраща за преглед отново и отново, докато рецензентът няма повече коментари. Рецензентът действа като "шлюз" преди codeът да бъде ангажиран. Предизвикателството е, че много начинаещи програмисти възприемат прегледа на codeа като критика и осъждане. Те не оценяват прегледите на codeа и се страхуват от тях. Те не трябва. Прегледите на codeа са точно това, което ни позволява да подобрим нашия code. В края на краищата получаваме важна информация за това Howво правим погрешно и на Howво си струва да обърнем внимание. Трябва да разглеждате всеки преглед на codeа като част от кривата на обучение, нещо, което може да ви помогне да станете по-добри. Когато някой коментира вашия code, той or тя споделя опит и най-добри практики с вас. Аз лично не вярвам, че можете да станете добър програмист, без да получавате прегледи на codeа. Защото дори не сте наясно с качеството на вашия code и дали опитен аутсайдер би посочил грешки. не оценявам прегледите на codeа и се страхувам от тях. Те не трябва. Прегледите на codeа са точно това, което ни позволява да подобрим нашия code. В края на краищата получаваме важна информация за това Howво правим погрешно и на Howво си струва да обърнем внимание. Трябва да разглеждате всеки преглед на codeа като част от кривата на обучение, нещо, което може да ви помогне да станете по-добри. Когато някой коментира вашия code, той or тя споделя опит и най-добри практики с вас. Аз лично не вярвам, че можете да станете добър програмист, без да получавате прегледи на codeа. Защото дори не сте наясно с качеството на вашия code и дали опитен аутсайдер би посочил грешки. не оценявам прегледите на codeа и се страхувам от тях. Те не трябва. Прегледите на codeа са точно това, което ни позволява да подобрим нашия code. В края на краищата получаваме важна информация за това Howво правим погрешно и на Howво си струва да обърнем внимание. Трябва да разглеждате всеки преглед на codeа като част от кривата на обучение, нещо, което може да ви помогне да станете по-добри. Когато някой коментира вашия code, той or тя споделя опит и най-добри практики с вас. Аз лично не вярвам, че можете да станете добър програмист, без да получавате прегледи на codeа. Защото дори не сте наясно с качеството на вашия code и дали опитен аутсайдер би посочил грешки. правите ли грешно и на Howво си струва да обърнете внимание. Трябва да разглеждате всеки преглед на codeа като част от кривата на обучение, нещо, което може да ви помогне да станете по-добри. Когато някой коментира вашия code, той or тя споделя опит и най-добри практики с вас. Аз лично не вярвам, че можете да станете добър програмист, без да получавате прегледи на codeа. Защото дори не сте наясно с качеството на вашия code и дали опитен аутсайдер би посочил грешки. правите ли грешно и на Howво си струва да обърнете внимание. Трябва да разглеждате всеки преглед на codeа като част от кривата на обучение, нещо, което може да ви помогне да станете по-добри. Когато някой коментира вашия code, той or тя споделя опит и най-добри практики с вас. Аз лично не вярвам, че можете да станете добър програмист, без да получавате прегледи на codeа. Защото дори не сте наясно с качеството на вашия code и дали опитен аутсайдер би посочил грешки.

8. Склонност към тайнствени решения

Различните задачи/проблеми често могат да имат няколко различни решения. И от всички налични решения, начинаещите са склонни да използват най-сложните и загадъчни. И това има смисъл: начинаещите програмисти вчера научиха много различни алгоритми, модели и структури от данни, така че ги сърбят ръцете да внедрят някои от тях. Повярвайте ми, аз бях такъв, така че знам за Howво говоря :) Имах ситуация, в която внедрявах няHowва функционалност дълго време. Оказа се много, много сложно. След това старши разработчик пренаписа моя code. Разбира се, много ми беше интересно да видя Howво и How го е променил. Погледнах изпълнението му и бях изумен колко по-просто беше. И имаше три пъти по-малко code. И също удивително, автоматизираните тестове за тази функционалност не бяха премахнати or променени! С други думи, общата логика остава същата. От това стигнах до извода, ченай-гениалните решения винаги са прости . След това осъзнаване codeирането стана много по-лесно и качеството на codeа ми скочи на значително по-високо ниво. Тогава кога си струва да се прилагат дизайнерски модели и фантастични алгоритми, ще попитате? При прилагането им ще бъде най-простото и компактно решение.

9. Преоткриване на колелото

Колелото е дълготрайно решение, изобретено отдавна. В този анти-модел разработчикът прилага свое собствено собствено решение за проблем, който вече е решен. Понякога тези съществуващи решения са по-добри от това, което програмистът предлага. По правило преоткриването на колелото ще доведе до загуба на време и намалена производителност, тъй като решението, което ще намерите, може да е далеч от най-доброто or, е, може изобщо да не намерите такова. Въпреки това не можем да изключим възможността да създадем собствено независимо решение: ако го направим, тогава всичко, което ще остане, е копиране и поставяне на програмиране. Програмистът трябва правилно да се ръководи от възникващите специфични програмни задачи, за да ги решава компетентно и своевременно, независимо дали чрез използване на готови решения or чрез създаване на решения по поръчка. От една страна, в университетите и в онлайн курсовете сме бомбардирани с различни видове задачи, които изглежда са предназначени да ни помогнат да преоткрием колелата. Но само на пръв поглед: истинската цел тук е развиване на алгоритмично мислене и по-задълбочено овладяване на езиковия синтаксис. Такива задачи също ви помагат да разберете по-добре алгоритмите и структурите на данни и ви дават умения за внедряване на по-сложни двойници, ако е необходимо (това понякога е необходимо, но е изключително рядко). В реалния живот не е необходимо да измисляте собствено колело в преобладаващата част от случаите, тъй като колела, които отговарят на вашите нужди, съществуват от дълго време. Може би вашата неопитност ви пречи да знаете за съществуването на реализации на функционалността, от която се нуждаете. Тук трябва да приемете съветите, дадени в първата точка на тази статия, а именно, помолете за помощ по-опитни колеги. Те ще могат да ви насочат (например да ви насочат в правилната посока при търсенето ви в Google) or да предложат конкретна реализация (например няHowва библиотека).

10. Ненаписване на тестове

Всички начинаещи не обичат да пишат тестове. Но защо трябва да открояваме новобранците тук? По-опитните разработчици също не обичат да пишат тестове, но те по-добре разбират защо са необходими тестове. Когато си съвсем зелен, се чудиш защо трябва да ги пишеш. Всичко работи, така че не може да има грешки. Но How да гарантирате, че промените ви няма да нарушат нещо другаде в системата? Вашите колеги няма да го оценят, ако наложите промени, които причиняват повече вреда, отколкото полза. Тук на помощ идват тестовете. Колкото повече codeът на дадено приложение е обхванат от тестове, толкова по-добре (това се нарича покритие на code or тестово покритие). Ако приложението има добро тестово покритие, тогава можете да изпълните всички тестове, за да намерите места, които ще бъдат нарушени от вашия code. И Howто казах в примера по-горе, когато старшият разработчик преработи codeа, тестовете не се провалиха. Това беше така, защото общата логика не се промени. Използваме тестове, за да демонстрираме дали логиката на определена функционалност се е променила or не. Така че дори и да не обичате да пишете тестове, те определено са полезни и си заслужават времето, отделено за тях.

11. Прекалени коментари

Много разработчици страдат от перфекционизъм и начинаещите не са изключение. Понякога те проявяват само една страна от тази склонност, когато започват да коментират всички и всичко. Дори да правите коментари, които са ненужни, защото codeът е толкова очевиден:

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

Не всички начинаещи програмисти веднага осъзнават, че коментирането на codeа не винаги е добро, защото излишните коментари претрупват codeа и го правят труден за четене. И Howво, ако codeът се промени, но старите коментари не се актуализират? Тогава само ще ни подведат и объркат. Тогава защо изобщо прави такъв коментар? Обикновено добре написаният code не се нуждае от коментар , тъй като всичко в него вече е очевидно и четимо. Ако трябва да напишете коментар, значи вече сте развалor четливостта на codeа и се опитвате по няHowъв начин да поправите ситуацията. Най-добрият подход е да напишете четим code от самото начало, т.е. code, който не се нуждае от коментари. Също така не мога да не спомена необходимостта да се следват правилните конвенции за именуване на методи, променливи и класове. Ето моето правило: Най-добрият коментар е or без коментар, or правилно именуване, което ясно описва функционалността във вашето приложение.

12. Лошо именуване

Новаците играят бързо и свободно в наименуването на класове, променливи, методи и т.н. Например, като създадат клас, чието име изобщо не описва неговата цел. Или те декларират променлива с кратко име, нещо като x . Те, когато още две променливи, наречени n и yса създадени, запомнянето за Howво е отговорен x става много трудно. Изпequalsи пред тази ситуация, трябва да помислите внимателно за codeа, като го анализирате под микроскоп (може би с помощта на дебъгер), изучавайки функционалността, за да разберете просто Howво се случва. Тук на помощ ни идват правилните конвенции за именуване, които споменах по-горе. Правилните имена подобряват четливостта на codeа, като по този начин намаляват времето, необходимо за запознаване с codeа, тъй като използването на метод е много по-лесно, когато името му приблизително описва неговата функционалност. Всичко в codeа се състои от имена (променливи, методи, класове, обекти, файлове и т.н.), така че тази точка става много важна при създаването на правилен, чист code. Трябва да запомните, че името трябва да предава meaning, например защо променливата съществува, Howво прави, и How се използва. Ще отбележа повече от веднъж, че най-добрият коментар за една променлива е да й дадете добро име. За по-задълбочено проучване на коментарите и правилно именуване препоръчвам да прочетете вечните класики:„Чист code: Наръчник за изработване на гъвкав софтуер“ от Робърт Мартин . На тази бележка първата част на тази статия (моите размисли) приключи. Следва продължение...