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

Всім знову привіт! Ми продовжуємо розглядати проблеми, з якими може зіткнутися молодий та незміцнілий програміст на своїй першій роботі. З першою частиною можна ознайомитися ось тут . Продовжуємо:

13. Недотримання стилю написання коду

На проектах зазвичай підтримується один стиль написання коду. Тобто, різні розробники дотримуються якихось писаних чи неписаних правил, щоб їх код не відрізнявся від інших. Не потрібно намагатися якось виділитися за допомогою своєрідного стилю написання коду: плюсиків це на ваш рахунок не додасть. Якщо ви новенький на проекті, вам варто відразу дізнатися, чи є якась документація, що описує загальний підхід до стилю написання коду. Можливо, є деякі файли стилю під конкретно ваш проект, які потрібно попросити скинути та імпортувати в середовище, в якому ви працюєте (наприклад IntelliJ IDEA), щоб воно вже могло своєю чергою робити підказки згідно з заданим файлом стилю. Наприклад, в стилі буде прописано використання модифікатора final скрізь, де це можливо, і IntelliJ IDEA виділятиме жовтим змінні,

14. Падати духом через помилки

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

15. Відсутність чіткого плану

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

16. Переробка

Мабуть, кожен новачок думає, що якщо він працюватиме до ночі, він почне давати собі раду краще зі своїми завданнями і швидше, так би мовити, в'їде у все. Я також раніше так думав, але зараз це не так. Я помітив такий момент: настає якийсь час, яка межа, переступивши за яку ти вже перестаєш адекватно мислити. Ти починаєш неабияк тупити, залипати і робити по годині ті речі, які міг би зробити за 10 хвабон на свіжу голову. І як правило, після перетину цієї риси втоми ти втикаєшся в якусь проблему, яка здається непереборною. Але прийшовши вранці на роботу ти її вирішуєш миттєво. Так ось, коли ви відчуваєте, що досягли цієї точки, не сидите допізна, а просто йдіть додому і добре відпочиньте. Адже якщо просидіти до пізньої ночі, особливо видатних результатів за цей годинник мук ви вже не досягнете, але при цьому ризикуєте погано (мало) відпочити перед наступним робочим днем ​​і запороть ще його. Подумайте про здоров'я: чи варто так на початку своєї кар'єри його підривати? Я думаю що ні. Нині дорого хворіти. Також подумайте про роботодавця. Переробляючи, ви робите гірше не лише собі, а й йому. Кому потрібен співробітник, який вічно не виспався, який від втоми не може реалізувати найпростіше сортування? Так, безсумнівно, бувають моменти, коли дедлайн горить, все пішло не так і це моє улюблене — «треба було ще вчора». Але, як правило, такі ситуації рідкість, та й після них потрібно сісти і ретельно обдумати, як це взагалі могло вийти і як цього уникнути у своєму майбутньому. що ні. Нині дорого хворіти. Також подумайте про роботодавця. Переробляючи, ви робите гірше не лише собі, а й йому. Кому потрібен співробітник, який вічно не виспався, який від втоми не може реалізувати найпростіше сортування? Так, безсумнівно, бувають моменти, коли дедлайн горить, все пішло не так і це моє улюблене — «треба було ще вчора». Але, як правило, такі ситуації рідкість, та й після них потрібно сісти і ретельно обдумати, як це взагалі могло вийти і як цього уникнути у своєму майбутньому. що ні. Нині дорого хворіти. Також подумайте про роботодавця. Переробляючи, ви робите гірше не лише собі, а й йому. Кому потрібен співробітник, який вічно не виспався, який від втоми не може реалізувати найпростіше сортування? Так, безсумнівно, бувають моменти, коли дедлайн горить, все пішло не так і це моє улюблене — «треба було ще вчора». Але, як правило, такі ситуації рідкість, та й після них потрібно сісти і ретельно обдумати, як це взагалі могло вийти і як цього уникнути у своєму майбутньому.

17. Нехтування англійською

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

18. Погоня за модними технологіями

