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

Эта статья об одной из таких парадигм. Речь идет о парадигме разделения.

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

Позвольте мне проиллюстрировать это на примере того, как сегодня создается современное веб-приложение.

1. Двойной бэкенд

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

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

Хорошо, так зачем нам по сути два бэкэнд-сервиса? Один как лямбда-слой, а второй как внешний интерфейс?

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

Так почему же это не делается? Есть несколько причин. Иногда возникает проблема с поддержанием лямбда-слоя. Он плохо спроектирован. Поэтому никто не любит прикасаться к нему, чтобы ничего не сломать. Инструментов тоже не хватает. Обслуживание лямбда-слоя чревато ошибками и занимает очень много времени.

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

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

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

Правильный способ — поддерживать один хороший бэкэнд с одним хорошим API.

2. Микросервисы

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

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

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

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

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

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

Не только эти причины, но и другие причины делают обслуживание микросервисов очень дорогим. Так когда же их следует использовать? Есть две вещи, которые могут сбалансировать стоимость разделения проекта на них. Во-первых, когда проект действительно огромен. Я имею в виду — огромный. Люди не знают, что это значит. Итак, давайте возьмем пример: когда вы создаете операционную систему. Или банковское ПО. Затем создание микросервисов может быть полезным.

Еще одно требование состоит в том, что вы можете четко разделить микросервисы. Это совершенно разные вещи. У них не более 1% общих вещей.

Ведь мы же не пишем операционные системы или банковское ПО каждый день, не так ли? Таким образом, использование микросервисов не сбалансирует затраты.

Выше того, что я писал ранее, речь идет не только о том, что микросервисы предназначены для огромных систем. Где «микро» на самом деле означает гигантскую часть программного обеспечения. Потому что я верю, что некоторые люди знают об этом. Но все же решите использовать микросервисы для подготовки кода на будущее. Станет ли он операционной системой или банковским программным обеспечением? Я надеюсь, что так и будет, потому что это не установленная годовая веха, это преждевременная оптимизация. Одна из худших ошибок, которые можно совершить.

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

Но само величие также является предметом споров. Они действительно? В стандартном процессе применения решений должна быть проблема, анализ, выводы и решение.

Лучше думать о том, какую проблему мы решаем, а не выбирать все доступные решения. Итак, в чем проблема внедрения микросервисов?

Среди прочего можно услышать проблемы с поддержанием кодовой базы. За свою 20-летнюю практику я иногда видел такое. И почти всегда проблема была одна: код был в беспорядке.

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

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

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

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

3. Редукс

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

Redux — это библиотека управления состоянием. Популярные интерфейсные вещи, которыми люди действительно одержимы.

И я понимаю причину этого. Есть одно место для хранения состояния, поток изменений состояния легко отследить, есть причудливое расширение для Chrome. Хорошая вещь!

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

Создатели Redux приложили немало усилий, чтобы все было разделено. Действия, редукторы, эффекты, все. Теоретически это может иметь смысл. Но на практике это означает, что использование Redux — это 99% времени написания/копирования стандартного кода только для того, чтобы правильно его настроить. Не говоря уже о том, что в каждой строке кода может скрываться ошибка. И это написание кода стоит денег.

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

Сегодня Redux — довольно популярная библиотека. Однако больше, чем ужасное удобство использования, разочаровывает то, что при всей славе Open Source и других библиотек, которые обеспечивают тот же стандарт, но в лучшем виде, Redux все еще используется сегодня.

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

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

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

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