Розбір типових помилок програмістів-початківців: частина 1

Hello, world! Після того, як ви вивчабо все необхідне і врешті-решт потрапабо на роботу стажером або джуніором, напевно, можна розслабитися, правда? Як би не так! Все тільки починається ... Навколо вас багато нового і незрозумілого, і як не напортачив ось так з порога? Ось про це сьогодні й поговоримо. У цій статті я хочу розібрати поширені помилки новачків і дати кілька порад із власного досвіду щодо їх уникнення. Отже, почнемо без зайвих передмов:

1. Страх звернутися за допомогою до досвідченіших колег

Всі ми люди, і всі ми боїмося виглядати безглуздо, особливо в очах новоспечених досвідченіших колег. Потрапивши на першу роботу, розробники часто йдуть на поводу даного страху і невтішно замикаються в собі, намагаючись розібратися в усьому особисто. При цьому людина може бути оточена більш досвідченими колегами, які, у свою чергу, зможуть направити спочатку найвірнішим шляхом, що допоможе уникнути більшої кількості помилок і зайвих “шишок”. Тому запам'ятайте: не треба боятися ставити запитання: ви новачок, і все це чудово розуміють. Коли ви питатимете, ніхто вас не битиме палицями. Можливо, навіть навпаки: ви швидше потоваришуватимете з колегами і почнете активніше з ними комунікувати. Скажу більше: чим більше ви будете питати і дискутувати про різні технічні моменти, тим швидше ви зможете вибратися зі шкіри зеленого новачка і перерости в експерта у своїй галузі. І ще одна порада. Не треба нехтуватиStackOverFlow . У цьому контексті я маю на увазі завдання на цьому ресурсі. З одного боку, потрібен якийсь час, щоб отримати відповідь на своє запитання. Але з іншого ви, можливо, дізнаєтеся відразу про кілька підходів до вирішення поточної проблеми та погляньте на неї трохи з іншого боку. Також хочу зазначити, що написання коментарів-відповідей, які уточнюють запитання на питання на StackOverFlow інших розробників, несуть, крім плюсика в карму, практичну користь: у вас з'являється можливість подискутувати і глибше розібратися в цьому питанні.

2. Не намагатись шукати інформацію самостійно

Мабуть, ця помилка є зворотною стороною попередньої. Я маю на увазі, коли ви при кожній проблемі чи затику починаєте смикати ваших колег та знайомих. Запитувати — це добре, але й із питаннями не треба перегинати, інакше можна просто набриднути. Перше, що потрібно робити, якщо сплив якийсь незрозумілий момент – застосовувати свої пошукові навички у найкращій системі пошуку – Google. З переважною більшістю незрозумілих помилок та інших моментів хтось уже стикався. І ви будете неабияк здивовані, погугливши та побачивши кількість людей, яким знайома аналогічна проблема, і які вже отримали вичерпні відповіді, придатні для використання в роботі. Виходячи з цього, нерідко можна почути від колеги відповідь на якесь питання - "Погугли". На цю відповідь не варто ображатися, адже все ж таки ваш колега не особистий вчитель, який повинен донести всі тонкощі вашої галузі роботи. У такому наставництві вам допоможуть безмежні простори інтернету. Іноді програміста ще називаютьлюдина з чорним поясом по google пошуку . Тому при “затику” насамперед гуглимо проблему, і якщо рішення знайдено не було (рідко, але буває), тоді вже починаємо запитувати колег. Запитувати їх відразу варто швидше не при якомусь затику чи незрозумілій помилці, а при виборі підходу для вирішення якогось завдання. Адже вони можуть бачити далі за ваше і відразу сказати, чим той чи інший підхід може обернутися в довгій перспективі.

3. Сліпий копіпаст

