Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-02-21

1 <a>#статьи</a>

2 <ul><li>26 мар 2021</li>

3 <li>0</li>

4 </ul>Не стесняйтесь своих ошибок, потому что ошибаются - все!

5 Переводчик-фрилансер. Увлечён своей профессией. Переводит полезные статьи на разные темы - от IT до путешествий, урбанистики и социологии. Занимается лингвистическими исследованиями.

6 об авторе

7 Живёт в Нидерландах, занимается backend-разработкой, увлечённо инвестирует в криптовалюты.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

35 Как попрактиковаться? Вот вам<a>идеи</a>pet-проектов, которые вы можете воплотить.

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

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

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

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

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

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

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

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

44 <a>Бесплатный курс по Python ➞Мини-курс для новичков и для опытных кодеров. 4 крутых проекта в портфолио, живое общение со спикером. Кликните и узнайте, чему можно научиться на курсе. Смотреть программу</a>