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

Перевод публикуется с сокращениями, автор оригинальной статьи – 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, которые сделают вас лучшим программистом
• Достаточно задать один вопрос, чтобы понять, какой вы программист

• 0 views
• 0 Comment