Как не изобретать велосипед - гибридный системный подход
уроки, извлеченные в стартапе до его приобретения
Когда я был девелопером, я работал в транспортном стартапе, который сломал монополию, делая странные вещи. Университет произвел на меня впечатление структурированного и упорядоченного подхода к ведению бизнеса. Возможно, так обстоят дела в других местах, но не в том месте, где я оказался.
Я был едва подготовлен к тому, как работал мой первый настоящий босс.
Он ненавидел изобретать колесо, и любое предложение всегда должно было предусматривать альтернативные существующие решения, которые можно было модифицировать в соответствии с целями проекта. Короче говоря, вся система была полностью скомпонована таким специальным способом, который был совершенно уникальным для самого бизнеса.
Вот четыре различных типа гибридных творений, которые мы создали для различных проектов, запускаемых нами в месячном цикле.
WordPress + Angular
Когда сторонняя компания предложила создать систему контента по невысокой цене в 45 000 долларов плюс текущая плата за обслуживание, часть моего мозга мгновенно вспыхнула красным.
Я сказал своему боссу, что он хочет вести блог. Система содержания была для этого просто причудливым названием. Кроме того, у него уже есть установленный WordPress. Проблема заключалась не в том, что сам WordPress отстой, а в том, как его использовали.
Система контента может оставаться организованной только в том случае, если люди, использующие ее, делают это правильно.
С накоплением более 500 сообщений в виде страниц без тегов или категорий, конечно, WordPress будет чувствовать, что он терпит неудачу в бизнесе.
После небольшого обновления с новой темой и переклассификации контента это позволило бизнесу использовать области виджетов для формы бронирования. В течение двух недель после того, как мы разобрали WordPress и перенесли части формы Angular в качестве плагина, мы получили более плавный процесс преобразования контента в систему бронирования, используя работу SEO, которая привлекала трафик.
Урок дня: если это звучит дорого, вероятно, так оно и есть.
Угловые микро-интерфейсы на Java
Когда я начинал, уже была налаженная система бронирования. Однако исходная система была неуклюжей, и специалист по бэкенду был не лучшим, когда дело касалось фронтальной реализации.
Были также ограничения в том, где мы могли разместить интерфейс, и для конкретного проекта, над которым я работал, он должен был находиться в самом приложении Java. Хотя это было не идеально, особенно когда мы пытались переместить все в их собственные отдельные пространства, мне пришлось придумать обходной путь, и в итоге я остановился на микро-интерфейсах Angular.
Хотя микро-интерфейсы и Angular не совсем синонимы, это возможно. Существует заблуждение, что для того, чтобы приложение Angular работало, нужно было создать целое приложение Angular с нуля, настроить его и затем работать только внутри этого монолита. Однако Angular допускает модуляризацию с помощью элементов Angular - это означает, что вы можете создать свой компонент Angular отдельно, а затем добавить его в проект. В результате получается аккуратно содержащий фрагмент кода, который остается изолированным от всего остального при использовании централизованной службы управления данными, чтобы поддерживать синхронизацию состояний с другими частями приложения Java.
Почему мы не создали Java напрямую? Отчасти это произошло потому, что мы хотели четко разделить Java-часть и интерфейсные технологии. Со временем все начало запутываться, и чистое разделение стало возможным только при переходном подходе.
Урок дня: когда создание с нуля невозможно, микро-интерфейсы могут помочь ускорить процесс перехода.
Angular + серверная часть микросервисов
Было время, когда серверная часть Java стала настолько плохой, что нам все еще приходилось выпускать функции. Сама Java неплохая, но то, как предыдущие разработчики сшивали код, привело к ситуации, похожей на спагетти и фрикадельки.
Это преимущества работы с устаревшим кодом и предыдущими расширениями, которые систематически не разбивались на модули.
Ограничение по времени и сокращение числа разработчиков в команде означало, что нам нужно было проявить творческий подход к тому, что у нас есть. Вместо того, чтобы пытаться бороться с бэкэндом Java, мы закончили тем, что составили серию бэкэнда микросервисов и прикрепили его к нашему существующему интерфейсу Angular.
Было много адаптеров для Java API, но новая структура также уступила место новому внутреннему коду, который не был тесно связан с существующей системой. Состояния сохранялись в базе данных и координировались с помощью ряда связанных лямбда-выражений AWS. В итоге мы использовали бессерверную разработку для локальной разработки, а затем организовали ее конвейерную обработку, чтобы все разработчики в команде могли работать над определенной частью серверной части, не вторгаясь в код другого разработчика. Это также избавило нас от надоедливых git конфликтов, которые у нас были.
Урок дня: модульное расширение может быть благом, когда вы увязли в устаревшем коде
Бэкэнд микросервисов с SQL и DynamoDB
Одна из основных проблем построения целого бэкэнда с микросервисами - как вы справляетесь со состояниями?
Временный характер микросервисов означает, что данные, которые необходимо передать по цепочке композиции, должны управляться внешним источником. Вам также необходимо, чтобы структуры данных были достаточно гибкими без необходимости создания новых схем для размещения каждого небольшого количества данных, которые вы хотите сохранить.
Итак, как нам сбалансировать потребность в том, чтобы данные были информативными, но в то же время гибкими? В итоге мы выбрали подход AWS lambda + DynamoDB. Быть частью одной экосистемы означало более легкую и быструю доступность, чем попытки работать по сети с внешней базой данных.
Мало того, структуры без таблиц позволяли данным иметь любую требуемую форму. Это позволило быстрее экспериментировать с моделями данных и преобразованиями по мере необходимости, не влияя на остальную часть приложения.
Способ биллинга DynamoDB аналогичен Firebase - плата основана на использовании. Единственное другое отличие - это предоставление ресурсов, а это означает, что при необходимости ваш счет может быть жестко ограничен.
Когда что-то нужно было хранить постоянно, мы перемещали данные в базу данных SQL, где сервер Java имел к ним доступ и делал то, что нужно.
Урок дня: решения для гибридных данных могут работать, особенно если у вас есть четкие цели для типов баз данных. Когда дело доходит до SQL и безтабличных баз данных, это не обязательно должен быть эксклюзивный тот или иной подход.
Последние мысли
Хотя приятно иметь все в одном месте и код, составленный по модульному принципу, не всегда на 100% гарантировано, что это произойдет в реальной жизни.
Код может быть беспорядочным, разрастаться в странной среде, что приводит к решениям, которые в то время имели смысл. Гибридный подход может помочь сбалансировать потребность в устойчивом рассудке разработчика и требования к доставке. Это также дает возможность модернизировать ваши системы, не пугая босса.
Сказать своему боссу, что вся система - мусор, никогда не сработает. Почему? Потому что большинство людей, не являющихся разработчиками, видят в коде постоянную структуру - например, физический объект, который не меняется и не разрушается. Это связано с денежной оценкой, и большинству предприятий необходимо вернуть эти инвестиции, прежде чем они подумают о том, чтобы отказаться от того, что у них есть в настоящее время.
Сам Интернет сейчас находится в зрелом состоянии, вместе с технологиями и идеологиями развития. То, что создано сегодня, имеет больше шансов выжить в следующем десятилетии, чем то, что было построено в период зарождения идей гибридных систем.
Когда дело доходит до бизнес-точки зрения, важно продолжать двигаться вперед, и иногда, как разработчикам, нам просто нужно понять эту часть, не избавляясь от всего.
