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

Перевод публикуется с сокращениями, автор оригинальной статьи – The woman.

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

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

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

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

Симптомы

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

Лечение

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

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

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

Симптомы

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

Лечение

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

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

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

Симптомы

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

Лечение

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

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

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

Симптомы

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

Лечение

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

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

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

Симптомы

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

Лечение

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

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

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

Симптомы

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

Лечение

• Указатели очень просты для понимания, но часто неправильно понимаются из-за отсутствия практики.

Дополнительные материалы в «Библиотеке программиста»:

• Советы программистам, которые учатся самостоятельно
• Вопрос дня: не поздно ли начинать карьеру программиста в 40 лет?
  
• 12 вещей, о которых стоит знать каждому программисту
  
• 30 уловок на языке Python, которые сделают вас лучшим программистом
  
• Достаточно задать один вопрос, чтобы понять, какой вы программист