15 ошибок в программировании, которые совершал каждый разработчик

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

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

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

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

4. Написание очевидных комментариев. Мы все видели подобные комментарии раньше. Они ничего не объясняют, но сосредотачиваются на том, что делает код (например, комментарий типа «цикл по продуктам», когда есть цикл foreach). Когда бы вы ни оказались в такой ситуации, не пишите комментарий, посвященный тому, что делает код. Вместо этого сосредоточьтесь на том, зачем этот код написан.

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

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

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

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

9. Изобретение колеса заново из-за недостатка знаний. Эта ошибка возникает, когда разработчик не знает, что уже доступно во фреймворке. В результате этого недостатка знаний разработчик реализует новые методы, которые почти идентичны методу, уже доступному в фреймворке.

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

11. Плохие сообщения при коммите. Мы, наверное, все это уже совершали раньше. «Исправлена ​​ошибка» или «WIP» — не очень хорошие сообщения в коммите. Важно писать правильные сообщения, и вы должны найти время для этого. Хорошее сообщение содержит полезную информацию о том, что изменилось и почему. Когда дела идут плохо, история изменений — отличный ресурс, чтобы быстро узнать, где именно что-то пошло не так.

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

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

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

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

Источник