7.5 Жесткое кодирование (Hard code)

Жесткое кодирование схоже с магическими числами, однако, его определение более общее. Жесткое кодирование предполагает явное указание некоторых значений в коде программы, например путь или имя файла, значения параметров:

std::string filePath = "C:/Documents and Settings/Username";

Image icon = LoadImage("MyImage.bmp")

Жесткое кодирование вызывает проблемы, связанные с переносимостью программы. Для изменения файла с картинкой потребуется перекомпиляция программы, а для переноса программы на другую операционную систему потребуется изменить формат пути к файлу.

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

Настраиваемые параметры программы могут быть вынесены в конфигурационные файлы, а зависимость от особенностей операционной системы, например формат пути к файлам, может быть вынесена в отдельный слой системы.

7.6 Мягкое кодирование (Soft code)

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

Для исключения проблем с мягким кодированием следует перед началом разработки определить множество параметров, которые будут настраиваемыми, а какие можно указать непосредственно в коде.

7.7 Золотой молоток (Golden hammer)

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

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

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

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

7.8 Слепая вера (Blind faith)

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

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

При проектировании программы следует выделить набор компонентов или классов, которые будут отвечать за проверку корректности данных, остальные классы будут работать, зная, что входные данные корректны. Проверка данных и результатов работы должна быть в четко определенных местах. Если проверка будет осуществляться при каждом использовании данных, это чревато другим антипаттерном − ненужная сложность.