10 самых частых ошибок разработчиков

10 самых частых ошибок разработчиков
На чтение
22 мин.
Просмотров
87
Дата обновления
25.10.2024

Человеку свойственно ошибаться. День за днём все мы совершаем промашки. И на работе тоже.

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

И это хорошо. Потому что ошибки ценны. Конечно, если мы извлекаем из них уроки — и растём профессионально. Как говорила Элеонора Рузвельт, жизнь слишком коротка, чтобы тратить её на повторение чужих ошибок. Так что лучше на них учиться.

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

[spacing size=”15″]

Ошибка 1. Неверно сохранять изменения проекта

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

Помните об этом и будьте внимательны.

[spacing size=”15″]

[spacing size=”20″]

Ошибка 2. Путать, что нужно коммитить

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

Первое обычно делают поспешные или небрежные разработчики. Например, я со счёта сбился, сколько раз видел в репозиториях файлы формата IDE. Бездумное добавление к коммиту всех файлов подряд ничем хорошим не кончится.

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

Чаще всего из-за пропавшего файла что-нибудь пойдёт не так, а что конкретно — зависит от файла. Например, если не хватает yarn.lock, вы получите разные зависимости для всех ваших окружений, что легко породит самые дурацкие ошибки.

[spacing size=”15″]
[spacing size=”20″]

Ошибка 3. Исправлять код как попало

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

Безусловно, иногда допустимо кодить «грязно». Когда главное — быстро получить результат. Например, если код нужен ненадолго или вовсе на раз. Но если кодом, который держится на костылях, будут пользоваться постоянно — это вам ещё аукнется.

[spacing size=”15″]

Ошибка 4. Искать лучший код для проходной задачи

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

А вам надо быстрее выдавать адекватный код, который верно решает поставленную задачу. Это значит — оптимальный для её условий, требований к кодингу в команде, понятный коллегам и так далее, а вовсе не лучший из всех возможных (например, по своим техническим характеристикам).

Так у вас останется время на действительно полезную работу.

[spacing size=”15″]

Ошибка 5. Не всегда проверять свой код

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

При этом большинство разработчиков ненавидят проверять свой код. Не видят в этом смысла, считают пустой тратой времени. Они уверены, что код заработает идеально. Почему — вопрос без ответа.

Не делайте так. Подкрепляйте веру в свой профессионализм результатами тщательного тестирования. Оно поможет устранить критические ошибки и подтвердит, что ваш код работает именно так, как задумано.

[spacing size=”15″]

Ошибка 6. Наследовать по поводу и без

В наследовании как таковом нет ничего плохого. Но я замечаю, что разработчики слишком уж им увлекаются. Это частая ошибка.

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

Так что помните: наследование — всё же не палочка-выручалочка, а палка о двух концах.

[spacing size=”15″]

Ошибка 7. Изобретать велосипед

Многие проекты применяют тот или иной фреймворк — это здорово упрощает жизнь разработчикам. Однако не все в команде знают, что фреймворк умеет.

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

Чтобы не делать двойную и тройную работу, изучайте фреймворки тщательнее.

[spacing size=”15″]

Ошибка 8. Не учиться новому

Не учиться чему-то новому — самая досадная ошибка разработчика.

Да, не всегда получается учиться на работе — приходится тратить и личное время. Но это необходимо, чтобы оставаться востребованным, это инвестиции в себя.

Ключ к совершенству — в практике, это знают все. Без неё не получить полезные навыки, не освоить другие языки программирования, новые технологии и так далее.

[spacing size=”15″]

Ошибка 9. Недооценивать объём работы

«Это задача в один стори поинт. Я быстро с ней управлюсь», — думали вы.

А всё оказалось иначе. Решение в лоб заработало не так, как ожидали. Пробуете альтернативное — на него уходит гораздо больше времени.

Недооценивать объём работы — ошибка частая, особенно в командах с гибким управлением проектами (типа Scrum).

Так что, если вы тимлид, закладывайте время не только на разработку продукта, но и на дополнительные этапы вроде тестирования.

[spacing size=”15″]

Ошибка 10. Излишняя самоуверенность

Уверенность в себе — это здорово, когда она не мешает вам слышать чужие мнения.

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

Разработчик не может разбираться сразу во всём и делать всё одинаково хорошо. Стоит это осознать.

Подытожу

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

[spacing size=”20″]

0 Комментариев
Комментариев на модерации: 0
Оставьте комментарий