Ошибки случаются даже у супер-опытных разработчиков, но лучше всё равно знать, где и какими они бывают. Меня зовут Иван, я работаю в финтех-компании и уже восемь лет пишу код. Сейчас всё объясню.

Не разобраться в задаче

⚠️ В чём ошибка. Если браться за работу в спешке и сразу начинать писать код, очень легко упустить важные детали или вообще неправильно понять смысл задачи и сделать не то что нужно. В результате задачу придётся переделывать и вы потеряете много времени впустую.

😞 Что самое плохое может случиться. Придётся все переделать.

🔥 Как правильно. Разберитесь в задаче, а потом делайте.

Как это сделать:

  • Внимательно прочитайте задачу, поковыряйте макет.
  • Разберитесь, кому нужна задача и для чего её делать.
  • Постарайтесь понять контекст и посмотрите на задачу как пользователь — будет ли вам хорошо, если такая фича появится?
  • Если после предыдущих шагов остались вопросы, задайте их коллегам.

То есть путь такой:

👉 Получили задачу → Внимательно прочитали → Уточнили непонятное.

Абы какой код

⚠️ В чём ошибка. Делать по принципу «Лишь бы работало» и не обращать внимания на качество кода, имена переменных и размер модулей. При этом основную часть времени разработчики не пишут свой код, а разбираются в чужом. Поэтому понятный код — экономия времени.

Но новички частенько делают тяп-ляп, лишь бы работало. Получается так:

Мем. Разработчик сначала доволен, но потом недоволен написанным кодом

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

👉 Лишь бы работало — тупиковый путь.

😞 Что самое плохое случится. Коллеги потратят много времени, чтобы разобраться, да и код будет дорого поддерживать. И придётся всё переписать.

🔥 Как правильно. Поймите, с какими данными вы работаете, что должно получиться в итоге, какие модули вы для этого создадите или будете менять, какие функции и классы напишете.

Задайте себе два вопроса.

  • Если я вернусь к этому коду через полгода, пойму ли я, что тут написано?
  • Понял бы я этот код, если бы его написал не я?

Если на оба вопроса ответ «нет», то есть ещё несколько проверенных практик:

  • Пишите комментарии к коду, если у вас в команде это принято.
  • Используйте нормальный нейминг, а не a или schetchik.
  • Разбивайте большие функции на несколько с понятными названиями.
  • Подключайте линтеры.

Нет автотестов

⚠️ В чём ошибка. Не писать автоматические тесты к коду, потому что зачем, если всё горит и можно проверить вручную?

Три программиста переживают из-за скорого дедлайна

😞 Что самое плохое случится. Кажется, что тесты тратят время впустую. Но это не так, особенно в большом продукте. Код без тестов быстрее приведёт к ошибкам, его будет сложнее и дороже поддерживать и дорабатывать. А потом всё равно придётся все переписать.

Дело в том, что добавление фичей или исправление багов без тестов несёт риск «регрессии».

👉 Регрессия — сделали новое, но сломалось старое.

Регрессия — бесконечный источник задержек, переработок и стресса, а рефакторинг (то есть переделка) такого кода напоминает бег в лесу с завязанными глазами.

🔥 Как правильно. Полюбите тесты.

  • Поймите, что тестировать, как работают тесты в целом и какие они бывают.
  • Разберитесь, как пишут тесты у вас в компании.

Дальше тесты станут частью работы, но ошибок будет меньше, проекты станут закрываться быстрее, а продукт будет работать.

Вопросы раньше времени

⚠️ В чём ошибка. Столкнулись с проблемой, но даже не попытались решить её самостоятельно.

😞 Что самое плохое случится. Коллеги вам помогут, если попросите. Но всегда стоит хотя бы попробовать ковырнуть код с ошибкой — это критически важно для обучения. Ну и в любом случае от вас будут ждать роста и самостоятельности, так что лучше прийти к этому побыстрее.

🔥 Как правильно. Встретили проблему — соберите информацию, сделайте хоть что-то, подумайте над тем, что получилось, а только потом просите помощи. Обращаясь за помощью к другим разработчикам, расскажите:

  1. Контекст — то есть то, над чем вы работаете.
  2. В чем проблема (происходит не то, что вы ожидаете, возникает ошибка и т. п.)
  3. Что вы попробовали,
  4. Что из этого получилось,
  5. Какой у вас вопрос.

Иногда после работы над проблемой полезно записать перечисленные выше пункты. Решение может придти ещё до того, как вы обратитесь за помощью. 🦆

Ни о чём не спрашивать в принципе

В чём ошибка. Не задавать вопросы, потому что коллеги подумают, что вы ничего не умеете.

Иногда новички пытаются решить задачу любой ценой, даже если у них и правда недостаточно знаний. Но один вовремя заданный вопрос может сэкономить массу времени всей команде.

😞 Что самое плохое случится. Новички долго сидят над одной задачей, пишут плохой код в последний момент и всё равно срывают сроки. А плохой код придётся переписать.

🔥 Как правильно. Задавайте вопросы, когда знакомитесь с задачей и вам что-то не понятно (см. пункт 1). Если вам не до конца понятно, для чего вообще делать эту задачу, спросите того, кто её поставил. Если исправляете и дорабатываете чужой код, но не понимаете, как он работает — спросите у автора, если он ещё не уволился.

Золотое правило любой работы:

👉 Если сомневаетесь — спросите.

План успеха:

  1. Дочитывайте задачи.
  2. Не пишите абы как.
  3. Полюбите тесты.
  4. Сделайте что-то с ошибкой.
  5. Если не получается — попросите помощи.

На этом всё, пора работать.

🐈🐈🐈