6 признаков того, что вы плохой программист

6 признаков того, что вы плохой программист

В большинстве случаев мы знаем, что должны делать, но не делаем этого. Мы думаем, что сможем исправить все позже. Но «позже» никогда не наступает. Это общий признак ленивого программиста и первый шаг к тому, чтобы стать плохим программистом.

Вчера я прочитал замечательную длинную статью Дэрилла Сантоса с GitHub. Я обобщил и выбрал некоторые из признаков, которые мне показались важными. Итак, перейдем к фактам.

1. Отсутствие понимания цели кода

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

Симптомы

  • Создание переменных, которые никогда не используются.
  • Выдача нерелевантных результатов.
  • Вызов функций, которые не имеют отношения к цели.
  • Выполнение идемпотентных функций (таких как save() ) несколько раз, просто для уверенности.
  • Исправление ошибок путем постоянного рефакторинга и перезаписи ошибочного кода.
  • Ненужное преобразование значений: сначала преобразуем decimal в string , а затем снова string в decimal .

Лечение

  • Используйте отладчик IDE в качестве помощника.
  • Проверяйте значения переменных до и после изменения.

2. Плохое понимание архитектуры языка

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

Симптомы

  • Несоответствие стандартам ООП;
  • Вызов нестатических функций/переменных в неинстанцированных классах.
  • Написание множества классов со всеми методами для управления полями объектов с помощью одного небольшого метода.
  • Использование реляционной базы данных как хранилища объектов.
  • Выполнение всех объединений и отношений на клиентской стороне.
  • Создание нескольких версий одного и того же алгоритма для обработки разных типов.
  • Установка отдельных значений (в императивном коде) вместо использования биндинга.

Лечение

  • Это не то, что можно преодолеть и выучить за один день – вам нужно больше практики.
  • Чтение документации. Если вы не понимаете архитектуру языка или основы ООП, потратьте немного времени на изучение.
  • Изучайте и применяйте код старших товарищей.

3. Отсутствие доверия к своему коду

Когда ваша логика слаба, вы сомневаетесь в каждом шаге и не доверяете собственному коду.

Симптомы

  • Применение функций IsNull() , IsNotNull() , isTrue(bool) или IsFalse(bool) без необходимости.
  • Проверка, является ли логическая переменная чем-то кроме true или false .
  • Многократный вызов одной и той же функции для подтверждения ее выполнения.

Лечение

  • Не переносите ненужные старые привычки из языка со слабой типизацией.
  • Будьте уверены в своей логике. Если испытываете проблемы, попробуйте использовать другой подход или почитайте литературу по алгоритмизации.

4. Попадание в ловушку рекурсии

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

Симптомы

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

Лечение

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

5. Слабые исследовательские навыки

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

Симптомы

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

Лечение

  • Для развития исследовательских навыков требуется время, так что не спешите.
  • Если вы застряли, не бегите к товарищу-программисту и не копируйте код из сети. Потратьте время и ознакомьтесь с документацией.

6. Плохое понимание концепции указателей

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