5 помилок розробників-початківців

19 вересня
Петро Мачларц, .NET-розробник, DataArt, Люблін
5 помилок розробників-початківців
Розробники роблять помилки, притому часто. Я пишу код вже 5 років, 3 роки займаюся комерційної розробкою.

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

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

Помилка № 1. Не ставити запитань

Отримавши завдання, ви хочете негайно заглибитись у написання коду, зробити перший комміт і скоріше продемонструвати свою ефективність. Такий період пройшли багато програмістів, зокрема і я.

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

Ставити запитання, натрапивши на перешкоду, важливо та потрібно. Чим раніше, тим краще.

Помилка № 2. Ігнорувати загальну картину

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

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

Помилка № 3. Довіряти своїм припущенням

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

Ось лише частина неправильних припущень, з якими мені доводилося стикатись:

  • системою будуть користуватися в одному часовому поясі;
  • сайт не буде відображатись у більш низькій/високій роздільності;
  • користувач завжди матиме доступ до інтернету;
  • два користувачі не будуть одночасно редагувати одні й ті самі дані;
  • користувач не буде використовувати AdBlock.

Ви можете знайти набагато більше подібних припущень, просто набравши в пошуку “помилкові припущення програмістів”.

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

Помилка № 4. Не обґрунтовувати рішення

Іноді в пошуках вирішення конкретної проблеми ви можете знайти відповідний фрагмент коду на GitHub або StackOverflow. Причому такий, який можна просто вставити у власний код і радіти, що система функціонує без збоїв. Однак цього недостатньо — ви повинні вміти пояснити, чому це рішення працює. Копіювання коду наосліп може заощадити час, але потім поставити вас у настільки незручне становище, що ця економія не буде достатньою компенсацією. Я не раз був свідком таких ситуацій при перевірках.

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

Помилка № 5. Уникати відповідальності

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

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

Що потрібно робити

Давайте ще раз пройдемося по пунктах і сформулюємо прості правила?

  1. Ставте запитання. Здатність до самостійного вирішення задачі є однією з основних навичок розробника, але важливо знати, коли варто звернутися за допомогою.
  2. Завжди пам'ятайте про загальну картину. Вчіться вникати в суть проблеми та оцінювати свою роботу з різних точок зору.
  3. Перевіряйте свої припущення.
  4. Робіть усвідомлений вибір і завжди будьте готові обґрунтувати свої рішення.
  5. Беріть на себе відповідальність. Будьте вірні своєму слову та не бійтеся труднощів.