Denver 83

Веб-разработчик, фрилансер… Пишу об ИТ и смежных технологиях. Ошибаться свойственно человеку. Вместе разберемся с самыми распространёнными ошибками разработчиков и способами их решения.

Кто-то из великих мыслителей когда-то сказал: «Покажите мне человека, который не ошибся ни разу в жизни, и я покажу вам человека, который ничего не достиг». Сами по себе ошибки — это не зло, они помогают нам расти и развиваться. Совершить их может специалист любого уровня. Однако учиться лучше на чужих неудачах, нежели на своих. «Библиотека программиста» детально разобралась в этой теме и составила список распространенных ошибок кодеров, которых вы можете избежать, если дочитаете статью до конца. Поехали!

1. Приступать к программированию, не до конца проработав схему проекта

Реализацию любого проекта можно разделить на три простых этапа:

1. Анализ требований проектируемого продукта
2. Создание схемы или прототипа самого проекта
3. Реализация или непосредственное написание кода

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

2. Отсутствие единообразия и формата написания кода

Это ошибка, которую чаще всего совершают неопытные разработчики и новички.

Разрозненный неоднообразный код затруднит чтение и расстроит не только членов вашей команды, но и всех, кому доведется читать ваши угловатые конструкции. Старайтесь оставлять после себя чистоту и не заставляйте потомков извергать проклятья, глядя на ваш свободный стиль написания кода. В современном программировании большинство ИТ-специалистов используют определенные методологии написания кода, которые варьируются в зависимости от области разработки и языка. Также многие из них используют «плагины для форматирования кода», помогающие мгновенно избавиться от этой ошибки.

Больше полезных материалов вы найдете на нашем телеграм-канале «Библиотека программиста» Интересно, перейти к каналу

3. Написание глупых или заумных комментариев

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

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

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

Также нужно отметить, что комментарии более эффективны, если они сообщают другим «почему этот конкретный код пишется в данной ситуации», а не «что делает этот код».

Однако при комментировании нужно знать меру. Не стоит писать философское эссе размером в страницу, все должно быть четко, лаконично и по существу.

4. Не тестировать написанное

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

5. Написание универсальных супер-функций

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

6. Плохие сообщения коммитов

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

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

Фиксации с сообщениями типа: «Исправлена ​​ошибка» или «Обновлена ​​функция» — так себе названия. Хороший коммит содержит информацию о проблеме и ее решении, предшествующий уникальному идентификатору токена (если он доступен).

7. Чрезмерная инженерия или усложнение простых вещей

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

1. Что использовать?
2. Где и когда использовать?
3. Как использовать?

Не стоит городить огород из ненужных плагинов и библиотек — старайтесь делать все проще и не усложняйте себе и без того нелегкий труд.

8. Не анализировать готовые решения в сети

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

9. Консерватизм и проповедование только одного стека

Поговорка, про кулика, расхваливающего свое болото актуальна и для мира ИТ. Наверняка, вам также доводилось слышать, как некоторые специалисты превозносят одну конкретную технологию, говоря, что все остальные ужасны. И заголовки кликбейтных статей, увещевающих о войнах фреймворков и языков («Vue vs React» или «Python vs Java») рождаются именно по их вине. Нельзя говорить, что один популярный инструмент хуже другого только лишь потому, что вы к нему привыкли. В разных ситуациях каждый будет хорош по-своему. Здесь главное уметь с ним работать. Грешно ругаться на молоток, утверждая, что он плохо забивает гвозди. А поскольку технологии совершенствуются довольно быстро, крайне важно быть открытым для новых идей и способов реализации. Консерватизм в ИТ — это ошибочный путь.

10. Перерабатывать и пренебрегать здоровьем

Последняя, наиболее важная проблема и главная ошибка начинающих разработчиков — это пренебрежение собственным здоровьем. Бесспорно, к работе нужно относиться ответственно и стараться делать поставленные задачи в срок, но не в ущерб себе. Факторов, влияющих на самый ценный ваш ресурс может быть много, начиная с вредного начальника и ежедневных мозговых штурмов и заканчивая решением срочных задач с горящими дедлайнами и работой допоздна. Однако несмотря ни на что, одно должно оставаться неизменным — ваша забота о собственном самочувствии. Помните, жизнь — это дар и ее качество гораздо важнее, чем сверхурочная работа, за которую в большинстве случаев вам даже «спасибо» никто не скажет.

***

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

Материалы по теме

• 🐛 Типовые ошибки в разработке UI: найти и обезвредить
• 8 самых распространенных ошибок веб-разработчика
• ⚠️ Как не нужно учить TypeScript: 5 распространенных ошибок
• 👶 10 ошибок начинающего разработчика
• ТОП-13 ошибок начинающего программиста