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

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

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

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

Что такое Антипаттерны?

Семестр “антипаттерн” был придуман в книге под названием AntiPatterns в 1998 году. Это относится к повторно используемые решения, которые изначально кажутся полезными, но позже получается приносить больше вреда, чем пользы.

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

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

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

1. Преждевременная оптимизация

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

По известной цитате Дональда Кнута “преждевременная оптимизация - корень зла“, что может быть преувеличением, но все же показывает, насколько серьезные проблемы могут привести к преждевременной оптимизации.

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

Чтобы предотвратить преждевременную оптимизацию, рекомендуется следовать принципу программирования YAGNI (Вам это не нужно), который советует “всегда реализуйте вещи, когда они вам действительно нужны, никогда, когда вы просто предвидите, что они вам нужны.”

2. Изобретая колесо

“изобретать велосипед” антипаттерн иногда также называют “проектирование в вакууме”. Это происходит, когда мы хотим все делаем сами а также написать все с нуля, без поиска уже существующих методов, API или библиотек.

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

3. Зависимость ада

Противоположность “изобретать велосипед” Антипаттерн является еще одним распространенным антипаттерном называется “ад зависимости”.

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

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

4. Код Спагетти

“Код спагетти” вероятно, самый известный кодирующий антипаттерн. Он описывает приложение, которое трудно отладить или изменить из-за отсутствия надлежащей архитектуры.

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

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

5. Программирование перестановкой

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

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

6. Копирование и вставка программирования

“Копирование и вставка программирования” происходит, когда мы не следуем принципу кодирования «Не повторяйся» (DRY), и вместо создания общих решений мы вставляем уже существующие фрагменты кода в разные места, а затем редактируем их в соответствии с заданным контекстом.

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

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

7. Cargo-Cult Программирование

Имя “грузо-культовое программирование” происходит от определенного этнографического явления “культ груза”. Культы грузов появились в южной части Тихого океана после второй мировой войны, когда принудительный контакт с развитыми цивилизациями заставил туземцев думать, что промышленные товары, такие как кока-кола, телевизоры и холодильники, доставляемые на острова грузовыми судами, были созданы сверхъестественными методы; и если они совершают магические обряды, похожие на обычаи западных людей, груз, наполненный товарами, придет снова.

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

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

8. Поток лавы

Мы говорим о “поток лавы” антипаттерн, когда нам нужно иметь дело с кодом, который имеет избыточные или некачественные детали тот кажется неотъемлемой к программе, но мы не до конца понимаем, что она делает или как она влияет на все приложение. Это делает рискованным удаление.

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

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

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

9. Жесткое кодирование

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

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

10. Мягкое кодирование

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

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

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