Починаючи свій шлях, розробники часто намагаються наздогнати освоєння новітніх технологій. Чи правильно це? З одного боку, так: новітні технології, проекти… Але чи варто робити це основним пріоритетом? Можливо, краще натиснути на "класичний набір" фахівця вашої області? Адже нове — це звичайно добре, але треба не забувати про основні технології вашого напряму. А вже потім, після того як ви трохи обростете досвідом і глибокими знаннями основ, можна пробувати щось нове. Врахуйте ще, нові технології мають перевагу в одних нюансах, але при цьому програють в інших. І доти, поки у розробника-початківця не буде розуміння цих особливостей, краще використовувати перевірені часом рішення. Наприклад, якщо програміст розробляє додаток, який взаємодіє з деякими даними, то не варто поспішати використовувати останнє NoSQL-рішення тільки тому, що це в моді. Швидше за все підійде і звичайна SQL база даних (MySQL, PostrgreSQL..), яка давно перевірена часом, має докладну документацію та вирішення всіх проблем на StackOverFlow :)

19. Вивчення безлічі технологій чи кількох мов відразу

Вище ми говорабо про освоєння модних технологій новачками. А як справи з вивченням безлічі технологій чи кількох мов відразу? Ви явно чули про програмістів, які знають більше однієї мови програмування та володіють безліччю технологій. Але я поспішу зауважити, що ці люди далеко не новачки у програмуванні. Це люди з великою кількістю років досвіду за плечима. Вони вже встигли стати майстрами у своїй початковій технології і пішли далі і далі. Що ж до новачків, які намагаються освоїти все і відразу, тут чудово підходить прислів'я: "за двома зайцями поженешся - жодного не спіймаєш". Наслідком може бути те, що ви жодний напрямок не освоїте добре, а лише по вершках пробіжитесь. Більш затребуваним буде фахівець, який глибоко знає одну мову, ніж усі, але трохи. Тому якщо ви хочете знати безліч мов та технологій, до цього потрібно підходити з розумом. Для початку у вас має бути базова, основна мова, яку потрібно глибоко вивчити. І лише потім, відштовхуючись від нього, вивчати додаткові напрямки. Наприклад, стати гуру по Java, потім вивчити Python як допоміжну мову, потім можна й вивчити щось із фронтової частини react/angular. У такому випадку ці технології не взаємозамінні, як, наприклад, C# і Java, а доповнюють один одного, що розширюють ваші кар'єрні можливості. Але знову ж таки повторюся: не варто намагатися вчити все відразу, потрібно послідовно. Так би мовити, ловити зайців по одному. вивчати додаткові напрямки. Наприклад, стати гуру по Java, потім вивчити Python як допоміжну мову, потім можна й вивчити щось із фронтової частини react/angular. У такому випадку ці технології не взаємозамінні, як, наприклад, C# і Java, а доповнюють один одного, що розширюють ваші кар'єрні можливості. Але знову ж таки повторюся: не варто намагатися вчити все відразу, потрібно послідовно. Так би мовити, ловити зайців по одному. вивчати додаткові напрямки. Наприклад, стати гуру по Java, потім вивчити Python як допоміжну мову, потім можна й вивчити щось із фронтової частини react/angular. У такому випадку ці технології не взаємозамінні, як, наприклад, C# і Java, а доповнюють один одного, що розширюють ваші кар'єрні можливості. Але знову ж таки повторюся: не варто намагатися вчити все відразу, потрібно послідовно. Так би мовити, ловити зайців по одному.

20. Неправильно поставлені цілі

Як ви ставите собі мету? Стати крутим розробником? Запам'ятайте раз і назавжди: цілі потрібно ставити фізичні, або іншими словами досяжні. Про що говорю? Наприклад, ви ставите собі за мету: хочу стати багатим. І як ви зрозумієте, що ви вже досягли цієї мети? Або як ви вимірюєте, наскільки ви стали до неї ближчими? Ну а якщо ви поставите мету "хочу заробити мільйон" - це вже трохи зрозуміліше, чи не так? Заробивши 10 тисяч, ви станете на 10 тисяч ближчими до своєї мети, і вам залишиться 990 тисяч. Попереду чимало, але ви можете помацати свій прогрес і зрозуміти, де знаходиться фінішна риса вашої мети, і це вам і не дасть опустити руки. Що стосується кар'єри, як щодо того, щоб поставити собі більш відчутну мету? Наприклад: хочу стати тимлідом. Або сеньйором. Ну чи архітектором, зрештою. Ну а велике завдання потрібно поділити на маленькі підзавдання. Ви ж не станете тимлідом ось так із порога кар'єри. Ставте терміни, якщо це можливо та доречно, та фокусуйтеся на поточному етапі.

