5 ошибок, после которых ваш код придётся переписать

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

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

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

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

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

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

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

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

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

Абы какой код

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В чём ошибка. Столкнулись с проблемой

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

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

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

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

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

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

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

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

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

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

План успеха:

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

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

🐈🐈🐈

«Доктайп» — журнал о фронтенде. Читайте, слушайте и учитесь с нами.