Антипаттерн — это альтернатива паттерну. Паттерн — это эффективный подход к решению задачи по программированию, предполагающий применение уже готового шаблона данного решения. Из этого получается, что антипаттерн — это решение задач по программированию по неэффективному шаблону или методу, который в результате решает поставленную задачу, но делает это неправильно и «криво».
Избегать антипаттернов — это хорошая практика для программиста. Так как их использование решает одну проблему, но обычно создает дополнительные трудности, которые по значимости не меньше решенной проблемы.
В то же время использование паттернов также иногда приводит к дополнительным проблемам. Это связано с тем, что при использовании готовых шаблонов для решения программистских задач не хватает базы знаний, времени и опыта.
Вот и получается, что использование антипаттернов всегда не рекомендуется, так как это заведомо проблемное решение, но в то же время и паттерны в неумелых руках не всегда выдают нужную эффективность. Поэтому использование паттернов и антипаттернов требует точного обоснования.
Сегодняшняя наша статья посвящена антипаттернам, поэтому приведем несколько популярных примеров.
Антипаттерны
На самом деле, антипаттернов тьма тьмущая. Они возникают как грибы после дождя. Это связано с тем, что само программирование не стоит на месте и постоянно растет объем разработок. Иногда складывается ощущение, что антипаттернов больше, чем паттернов. Их даже делят на 3 основные группы:
Антипаттерны архитекторов;
Антипаттерны разработчиков;
Антипаттерны руководства.
Антипаттерны архитекторов
Эти антипаттерны связаны с архитектурными проблемами разработки. Обычно их провоцируют неправильные решения, принятые архитекторами программы. Их наличие подразумевает нарушенную или запутанную структуру приложения, а также нарушенную взаимосвязь между компонентами программы, что в итоге приводит к ее некорректной работе.
Такие антипаттерны приводят к следующим проблемам:
скрывается часть функционала, которую считают ненужной для пользователя;
создается программа, у которой невозможно распознать структуру;
необоснованно сложный дизайн;
необоснованно сложный интерфейс, который очень трудно разработать;
нет возможности предугадать, как зависят события от действий пользователей;
программа решает только узкую задачу и не способна решать более широкие задачи;
и др.
Антипаттерны разработчиков
Как понятно из названия, эти антипаттерны связаны непосредственно с разработчиками программного обеспечения, а точнее, с их принятыми решениями. Может сложиться такая ситуация, что на уровне архитектуры все продумано неплохо, но разработчики реализовали все совсем не так.
Такие антипаттерны приводят к следующим проблемам:
один класс использует большое разнообразие методов;
использование объектов в неподходящем состоянии;
когда одни объекты передают данные другим объектам;
неправильное применение классов и функций;
лишняя сложность при решении задачи;
нет возможности проверить работу подпрограммы;
постоянное добавление новых скриптов для решения найденных ошибок;
неправильное наименование переменных, методов, функций и т. д.;
нет возможности удалить код низкого качества, потому что его удаление приводит к фатальным ошибкам;
запутанная реализация кода;
нет возможности проводить рефакторинг кода;
наличие объектов, которые только «притворяются», что содержат какие-то данные;
неоправданное использование паттернов;
когда копируются и применяются повторяющиеся скрипты;
замена функциональности документацией;
уверенность, что часто используемое решение спасет ситуацию и в этот раз;
уверенность в том, что не сработает известная ошибка;
слишком ранняя оптимизация кода;
создаются решения с нуля, при том что есть уже готовые отличные решения задач;
создается плохое решение, когда есть уже готовое отличное решение;
ошибки, приводящие к краху программы и невозможности ее реанимировать;
новый функционал добавляется как отдельное решение вместо того, чтобы обновить старый функционал;
бессмысленное применение различных библиотек, приводящее к тому, что удалить старые невозможно, а установить новые очень сложно;
предварительный показ того, как будет работать еще не написанная функция;
каждое новое обновление программы требует все больше и больше ресурсов «железа»;
реализация функций только для демонстрации их наличия;
и др.
Антипаттерны руководства
Как ни странно, но руководство тоже иногда применяет антипаттерны в своих решениях. От любого руководителя в первую очередь зависит взаимодействие между всеми сотрудниками, которые трудятся над разрабатываемой программой. Помимо этого, он отвечает еще за сроки реализации программы, необходимое количество ресурсов на разработку и за конечный результат.
Поэтому применение антипаттернов руководителем чревато последствиями. Некоторые проблемы, которые могут от этого возникнуть:
проект закрывается еще до старта его реализации, так как неправильно расходовались средства и было много потрачено на проектирование и анализ;
в проект, приносящий реальный доход, не финансируются средства на его развитие;
расходуются большие усилия и финансы на то, чтобы перенести разработку в новое окружение;
новые улучшения наносят ущерб общему состоянию программы;
необоснованное улучшение красоты кода приводит к ухудшению качества программы;
реализуется решение, даже после того, как было обосновано, что это ошибка;
когда игнорируется мнение специалиста ниже по статусу;
слишком жесткое управление;
непредоставление всей необходимой информации сотрудникам;
теряется контроль над масштабированием программы;
полное отсутствие личного вклада в разработку;
неправильное формирование команды, когда уход одного из ее членов провоцирует остановку разработки, так как все было завязано на этом человеке;
самостоятельное решение задач без оповещения кого-либо о том, как было достигнуто решение;
и др.
Заключение
Антипаттерны и проблемы идут рядом друг с другом. Антипаттерн — это решение, которое принял специалист в какой-то конкретной ситуации, чтобы исправить одну проблему, но по факту эти решения приводят к еще большим проблемам.
Можно сказать, что антипаттерны — это враги программистов и никакой пользы в себе они не несут. Нехватка времени, спешка и давление заказчика часто провоцируют их применение. Единственный путь их не применять — это правильно распределять свое рабочее время и никогда не поддаваться спешке, чтобы делать все так, как надо.
Другое
