В большинстве случаев мы знаем, что должны делать, но не делаем этого. Мы думаем, что сможем исправить все позже. Но «позже» никогда не наступает. Это общий признак ленивого программиста и первый шаг к тому, чтобы стать плохим программистом.
Вчера я прочитал замечательную длинную статью Дэрилла Сантоса с GitHub. Я обобщил и выбрал некоторые из признаков, которые мне показались важными. Итак, перейдем к фактам.
1. Отсутствие понимания цели кода
Прежде чем писать код, вы должны знать, что он будет делать – это похоже на запуск программы в вашей голове.
Симптомы
- Создание переменных, которые никогда не используются.
- Выдача нерелевантных результатов.
- Вызов функций, которые не имеют отношения к цели.
- Выполнение идемпотентных функций (таких как save() ) несколько раз, просто для уверенности.
- Исправление ошибок путем постоянного рефакторинга и перезаписи ошибочного кода.
- Ненужное преобразование значений: сначала преобразуем decimal в string , а затем снова string в decimal .
Лечение
- Используйте отладчик IDE в качестве помощника.
- Проверяйте значения переменных до и после изменения.
2. Плохое понимание архитектуры языка
Объектно-ориентированное программирование – такая же парадигма, как функциональное или декларативное программирование, но со своими отличиями. Программисты зачастую путаются при переходе с одной архитектуры на другую, и это нормально: со временем вы лучше поймете эту архитектуру.
Симптомы
- Несоответствие стандартам ООП;
- Вызов нестатических функций/переменных в неинстанцированных классах.
- Написание множества классов со всеми методами для управления полями объектов с помощью одного небольшого метода.
- Использование реляционной базы данных как хранилища объектов.
- Выполнение всех объединений и отношений на клиентской стороне.
- Создание нескольких версий одного и того же алгоритма для обработки разных типов.
- Установка отдельных значений (в императивном коде) вместо использования биндинга.
Лечение
- Это не то, что можно преодолеть и выучить за один день – вам нужно больше практики.
- Чтение документации. Если вы не понимаете архитектуру языка или основы ООП, потратьте немного времени на изучение.
- Изучайте и применяйте код старших товарищей.
3. Отсутствие доверия к своему коду
Когда ваша логика слаба, вы сомневаетесь в каждом шаге и не доверяете собственному коду.
Симптомы
- Применение функций IsNull() , IsNotNull() , isTrue(bool) или IsFalse(bool) без необходимости.
- Проверка, является ли логическая переменная чем-то кроме true или false .
- Многократный вызов одной и той же функции для подтверждения ее выполнения.
Лечение
- Не переносите ненужные старые привычки из языка со слабой типизацией.
- Будьте уверены в своей логике. Если испытываете проблемы, попробуйте использовать другой подход или почитайте литературу по алгоритмизации.
4. Попадание в ловушку рекурсии
Идея рекурсии очень хитрая, но несложная. Многие программисты боятся рекурсии как огня, но она делает код более чистым и эффективным.
Симптомы
- Сложные итерационные алгоритмы для задач, которые могут быть решены рекурсивно, например, прохождение по дереву файловой системы.
- Проверка состояния до и после рекурсивного вызова.
- Рекурсивные функции, которые не проверяют базовое условие.
- Рекурсивные функции, которые конкатенируют/суммируют глобальные переменные и вывод.
Лечение
- Запускайте код в несколько шагов, чтобы понять последовательность действий. Это может привести к переполнению стека.
- Измените базовое условие, чтобы увидеть выходные данные.
- Ваша цель – обрести уверенность и полное представление о том, где вы находитесь и что делаете в цепочке рекурсии.
5. Слабые исследовательские навыки
Современные фреймворки и языки обладают огромным количеством встроенных библиотек и функций. Информации настолько много, что хорошему программисту потребуется несколько лет, чтобы усвоить хотя бы ее часть. Однако хороший программист всегда ищет встроенную фичу, прежде чем начать придумывать собственный велосипед.
Симптомы
- Повторное изобретение встроенных базовых механизмов, таких как обработчики или регулярные выражения.
- Повторное изобретение классов и функций, встроенных во фреймворк.
- Вместо поиска информации в сети, посты на форумах в стиле: «Дайте мне код, пожалуйста».
- Постоянное использование старомодных техник программирования, даже когда новые лучше решают задачу.
- Усложнение текущего решения («код обходного пути») вместо поиска более простого, которое выполнит то же самое с меньшим количеством кода.
Лечение
- Для развития исследовательских навыков требуется время, так что не спешите.
- Если вы застряли, не бегите к товарищу-программисту и не копируйте код из сети. Потратьте время и ознакомьтесь с документацией.
6. Плохое понимание концепции указателей
Если вы не понимаете концепцию указателей, вам будет тяжело писать сложные структуры данных и эффективные API. Вы обязательно создадите начиненный ошибками дизайн структуры данных.