10 правил як швидко вирости з Junior до Middle developer

Усі статті, обговорення, новини для початківців — в одному місці. Підписуйтеся на телеграм-канал!

Напевно майже кожен Junior developer має бажання швидше стати Middle developer. Початківець програміст зазвичай намагається виконати побільше поставлених задач за найменшу кількість часу вважаючи при цьому що це і буде показником ефективності його роботи. Задачу програміст зазвичай отримує уже оцінену в story points і ця оцінка може здаватися сильно завищеною. Отримуючи подібну задачу програміст може виконати її в кілька разів швидше оціненого часу і думати що це ж круто що він так зміг. Проте насправді все не так просто як здається, кожна навіть найпростіша задача має певний вплив на систему що розробляється, а особливо якщо ця система складна. Тому перше правило програміста початківця — намагайтеся аналізувати вплив змін які зроблені в рамках задачі на систему, а не просто виконуйте задачу.

Коли Junior програміста кидають на який складний проект, то задачі які йому дають на початку максимально деталізовані і зрозумілі. Деякі програмісти можуть до цього настільки звикнути, що просто виконуватимуть поставлені задачі і не сильно вникатимуть для чого робиться поставлена задача і які зміни\новий функціонал вона принесе в систему. Ця звичка може перерости в те що програміст не сильно прийматиме участь в обговорені задач на грумінгу і в подальшій оцінці задач на планінг покері. Програмісту початківцю може здаватися що подібні мітинги тільки забирають час, тому він може намагатися навіть паралельно з мітингом пробувати реалізовувати задачі, але це є величезною помилкою. Тому що навіть якесь невелике питання яке може здаватися дурнуватим може спровокувати дискусію, яка кардинально змінить спосіб реалізації задачі, який планувався спочатку. Тому друге правило — намагайтеся приймати активну участь у запланованих мітингах, задавайте питання, а ще краще підготуйтеся до мітингів заздалегідь: проаналізуйте сторі які будуть обговорюватися, спробуйте їх попередньо оцінити, обдумайте можливі способи реалізації.

Іноді задача може здаватися настільки простою що програміст початківець може подумати, що ж тут тестувати, якщо і так все має працювати. Подібних думок не варто допускати взагалі, навіть більше — тестувати задачу потрібно уважно і перевіряти функціонал під відповідними користувачами (персони яких вказані в юзер сторі). Для великих сторі зручним варіантом може бути копіювання опису сторі наприклад в блокнот і видалення слів\речень після того як відповідний функціонал було протестовано програмістом — так Ви точно нічого не забудете і не пропустите.

В бажанні пошвидше зробити задачу Junior програміст може не приділяти належну увагу юніт тестам пишучи їх з недостатнім покриттям логіки, таким чином частина функціоналу упускається що понижує якість написаного коду. Ба більше, код для покриття певної логіки з часом змінюється і правильні повноцінно написані юніт тести допомагають виявити помилку як при рефакторінгу коду так і тоді коли спосіб реалізації задачі в силу якихось причин змінюється. Тому четверте правило — юніт тести варто писати якісно навіть якщо на їх написання буде витрачено більше часу чим на реалізацію самої задачі.

Код програміста початківця змінюється з часом і це добре, так як навики покращуються і код відповідно теж швидше за все покращується. Тобто через певний період часу Ви можете не впізнати свій код або Вам здаватиметься що як я міг написати подібний код. Тому виберіть свій власний стиль написання коду або використовуйте вимоги до коду які прийняті у вас на проекті і слідуйте цьому стилю постійно. Код який написаний нашвидкоруч, невідформатований і який не відповідає одному і тому ж стилю потім і Вам самим буде складно читати.

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

Програміст який пише код має чітко розуміти за що відповідає і що робить той чи інший рядок коду. При написанні коду і при його рев’ю такі знання допомагають відразу проаналізувати якість коду і виправити його коли виникають сумніви щодо необхідності того чи іншого рядка коду. Тобто подумки програміст може діяти як комп’ютер і на певному прикладі проходити рядок за рядком і переконуватися що результат виконання коду саме той який очікується. Тому сьоме правило — пишіть код обдумуючи кожен рядок коду і у разі виникнення сумнівів скористайтеся довідкою щодо певного методу або витратьте додатковий час для того щоб впевнитися що результат виконання рядка коду саме той який Ви очікуєте.

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

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

І напевно найбільш важливе правило наприкінці — пам’ятайте що на фікс багу який був виявлений в продакшні витрачається в рази більше часу ніж якби він був виявлений на етапі розробки, так як це вимагає додаткової розробки, деплоймента і тестування в різних тестових середовищах. Тому передавайте задачу в тестування тільки тоді коли ви на всі 100% впевнені що реалізували її відповідно до всіх вимог описаних в задачі.