Реальный опыт проекта по выбору стека UI-технологий
В последнее время я начал работать над проектом Frontend Migration, в котором на Durandal и Knockout работало несколько разных приложений.
Эта интересная и прекрасная история началась, когда один из наших архитекторов продукта установил меня, чтобы я понял линейку продуктов с точки зрения пользовательского интерфейса. Требование клиента заключалось в том, что им нужна была гармонизация всех различных активов, а также платформа единого входа (SSO), чтобы обеспечить лучший пользовательский опыт.
Я обнаружил, что их многочисленные продукты работают на устаревшем технологическом стеке. Эти продукты не согласованы друг с другом. И им также нужна единая унифицированная платформа (SSO) для всех активов. Это кажется простым требованием, но если вы разберетесь с ними, вы почувствуете сложность.
- Трансформация технологий, новые технологии должны поддерживаться в течение следующих 5 лет, они должны масштабироваться, чтобы новые активы можно было добавлять / удалять с минимальными настройками
- Все активы должны выглядеть одинаково, но при этом представлять уникальную индивидуальность, рассматривать их как букет цветов, где каждый цветок имеет свой блеск и аромат.
- SSO, я думаю, это не требует объяснений
Что ж, в этом посте я не буду писать о последних требованиях, так как это не тема для обсуждения. напишу другой пост, чтобы закрепить и их.
Возвращаясь к нашему самому важному требованию, выбор технологического стека, который может поддерживать в течение следующих 5 лет, - очень сложная работа, для этого требуется понимание текущих и будущих требований, компромиссы, доступность рабочей силы по кривой обучения, срок действия и т. д.
Да, Срок годности - один из ключевых факторов, который необходимо определить в начале разработки. В этом мире нет ничего бессмертного, как программное обеспечение, технологии и архитектура. Если вы посмотрите на Angular, там также упоминается срок годности версии: Все наши основные выпуски поддерживаются в течение 18 месяцев. Это означает, что у вашего приложения нет гарантии, если оно создано с использованием Angular и работает в версии, которой 18 месяцев. При этом правильный выбор не только повысит производительность, но и повлияет на долговечность.
Итак, я провел сравнительный анализ некоторых передовых фреймворков, доступных на рынке, таких как React, Angular, Polymer.
Некоторые из вас могут подумать, почему я выбрал для анализа только эти три пункта:
Что ж, на рынке доступно большое количество фреймворков пользовательского интерфейса, которые служат той же цели с небольшими различиями, но некоторые из них достаточно надежны и популярны, чтобы их можно было включить в список кандидатов для нашего анализа. Я выбрал Angular и React, потому что оба являются надежной платформой для создания сложных функций пользовательского интерфейса, имеют хорошую поддержку сообщества, частота развертывания новых версий составляет быстро, обогащенный ускорителями разработчика, такими как интерфейс командной строки и т. д., так что это был очевидный выбор.
Что касается полимера, я вижу, что он имеет огромный потенциал для создания многоразовых компонентов, не зависящих от инфраструктуры, т. Е. вы можете создавать компоненты в Polymer и развертывать их в любых других UI-фреймворках, таких как Angular, React, Backbone, Vue и т. д. Его встроенная поддержка создания веб-компонентов выделяет его из ряда вон выходящего.
Критерии отбора
Теперь у меня были требования и кандидаты на технологии, следующим шагом было составить критерии, на основе которых мне нужно было определить подходящую.
В этом разделе представлены некоторые критерии и драйверы, которые я использовал при оценке. Они в основном обусловлены требованиями, например. как эти варианты (React, Angular, Polymer) обеспечивают возможность повторного использования. Есть ли у нас какие-либо встроенные инструменты / процессы для повышения производительности? или как эти варианты работают, когда у нас есть сложный пользовательский интерфейс (грязные обновления, глубоко вложенная иерархия) для рендеринга?
Результат
Позвольте мне начать этот раздел с универсальной истины: не существует серебряной пули для решения всех проблем. сказав, что я выбрал для этой реализации Angular, почему? смотрите ниже
· Модульность и управляемость происходит от Typescript - написание корпоративного приложения / продукта с более длительным сроком хранения требует высокой управляемости. Поскольку Angular по умолчанию склонен к машинописному тексту, становится проще писать код на Angular с использованием машинописного текста.
· Единая платформа для всех нужд, меньше проблем с интеграцией - не беспокойтесь о сторонних интеграциях, команда Angular управляет совместимостью версий во время обновления. вы просто сосредотачиваетесь на написании масштабируемого кода.
· Создано лидерами отрасли. Конечно, ни у кого нет сомнений в том, что команда Google Angular предоставляет лучшие наборы технологий, набор инструментов и документацию. Всегда лучше выбирать «продукты с репутацией и надежностью».
Некоторые другие моменты, которые я заметил во время своей оценки и которые стоит упомянуть здесь:
. Обеспечивает возможность повторного использования с поддержкой компонентно-ориентированной архитектуры
· Стандартизация и удержание навыков. В моей команде было больше ребят из ООП, которые в прошлом выполняли тяжелую работу на Java или аналогичной платформе ООП. Поскольку Angular поддерживает TS в качестве естественного языка разработки, ребята из ООП чувствуют себя как дома. Напротив, я обнаружил, что React ближе к функциональной парадигме, когда вы в основном пишете чистые функции для создания приложений.
· Эффективность разработки
Заключительное примечание
У каждого фреймворка / библиотеки есть баланс прибылей / убытков. Это скорее технические / бизнес-требования, которые определяют решение. В моем случае клиенту необходимо поддерживать продукт в течение следующих 5 лет. Для этого нужна линейка продуктов с хорошей репутацией, поэтому не идите на поводу у отраслевой волны, это может серьезно повлиять на ваш проект. Всегда полезно сформулировать функциональные и нефункциональные требования, а затем попытаться найти наилучший вариант.
