Не совсем так и не в протоколе дело, а в том, что один модуль стал меньше знать о другом модуле. Самое банальное, как создать класс. Это другая зона ответственности. Да, есть паттерны, которые помогают решить эту проблему: DI или Фабрика. Но опять же мы навязываем знание о потребителе поставщику данных.
Утрированно: уменьшая связанность, мы уменьшаем у поставщика данных знания, кто эти данные будет использовать.
В рамках Symfony я подобные вещи решал с помощью стандартного сериализатора.
И ни что не мешает его поставить в любой проект «composer require symfony/serializer».
Это не дичь, а использование уже готового инструмента.
Часто, в работе требуется выполнять разные команды с параметрами в зависимости от настроек конкретного окружения. Постоянно вспоминать команды — напрягает, хочется как-то это упростить и автоматизировать.
Это удобно использовать при переключении между ветками проекта: выполнить миграции, подтянуть новые зависимости или запустить установку заново.
Конечно же обертку можно написать на любом языке, но Make уже дает готовый инструмент.
Как пример, список команд в одном наших из проектов:
=== Application ===
make configure — Настройка конфигов
make reinstall — полная переустановка сервиса (сборка контейнера, сброс БД, composer install)
make install — первоначальная установка или обновление сервиса (сборка контейнера, composer install)
make status — статус приложения
make clean — удаление всех файлов, которые созданы во время установки
make cache-clear — прогрев кэша (через приложение) === Tests ===
make app-ok — проверка всего сервиса
make cc — прогон тестов === Docker ===
make up — поднять сервис
make stop — остановить сервис
make down — остановка с удалением контейнера
make php-cli — войти в shell сервиса php
make nginx-cli — войти в shell сервиса nginx
make php-log — stdout сервиса php
make nginx-log — stdout сервиса nginx === DB ===
make migrate — накатка миграций
make remigrate — Очистка БД и выполнение миграций
На данный момент API SchoolOut практически аналогичен API Mail.Ru
Мы специально сделали адаптер, который позволит разработчикам приложений для Mail.Ru быстро настроить приложение для работы на SchoolOut. Поэтому и документации очень похожи.
Не совсем так и не в протоколе дело, а в том, что один модуль стал меньше знать о другом модуле.
Самое банальное, как создать класс. Это другая зона ответственности. Да, есть паттерны, которые помогают решить эту проблему: DI или Фабрика.
Но опять же мы навязываем знание о потребителе поставщику данных.
Утрированно: уменьшая связанность, мы уменьшаем у поставщика данных знания, кто эти данные будет использовать.
Не думали выложить свое решение в открытый доступ?
Например:
И ни что не мешает его поставить в любой проект «composer require symfony/serializer».
Часто, в работе требуется выполнять разные команды с параметрами в зависимости от настроек конкретного окружения. Постоянно вспоминать команды — напрягает, хочется как-то это упростить и автоматизировать.
Это удобно использовать при переключении между ветками проекта: выполнить миграции, подтянуть новые зависимости или запустить установку заново.
Конечно же обертку можно написать на любом языке, но Make уже дает готовый инструмент.
Как пример, список команд в одном наших из проектов:
Confluence — база знаний (ТЗ и его обсуждение)
Jira — управление задачами и ресурсами
Мы специально сделали адаптер, который позволит разработчикам приложений для Mail.Ru быстро настроить приложение для работы на SchoolOut. Поэтому и документации очень похожи.