Человеку свойственно ошибаться. День за днём все мы совершаем промашки. И на работе тоже.
Создание программ — задача сложная. Без ошибок здесь не обходится. Какие-то ошибки пустяковые, какие-то — серьёзные. Но они были и будут всегда.
И это хорошо. Потому что ошибки ценны. Конечно, если мы извлекаем из них уроки — и растём профессионально. Как говорила Элеонора Рузвельт, жизнь слишком коротка, чтобы тратить её на повторение чужих ошибок. Так что лучше на них учиться.
Я расскажу про самые частые ошибки разработчиков. Надеюсь, вы научитесь их избегать.
Ошибка 1. Неверно сохранять изменения проекта
Все хоть раз коммитили в неправильную ветку репозитория. На исправление этой ошибки можно убить уйму времени. Но если заметить её вовремя, ничего страшного не произойдёт. Гораздо хуже — продолжать коммитить неверную ветку.
Помните об этом и будьте внимательны.
Ошибка 2. Путать, что нужно коммитить
Я часто сталкиваюсь с тем, что в репозитории оказываются лишние файлы или в нём чего-то недостаёт. Это происходит тогда, когда фиксируют слишком много изменений за раз. Тут уж немудрено надобавлять лишнего или забыть что-то нужное.
Первое обычно делают поспешные или небрежные разработчики. Например, я со счёта сбился, сколько раз видел в репозиториях файлы формата IDE. Бездумное добавление к коммиту всех файлов подряд ничем хорошим не кончится.
С другой стороны, есть файлы, про которые часто забывают — по незнанию или не разобравшись в их назначении. Например, файл yarn.lock. Разработчики не понимают, зачем он нужен, — и потому боятся добавлять в репозиторий. Или считают, что этот файл важен только в их локальном окружении.
Чаще всего из-за пропавшего файла что-нибудь пойдёт не так, а что конкретно — зависит от файла. Например, если не хватает yarn.lock, вы получите разные зависимости для всех ваших окружений, что легко породит самые дурацкие ошибки.
Ошибка 3. Исправлять код как попало
Разработчики часто исправляют баги небрежно, лишь бы побыстрее. Такой подход быстро приводит к техническому долгу. А это демотивирует не только тех, кто вынужден дорабатывать ваш код, но и всю команду.
Безусловно, иногда допустимо кодить «грязно». Когда главное — быстро получить результат. Например, если код нужен ненадолго или вовсе на раз. Но если кодом, который держится на костылях, будут пользоваться постоянно — это вам ещё аукнется.
Ошибка 4. Искать лучший код для проходной задачи
Этим часто грешат новички — очень уж им охота впечатлить коллег. Но поверьте, писать навороченный код для задачи, которая того не стоит, бессмысленно. Так вы тратите время на то, чего не требовалось.
А вам надо быстрее выдавать адекватный код, который верно решает поставленную задачу. Это значит — оптимальный для её условий, требований к кодингу в команде, понятный коллегам и так далее, а вовсе не лучший из всех возможных (например, по своим техническим характеристикам).
Так у вас останется время на действительно полезную работу.
Ошибка 5. Не всегда проверять свой код
Каждый разработчик хоть раз в жизни писал совсем короткий код — буквально пару строк. Казалось, тут просто нечему ломаться. И верно: здесь не ломалось — ломалось где-то ещё, но виноваты были как раз те две строчки.
При этом большинство разработчиков ненавидят проверять свой код. Не видят в этом смысла, считают пустой тратой времени. Они уверены, что код заработает идеально. Почему — вопрос без ответа.
Не делайте так. Подкрепляйте веру в свой профессионализм результатами тщательного тестирования. Оно поможет устранить критические ошибки и подтвердит, что ваш код работает именно так, как задумано.
Ошибка 6. Наследовать по поводу и без
В наследовании как таковом нет ничего плохого. Но я замечаю, что разработчики слишком уж им увлекаются. Это частая ошибка.
Злоупотребляя наследованием, легко угодить в капкан переинжиниринга. В результате ваш код окажется настолько универсальным, что вы забудете про главную задачу, ради которой он создан и которую должен решать лучше всего. Использовать его будет одинаково неудобно для всех целей, а потому и неразумно.
Так что помните: наследование — всё же не палочка-выручалочка, а палка о двух концах.
Ошибка 7. Изобретать велосипед
Многие проекты применяют тот или иной фреймворк — это здорово упрощает жизнь разработчикам. Однако не все в команде знают, что фреймворк умеет.
И это проблема. Потому что такие разработчики продолжают изобретать методы и инструменты, аналоги которых во фреймворке уже есть. То есть не только тратят время впустую, но и не пользуются потенциалом фреймворка — усложняют повторное использование кода.
Чтобы не делать двойную и тройную работу, изучайте фреймворки тщательнее.
Ошибка 8. Не учиться новому
Не учиться чему-то новому — самая досадная ошибка разработчика.
Да, не всегда получается учиться на работе — приходится тратить и личное время. Но это необходимо, чтобы оставаться востребованным, это инвестиции в себя.
Ключ к совершенству — в практике, это знают все. Без неё не получить полезные навыки, не освоить другие языки программирования, новые технологии и так далее.
Ошибка 9. Недооценивать объём работы
«Это задача в один стори поинт. Я быстро с ней управлюсь», — думали вы.
А всё оказалось иначе. Решение в лоб заработало не так, как ожидали. Пробуете альтернативное — на него уходит гораздо больше времени.
Недооценивать объём работы — ошибка частая, особенно в командах с гибким управлением проектами (типа Scrum).
Так что, если вы тимлид, закладывайте время не только на разработку продукта, но и на дополнительные этапы вроде тестирования.
Ошибка 10. Излишняя самоуверенность
Уверенность в себе — это здорово, когда она не мешает вам слышать чужие мнения.
Самоуверенные разработчики порой забывают, что тоже совершают ошибки. И чаще начинают принимать решения единолично, не консультируясь ни с кем. Однажды это непременно выйдет им боком: либо качество решений упадёт, либо коллеги начнут чувствовать себя ненужными.
Разработчик не может разбираться сразу во всём и делать всё одинаково хорошо. Стоит это осознать.
Подытожу
Подумайте над этими ошибками, извлеките урок из каждой. Позвольте себе ошибаться, но не забывайте на этом учиться. И помните расхожую мудрость: не ошибается лишь тот, кто ничего не делает.
