Веб-разработка: 10 кодирующих антипаттернов, которых вы должны избегать

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

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

Шаблоны проектирования обычно являются повторно используемыми решениями для определенных сценариев, которые могут пригодиться для решения часто возникающих проблем и могут очень помочь нам оптимизировать наш код.
Хотя шаблоны проектирования являются отличным средством для улучшения нашего процесса разработки с помощью хорошо проверенных формул, иногда мы также можем ошибаться с ними. Они называются антипаттернами.
Что такое антипаттерны?
Термин «антипаттерн» был придуман в книге под названием AntiPatterns в 1998 году. Это относится к повторно используемым решениям, которые первоначально кажутся полезными, но позже оказывается, что они приносят больше вреда, чем пользы.

Это может происходить по разным причинам, например, если мы не используем шаблоны в правильном контексте, обстановке или времени (решения, которые были эффективны в прошлом, могут не всегда работать в настоящем), или в других случаях вся парадигма было просто плохо с самого начала.
Антипаттерны также часто называют паттернами неудач. Хорошей новостью является то, что их можно распознать и избежать.

В этой статье мы рассмотрим 10 распространенных антипаттернов кодирования в веб-разработке, которые могут ввести нас в заблуждение, что у нас хорошо оптимизированный код. (Обратите внимание, что антипаттерны, перечисленные в этом посте, не обязательно совпадают с тем, что вы можете найти в упомянутой выше книге.)
1. Преждевременная оптимизация
Хорошее время является решающим фактором в оптимизации кода. Мы можем легко воспроизвести антипаттерн «преждевременной оптимизации», если мы обращаем внимание на небольшую эффективность и оптимизируем ее слишком рано в процессе разработки, прежде чем мы точно знаем, что мы хотим сделать.

В соответствии с Дональд Кнут«Знаменитая цитата»преждевременная оптимизация – корень зла«Это может быть преувеличением, но все же показывает, как серьезные проблемы могут привести к преждевременной оптимизации.

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

Чтобы предотвратить преждевременную оптимизацию, рекомендуется следовать ЯГНИ (Тебе это не нужно) принцип программирования, который советует «всегда реализовывать вещи, когда они вам действительно нужны, а не тогда, когда вы просто предвидите, что они вам нужны».
2. Изобретая колесо
Антипаттерн «заново изобретать колесо» иногда также называют «конструированием в вакууме». Это происходит, когда мы хотим сделать все сами и написать все с нуля, не ища уже существующие методы, API или библиотеки.

Изобретать колесо – это не просто тратить время, но нестандартные решения, особенно для базовых функций, редко бывают настолько же хороши, как стандартные, которые уже были протестированы многими разработчиками и пользователями.
3. Зависимость ада
Противоположностью антипаттерна «изобретать колесо» является другой распространенный антипаттерн, называемый «ад зависимости».

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

Ад зависимостей может быть решен с помощью менеджеров пакетов, которые могут разумно обновлять взаимозависимые зависимости. Если эта проблема нас слишком волнует, рефакторинг также может быть хорошей идеей.
4. Код Спагетти
«Код спагетти», пожалуй, самый известный кодирующий антипаттерн. Он описывает приложение, которое трудно отладить или изменить из-за отсутствия правильной архитектуры.

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

Спагетти-код, как правило, проистекает из комбинации различных плохих практик кодирования, таких как код, не содержащий надлежащих условных блоков, имеющий множество операторов goto, исключений и потоков, содержащих части, которые принадлежат где-то еще, имеет минимальные отношения между объектами, имеет функции или методы, которые не могут быть повторно использованы или не документированы должным образом или вообще.
5. Программирование перестановкой
«Программирование перестановкой» или «программирование случайно» происходит, когда мы пытаемся найти решение проблемы, последовательно экспериментируя с небольшими модификациями, тестируя и оценивая их одну за другой, и, наконец, реализуя ту, которая работает сначала.

Программирование с помощью перестановки может легко внести новые ошибки в наш код, и что еще хуже, они являются ошибками, которые мы не обязательно распознаем сразу. Во многих случаях также невозможно предвидеть, будет ли решение работать для всех возможных сценариев или нет.
6. Копирование и вставка программирования
«Копирование и вставка программирования» происходит, когда мы не следуем Не повторяйте себя (СУХОЙ) принцип кодирования, и вместо того, чтобы создавать общие решения, мы вставляем уже существующие фрагменты кода в разные места, а затем редактируем их в соответствии с заданным контекстом.

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

Программирование копирования и вставки выполняется не только начинающими разработчиками, но и опытными программистами, так как многие из них склонны использовать свои собственные заранее написанные, хорошо протестированные фрагменты кода для конкретных задач, что может легко привести к непреднамеренным повторениям.
7. Cargo-Cult Программирование
Название «грузо-культовое программирование» происходит от определенного этнографического феномена, называемого «грузовой культ». Грузовые культы появился в южной части Тихого океана после второй мировой войны, когда принудительный контакт с развитыми цивилизациями заставил туземцев думать, что промышленные товары, такие как кока-кола, телевизоры и холодильники, доставляемые на острова грузовыми судами, были созданы сверхъестественными методами; и если они совершают магические обряды, похожие на обычаи западных людей, груз, наполненный товарами, придет снова.

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

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

Это обычно происходит с устаревшим кодом, или когда код был написан кем-то другим (обычно без надлежащей документации), или когда проект слишком быстро перешел с этапа разработки на этап производства.

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

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

Подробнее: 10 причин, почему вам нужна оптимизация кода

1. Жесткое кодирование
   «Жесткое кодирование» – это известный антипаттерн, против которого большинство книг по веб-разработке предупреждает нас прямо в предисловии. Жесткое кодирование – неудачная практика, при которой мы сохраняем данные конфигурации или входные данные, такие как путь к файлу или имя удаленного хоста, в исходном коде, а не получаем их из файла конфигурации, базы данных, пользовательского ввода или другого внешнего источника. ,

Основная проблема с жестким кодом заключается в том, что он работает должным образом только в определенной среде, и в любое время условия меняются, нам нужно изменить исходный код, обычно в нескольких отдельных местах.
10. Мягкое кодирование
Если мы очень стараемся избежать ловушки жесткого кодирования, мы можем легко столкнуться с другим антипаттерном, называемым «мягким кодированием», который является его полной противоположностью.

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

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