Але гуглеж проблеми і відповідно її вирішення має і своє підводне каміння. Наприклад, сліпий копіпаст. Це зазвичай відбувається, коли ви знаходите схожу проблему (але можливо, не точно таку) і під нею, наприклад, на StackOverFlow рішення. Ви берете це рішення, копіюєте та вставляєте собі, без зайвих заглиблень у подробиці. А потім ви чи ваші колеги за проектом виявляєте якісь дивні баги чи неправильну поведінку вашого функціоналу. І одразу ніхто й не здогадується, звідки ростуть ноги. Потім, звичайно, місце з цим кодом буде знайдено, і вас точно не похвалять за це рішення. Тому, коли ви знайшли готове рішення на StackOverFlow (або ще десь), в першу чергу ви повинні докладно розібрати його, що як і навіщо. Можливо, погуглити цей функціонал і переглянути документацію до нього. І лише після цього впроваджувати у свій проект.

4. Кидати неправильне рішення

При написанні рішення іноді буває, що воно постійно ускладнюється, і врешті-решт заходить у глухий кут. І ви намагаєтеся все більше його ускладнити, щоб якимось чином вирішити це завдання саме із застосуванням цього підходу замість того, щоб спробувати пошукати іншу, більш робочу альтернативу. Можливо, вам просто шкода витрачених вами сил і часу і тому ви вирішуєте: хоч би що там було — не здаватися, а вирішити завдання саме цим шляхом. Це не зовсім правильний підхід. Принаймні у програмуванні. Чим раніше ви спробуєте інший підхід, тим більше часу ви заощадите. Тому не бійтеся експериментувати та пробувати інші підходи, незважаючи на кількість часу, вкладену в цей. Тим більше, це будуть окуляри в скарбничку вашого досвіду, тому що ви спробуєте кілька підходів і краще вивчите цю область.

5. Страх ставити питання про поточне завдання

Робота на проекті, як правило, зводиться до виконання деяких завдань (Tasks). Наприклад, у Jira. І ці завдання не завжди докладно та доступно описують. Їх пишуть як правило тимліди, і це теж люди, якщо що. Вони теж можуть щось забути дописати або не врахувати, що ви мало знайомі з тим чи іншим функціоналом. Ну або у вас немає якихось доступів за проектом (наприклад, доступ до Бази даних, сервера логів і так далі). І ось, отримавши завдання, повивчивши її вже більш ніж пару годин, ви так само сидите і дивно дивіться на екран. І замість того, щоб продовжувати безрезультатно розумітися на цьому, вам варто почати ставити навідні/уточнюючі питання творцю даної таски. Скажімо, у додатку, який ви використовуєте для комунікації в команді (наприклад, Microsoft Teams) або безпосередньо коментарем під даною тягою. З одного боку, якщо ви напишете питання в особу, швидше за все відповідь буде швидшою, оскільки людина побачить питання відразу. З іншого ж боку, ставлячи запитання у Джирі, у вас є свідчення того, що ви щось робите, а саме розбираєте завдання. Є спосіб прискорити цей процес: поставити запитання коментом у Джирі та в личку скинути посилання на цей коментар із проханням подивитися.

6. Занадто великі надії на тимліда

Знову ж таки, це зворотний бік попереднього пункту. Тімлід - це людина, яка є головною в якійсь команді розробників. Зазвичай більшість часу такого члена команди йде на різноманітних комунікації. І при цьому він ще й пише код, щоб не забувати, що це взагалі таке. Ну, як ви зрозуміли, це дуже зайнятий персонаж. І зайве смикання по кожному чхові явно його не потішить. Уявіть, якщо кожен член команди його засипатиме купою питань. Так можна і збожеволіти, чи не так? І не буде дивно, що при багатьох питаннях з вашого боку він буде вам довго відповідати. Що ж можна зробити, щоб скоротити кількість питань тимлід:

• Більш глибоко вивчити документацію цього проекту, щоб зменшити кількість білих плям.
• Запитувати решту членів команди. Цілком можливо, вони знайомі з цим функціоналом не менше за лід, а то й більше, адже швидше за все той функціонал писав хтось із них.

Як варіант, в IDE можна дивитися інструкції: хто і коли востаннє змінював код у певному рядку. Таким чином ми і з'ясуємо, кому найбільш правильно буде поставити це питання. Як ви вже напевно зрозуміли, у питаннях тимліду, як і в питаннях колегам, треба намагатися тримати золоту середину — не боятися ставити запитання, але й не діставати їх надмірною кількістю.

7. Побоювання code review

