В индустрии разработки программного обеспечения часто используются два термина: Front-End и Back-End. Но с чего все началось? Как это влияет на команды? и действительно ли это хорошо?
Более десяти лет назад веб-сайты были довольно примитивными. Большинство веб-сайтов работали на сервере, генерирующем статические страницы с некоторым содержанием. С пользователем было очень простое взаимодействие: в основном кнопки и формы. Процесс тоже был простым. Например, сервер генерирует форму с некоторыми входными данными. Пользователь вводит некоторую информацию и отправляет ее. Данные отправляются на сервер, и сервер генерирует еще одну новую страницу с успехом или неудачей в зависимости от ввода.
Этот тип архитектуры, который я только что описал, называется монолитом. Например, PHP, ASP, JSP и т. Д., Содержащие представление HTML. Позже мы начали видеть использование шаблонов и паттернов, таких как MVC, но все же интерфейс и серверная часть были объединены.
Монолитное программное обеспечение очень легко написать и намного проще в краткосрочной перспективе, нет необходимости настраивать API или вызывать их, и, следовательно, скорость разработки выше (и даже производительность). Это также облегчает жизнь, когда дело доходит до SEO и A / B-тестирования. Однако, поскольку все написано в одном месте, он может стать тесно связанным «Кодексом спагетти», который может быть трудно поддерживать и масштабировать в долгосрочной перспективе.
Позже, когда Ajax получил широкую поддержку в браузерах, мы наконец смогли запрашивать данные в фоновом режиме, не перенаправляя пользователя на другую страницу. Например, Gmail в 2004 году - не нужно обновлять вручную, чтобы увидеть новые электронные письма. Этот момент времени имеет решающее значение, потому что именно в этот момент мы начинаем переходить на разработчиков внешнего и внутреннего интерфейса (а не просто на «веб-разработчиков»).
Однако для того, чтобы сделать простой вызов ajax, ранее требовалось написать около 100 строк кода. Использование библиотеки jQuery решило эту проблему, и мы смогли сделать запрос с 1–3 LoC (используя функции $ .post или $ .get).
Кроме того, на рынке появлялись новые типы устройств - мобильные, планшеты, смарт-телевизоры и т.д. фреймворки (например, бутстрап решает проблемы с адаптивным макетом). Такие интерфейсные технологии сделали процесс разработки более плавным, а также открыли гораздо более широкие возможности.
Более того, когда архитектура представляет собой монолит, поддержка различных устройств становится сложной и неэффективной. Это увеличило использование API-интерфейсов - одна серверная часть обслуживает разные типы клиентов и интерфейсов или систем (возможность повторного использования).
Преимущества разделения кажутся очевидными. И многое другое: слабая связь (легче тестировать отдельно), возможность имитировать ответы (более высокая скорость разработки), меньшая нагрузка на сервер и, что очень важно, более простая поддержка CDN.
Тем не менее, хотя отделение интерфейса от серверной части доказало свою эффективность, оно также усложнило внутреннюю часть, потому что нам нужно позаботиться о таких вещах, как управление версиями API, реализация интерфейсов связи, таких как REST, SOAP и т. Д. нам нужно обрабатывать ошибки сервера, отправляя, получая и обрабатывая данные.
Чтобы решить ее должным образом, требуется гораздо больше усилий по сравнению с монолитом. Другими словами, нам нужно больше разработчиков, чтобы ускорить поставки программного обеспечения. А большие команды могут привести к большему количеству конфликтов. И это также момент, когда ваш конвейер CI / CD начинает давать сбой (и, конечно, это хорошо, потому что означает, что интеграционные тесты работают).
Поэтому при расширении команды очень важно выбрать правильную архитектуру / шаблоны. Мы можем уменьшить количество конфликтов, сделав команды более автономными. Я хотел бы показать вам несколько шаблонов в качестве примера того, как разные архитектуры могут лучше сочетаться с разными командами.
Архитектура микространиц - родственная душа не SPA, микросервисы
У каждой команды есть страница. Страницы взаимодействуют между собой с помощью сеанса (например, файлы cookie, локальное хранилище и т. Д.).
Каждая страница полностью независима и имеет собственный репозиторий и зависимости. Например, вы даже можете использовать несколько фреймворков (Angular, React, Vue.js и т. Д.) - я не говорю, что вы хотите, но вы можете (может быть полезно для миграции). Это также означает, что у вас могут быть дубликаты (например, заголовок).
+ Меньше зависимостей
+ Простая интеграция
+ Полная автономия
- Дублирование функций
- Несогласованность UX
- Низкая производительность
- Обмен данными ограничен через сеанс
Архитектура портала - SPA
У каждой команды есть виджет. Глобальные функции доступны через портал.
+ Никаких дубликатов
+ Единый UX
- Портал - это зависимость
- Портал нужно издеваться
- Управление версиями зависимостей
Резюме
В заключение я сначала представил монолит и перешел к разделению задач, к более модульной архитектуре, которая позволяет большим командам работать вместе над крупными проектами более эффективно. Организационная структура неразрывно связана с архитектурой, и у каждого шаблона есть свои преимущества и недостатки.
Модульные шаблоны и микросервисы / страницы - это компромисс. Они могут хорошо подходить для крупномасштабных проектов, но не обязательно для стартапов / небольших проектов. Это может чрезмерно усложнить ситуацию и замедлить поставки программного обеспечения без достаточных оснований. Начните с монолита, отделяйте, когда придет время.
Ги Ромбо является основателем LeAgile.co. У нас есть проверенный опыт оказания помощи компаниям в реализации их цифровых преобразований и ускорении поставок программного обеспечения. 🚀✨
