Комментарии 3
Ожидал в статье рассказ о внедрении процессного управления из-за заголовка, а тут рефлексия по процессам разработки. Тем не менее рефлексия приятная, прочитал с удовольствием.
Не очень складное, но по содержанию прекрасное описание выстраивания процесса на личном примере (пробелы везде можно найти). Не понятно в чем проблема взаимодействия команд фронта и бэка по контрактам API. Очевидно, что swagger-описания на старте не бывает и что о контрактах нужно договариваться и где-то фиксировать, что и делается у автора в юзерстори. "Поля и их обязательность" определяются не бэком, а бизнесом - это результат бизнес-анализа. Я знаю одного избалованного (точнее профдеформированного) рельсами руководителя разработки, который методы для java формализует в виде справочника и в таком случае вообще нет никаких проблем - бэк вернёт когда-нибудь всё, что надо фронту с полями предметной области в контексте - пиши свой фронт на здоровье, не оглядывайся - не нужно командам на каждом проекте проходить одно и то же. Если же фронт не погружен в контекст, не вникает в специфику бизнес-задачи, то он будет ждать "наименования полей и их обязательность" до морковкина заговенья, жаловаться на бэк и никогда ничего дельного не напишет.
Вроде ничего нового, можно было бы решить этот вопрос Swagger`ом, но там контракты появляются после раскатки, что нам не подошло. Возможно, есть более совершенные решения, о которых я с радостью почитаю в комментариях и, наверное, возьму на вооружение
Можно писать `Swagger` "на берегу". Фронтенд на его основе может замокать ответы сервера. Не раз уже так делали в силу сжатых сроков
Как мы строили процессы в Домклик