1. Якщо ми говоримо про становлення сеньйором , то першою метою буде знайти роботу джуніором або стажування в компанію.
2. Далі як цілі можна ставити поглиблення знань у певних технологіях. Java - підготовка до сертифікації Oracle першого рівня. Ставимо собі термін на підготовку та йдемо до мети.
3. Після, наприклад, можна поставити собі за мету підтягнути англійську на один рівень (скажімо, з B1 до B2). Складаємо план підготовки, плануємо час та рухаємося до мети.

І так, крок за кроком (паралельно отримуючи досвід у розробці) ми і можемо досягти нашої кінцевої мети.

21. Теорія без практики

Незаперечний факт, що вивчення нових технологій, поглиблення у вже вивчені — це те, що робить нас кращими як професіонали у своїй галузі. Але на початку шляху розробники рідко усвідомлюють, що поглинання технічних книг одну за одною не має величезної користі, якщо нові знання не будуть випробувані на практиці. Я сам не раз на це натикався. Бувало так, що вб'єш купу часу на якусь книгу, але при цьому не практикуєш нічого з неї, і майже всі новонабуті знання забуваються: залишається лише загальний невиразний спогад про те, як все приблизно працює. Підсумок – купа втраченого часу без відчутного результату. Навіщо нам марнувати час даремно? Життя не нескінченна. Тому коли вивчаєте нову технологію, не зациклюйтесь на теорії: паралельно пишіть наведені приклади, експериментуйте з новою технологією, і тільки так у вас щось закріпиться у голові. Так, швидкість споживання нових матеріалів неабияк просяде, але при цьому якість засвоєння зросте в рази. Ну і якщо освоїти одну технологію добре, наступні засвоюватимуться вже простіше (як і з вивченням мов).

22. Зайвий перфекціонізм

Більшість розробників — перфекціоністи: люди, які прагнуть ідеальності. Отже, їх код теж має бути ідеальним. І ось код уже написаний, протестований, відредагований і начебто час уже заливати його в загальну гілку. Але творцеві все одно ще код не подобається, і він починає його і так, і так перекручувати, витрачаючи на це багато часу. Ну, а час у цьому випадку — гроші клієнта. Початківці програмісти більше схильні до цього прагнення до досконалості. Досвідчені розробники вже звикли до почуття, що код ідеальним ніколи не буде, і що потрібно намагатися написати його краще, але при цьому не перегинати в прагненні наблизитися до ідеалу. Так, що запам'ятайте: потрібно навчитися тримати золоту середину, і не якось нашвидкуруч, але намагатися відтворити Мону Лізу в коді.

23. Не думати про архітектуру

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

24. Синдром самозванця

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

25. Рідко робити коміти

Запам'ятайте: комміти потрібно робити часто! Ну, не кожні півгодини, але якщо у вас стоїть завдання реалізувати функціонал, який ви пишете тиждень, то це має бути не один коміт у п'ятницю ввечері, а, наприклад, п'ять коммітів. Практично будь-яке велике завдання можна умовно розбити на менші завдання. І ось виконання цих завдань менше ви і комітіте. Так, і не забувайте ці комміти одразу заливати на віддалений сервер. Інакше ви можете весь тиждень робити комміти, і, наприклад, у п'ятницю в обід щось трапляється з вашим комп'ютером, і ось цілий тиждень нанівець! А якщо ви робабо комміти на віддалений сервер, просто з іншого комп'ютера стягнете гілку з останнім коммітом і продовжите роботу. І ще одне: не викладайте новий функціонал у працюючий продакшн сервер у п'ятницю ввечері. Просто повірте. Воно вам не потрібне. Це загрожує тим, що можуть вилізти несподівані помилки, за фіксингом яких ви проведете свої вихідні. А це не весело. На вихідні треба відпочивати. На цьому, мабуть, сьогодні все. PS Остання порада: пишіть багато коду. PSS Пишіть БЕЗУМНО багато коду, адже тільки так можна набратися такого необхідного досвіду.