Code reviewабо огляд коду - це такий собі етап перед заливкою коду в загальну програму (у спільну гілку, наприклад - master або dev). Дану перевірку проводить розробник, який не має відношення до цієї таски, який може свіжим поглядом виявити помилки, неточності або недоробки в code style, які залишабося непоміченими в початковій фазі розробки. Якщо зауваження є, вони залишаються коментарями до певних ділянок коду. У такому разі розробник, який виконував цю таску, повинен виправити помилки згідно з рев'ю (або обговорити свої рішення з ревьюєром, можливо, переконавши його у правильності свого рішення). Після знову відправити на ревью, і так доти, поки у ревьюера не буде зауважень. Рев'юєр служить "фільтром" перед заливкою коду. Так от, багато програмістів-початківців сприймають code review як критику і осуд. Вони її не цінують та бояться, і це неправильно. Саме код ревью дозволяє нам покращувати наш код. Адже ми отримуємо важливу інформацію про те, що ми робимо не так і на що варто звернути увагу. Необхідно дивитися на кожне код ревью як на частину навчання, на те, що може допомогти краще. Коли людина залишає коментар до вашого коду, він ділиться з вами своїм досвідом, своїми best practices. Як на мене, не можна стати добрим програмістом без отримання code review. Тому що ти і не знаєш, наскільки твій код добрий і чи є там косяки з погляду досвідченої людини збоку. що може допомогти стати кращим. Коли людина залишає коментар до вашого коду, він ділиться з вами своїм досвідом, своїми best practices. Як на мене, не можна стати добрим програмістом без отримання code review. Тому що ти і не знаєш, наскільки твій код добрий і чи є там косяки з погляду досвідченої людини збоку. що може допомогти стати кращим. Коли людина залишає коментар до вашого коду, він ділиться з вами своїм досвідом, своїми best practices. Як на мене, не можна стати добрим програмістом без отримання code review. Тому що ти і не знаєш, наскільки твій код добрий і чи є там косяки з погляду досвідченої людини збоку.

8. Схильність до хитромудрих рішень

Часто різні завдання/проблеми можуть мати кілька різних шляхів вирішення. І з усього доступного безлічі рішень новачки зазвичай застосовують найбільш складні і "розумні". І адже правда: якщо програміст-початківець буквально вчора вивчив безліч різних алгоритмів, патернів, структур даних, то в нього руки так і сверблять впровадити якийсь із них. Та й хочеться, сказати б, заявити про себе. Повірте, я сам був таким і знаю, про що говорю :) Була в мене ситуація, коли я довго писав один функціонал, який вийшов дуже складним. Потім його переписав розробник рівня Senior+. Звичайно, мені стало цікаво подивитися, що і як він переробив. Переглянув його реалізацію і здивувався, наскільки вона полегшала. Та й коду стало менше разу так у три. І при цьому тести на цей функціонал не змінабося та не впали! Тобто, загальна логіка залишилася все та ж. З цього я зробив для себе висновок, що:найгеніальніші рішення завжди прості . Після цього розуміння писати код стало набагато простіше, і він відчутно став більш високорівневим. Ну тоді коли варто тоді застосовувати патерни і алгоритми, запитаєте ви? Тоді, коли застосування їх і буде найпростішим і найкомпактнішим способом.

9. Винахід велосипедів

Це поняття також відоме як винахід колеса. Суть його полягає в тому, що розробник реалізує власне рішення для завдання, для якого вже існують рішення, причому у рази краще, ніж придумане програмістом. Як правило, винахід власного велосипеда призведе до втрати часу і зниження ефективності роботи розробника, адже рішення можна знайти далеко не краще, ну або взагалі не знайти його. При цьому відкидати можливість самостійного рішення також не можна. Програміст повинен правильно орієнтуватися у завданнях, які можуть постати перед ним, щоб грамотно та своєчасно їх вирішити, використовуючи готові рішення чи винаходячи власні. З одного боку, в університетах і на курсах нас засипають різноманітними завданнями, які повинні допомогти нам набити руку на створенні велосипедів. Але це лише на перший погляд. Насправді метою цього є розвиток алгоритмічного мислення та глибшого освоєння синтаксису мови. А ще такі завдання допомагають краще зрозуміти алгоритми/структури, і при потребі — дати навички реалізації своїх розширених аналогів (але це буває потрібно дуже рідко). У реальному житті в переважній більшості випадків не потрібно вигадувати своє колесо, оскільки вже давно існують аналоги, які задовольняють наші потреби. Можливо, через свій досвід ви не знатимете про існування необхідних вам реалізацій того чи іншого функціоналу. Тут потрібно скористатися першим пунктом цієї статті, а саме попросити допомогу у досвідченіших колег. Вони зможуть направити вас (наприклад, порадити, у якому напрямку гуглити) або підказати конкретну реалізацію (деяку бібліотеку).

10. Не писати тести

Усі новачки не люблять писати тести. Та що там новачки: не новачки теж не люблять писати тести, але краще розуміють, навіщо це потрібно. Коли ти зовсім зелений, ти гадаєш: а навіщо їх писати? Воно все працює, і помилок бути не може. Але як переконатись, що ваші зміни не зламали щось в іншій частині системи? Ваші колеги не оцінять, якщо ви заллєте зміни, які руйнують більше, ніж приносять користь. Тут і приходять на допомогу випробування. Чим більше програма покрита тестами, тим краще (також називається відсоток покриття). Якщо програма добре покрита тестами, запустивши їх усі ви можете виявити місця, які можна зламати вашими змінами. І як я говорив у прикладі вище, при рефакторинг функціоналу тести так і не впали, а все тому, що загальна логіка не змінилася. Отже, тести також можуть показувати, чи змінилася логіка певного функціонала чи ні. Так що навіть якщо ви не любите писати тести, безперечна користь від них є, і вони стоять витраченого на них часу.

11. Надмірне коментування

Багато розробників страждають на перфекціонізм, і новачки в цьому випадку не виняток. Ось тільки побочка цього прагнення іноді полягає в тому, що вони починають коментувати всіх та все. Навіть те, що не потрібно, бо так очевидно:

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

Не всі програмісти-початківці відразу усвідомлюють, що коментування коду — це не завжди є добро, адже код вийде куди більш нагромадженим і складно читаним. А якщо код змінабо, а коментар до нього немає? Виходить, він нас обманюватиме і тільки плутатиме. До чого тоді взагалі такий коментар? Зазвичай добре написаний код не потребує коментування , тому що в ньому і так все очевидно і читаємо. Якщо ж ви пишете комент, значить, ви вже запороли читання коду і намагаєтеся хоч якось згладити ситуацію. Найкращим підходом спочатку писати код, який не доведеться доповнювати коментарями. Також не міг не згадати правильні іменування методів, змінних та класів, а саме — правило якого я сам і дотримуюсь: Найкращий коментар - це відсутність коментаря, а замість нього - правильні іменування , які зрозуміло описують той чи інший функціонал у вашому додатку.

12. Погані іменування

Часто новачки фальшивлять із найменуваннями класів, змінних, методів тощо. буд. Наприклад, коли створюють клас, ім'я якого не описує його призначення. Або створюється змінна з коротким ім'ям, щось на зразок x , і коли створюються ще дві змінні з іменами n і y , згадати, за що відповідає xстає дуже важко. У таких випадках доводиться ретельно вдумуватись у код і під мікроскопом (можливо, з використанням дебагера), вивчати цей функціонал, щоб просто зрозуміти, що там таке відбувається. Тут нам на допомогу і приходять правильні назви в коді, які я згадав вище. Правильні назви покращують читабельність коду, відповідно заощаджуючи час на ознайомлення, адже набагато простіше використовувати метод, у якому назва описує його функціонал. У коді все складається з назв (змінні, методи, класи, об'єкти, файли і т. д.), цей пункт стає дуже важливим при створенні правильного, чистого коду. Варто пам'ятати, що ім'я має передавати сенс: чому, наприклад, змінна існує, що вона робить і як використовується. І ще не раз зазначу, що найкращим коментарем для опису змінної є її правильне ім'я. Для більш глибокого вивчення коментарів і правильних імен раджу почитати класику, що не старіє:”Чистий код. Створення, аналіз та рефакторинг”, Роберт Мартін . На цій ноті перша частина цієї статті (роздумів) добігла кінця. Далі буде…