Для меня scrum - это способ создать хорошее по с нулевой командой, которая даже никогда не работала в команде; с владельцем продукта, который никогда не был владельцем продукта. Вы можете слепо следовать инструкциям и у вас что-то получится. Чтоб получить хороший результат нужно следовать инструкциям обдуманно.
Как и любой "язык", scrum адаптируется под вас. Владелец продукта (возможно совместно с мастером и командой) шлифует книжные процессы и это нормально. И всегда будут ситуации, которые не встраиваются в идеальный процесс. И умение руководителей - это способность с этой ситуацией справиться. Если руководитель не имеет богатого опыта, то он будет работать по книжке и это нормально.
Оценка и "ритуал оценки" - это собрание на котором вы можете обратить внимание на отклонение. Если кто то задачи не может или дает очень большую оценку, то это сигнал как минимум поговорить о задаче. И на этом собрании команды вы можете задать вопросы, которые помогут вам с оценкой и улучшить качество постановки задачи. И оценки даются интуитивно, никто не запрещает так давать оценки задачам.
Про отсутствие скрам мастера или владельца продукта. Все в команде должны быть взаимозаменяемы. Это даже в манифесте прописано. Взаимозаменяемость среди тех специалистов полноценную я не встречала (очень ограничено), а вот роли между собой мы вполне могли менять.
Выбрать правильную методологию и адаптировать ее под свою команду - это задача руководителя. И да на некоторые проекты не ложится идеи scrum, некоторые должны работать по водопаду, а кто-то работает по Extreme programming (XP).
Во-первых, речь идёт не только о Кафка - мы её взяли для примера. Во-вторых, с помощью schema registry можно сгенерировать только модели - не учитываются хедеры, которые по спецификации api могут быть обязательны. Третье - мы пытаемся сгенерировать не только dto , но и обвязку вокруг. Ну и последнее - мы пытаемся именно объединить описание двух спецификаций - чтоб использовать один язык (OpenAPI) и один процесс генерации кода - openapi plugin.
API First как процесс не имеет ничего общего с генерацией кода. Это процесс при котором сначала разрабатывается API. Потом всё остальное. Поэтому не рекомендовать процесс я не могу :-).
Генерация кода - это хорошее дополнение к процессу. Почему бы не сгенерировать код, если команда определилась как будет описывать API . В нашем случае то самое единое информационное поле - это спецификации в OpenAPI формате (имхо: wsdl немного архаично смотрится, json scheme не содержит всю информацию об API).
Мы не упаковывали npm - мы именно отдавали спеку. На мой взгляд, это удачный пример мягкого перехода на описанные процессы генерации кода. Никто не мешает поочередно переходить на использование спецификации в качестве источника информации об API.
Переход на какой либо процесс - это всегда нетривиальная задача. У меня был опыт гибрида: мы клиенту (js+react) отсылали спеку (сложную с обобщёнными типами), а сами эту спеку создавали автоматически по моделям java. В итоге клиент перешел на генерацию кода, а мы (бек) нет. Но это нас вполне устроило. Немного смягчит сценарий перехода.
По поводу крупный или не крупный проект: постановка вопроса от размера проекта абсолютно не зависит. Ломать что-то работающее всегда сложно. Прекрасно видела систему из множества сервисов (ты даж не знал, кто твои клиенты) и единственное чем обменивались была подобная спецификация.
По поводу коммон библиотек: распространение коммон библиотек у нас привело к тому, что в одном общем классе было 100500 групп валидаций. Да и как только коммон библиотека меняет версию начинается очень большая беготня (или если версии где-то разошлись). Если используются спеки эта проблема пропадает (при полной поддержке обратной совместимости).
С дженериками при неудачном стечении обстоятельств действительное были проблемы (сейчас уже лучше - начиная с 3.1).
генераторы кода для Async API на node JS - по крайней мере то что я нашла на их сайте. Соответственно для сборки проекта с генерацией кода в инфраструктуру для сборки Java приложений надо тянуть ноду (не хочу). Я хочу такой же процесс сборки - плагин (в моем случае gradle plugin). Надо посмотреть внимательнее на плагин, который вы прислали (спасибо).
Так же, когда речь идет о переходе на api-first, то изучение двух DSL станет большим препятствием. Мы решили немного приблизить спецификацию асинхронного общения к OpenAPI
Добрый день. Про AsyncAPI написано в статье. Мы его рассматривали. Но у него для нас есть критичные недостатки: инфраструктура вокруг него вся на JS и это еще один DSL.
Количество идей не бесконечно. Предлагаю это не только я ) Это весьма популярная тема. OpenAPI обрел свою популярность - поэтому вокруг него много софта.
Спасибо за совет. Громкий ЛОГ при выходе действительно хорошо подсвечивает то, что несколько запусков по прохождении тестов.
Под тестами контроллеров имеются в виду тесты @MockMvc - они полностью имитируют запрос и ответ к нему. Обращение к методу контроллера происходит с помощью URL.
На мой взгляд, основная проблема работы с техдолгом - это отсутствие у команды политики создания задач типа "техдолг". Попытаюсь объяснить, что я имею в виду. Команда хочет перейти на новую версию библиотеки. Задача заводится. Но оснований перехода нет - старая версия работает, нового функционала в новой версии не добавили, дефекты критичные для вашего продукта не исправлены. Формально это можно считать техдолгом. Но на деле, получается, что техдолг заполнен неприоритетными задачами, которые и создают такое пренебрежительное отношение к важной проблеме.
В плане проектирования, да Вы правы, ничего нового. Но если посмотреть с точки зрения разработчика, то весьма редко начинают программировать сервис именно с API. В итоге много ожиданий и неожиданных находок, когда уже, казалось бы, всё готово.
Конечно, использование подхода не гарантирует наличие имплементации. Это гарантирует процесс тестирования (который в этом случае начинается рано - сразу после разработки спецификации). Если уж на продакшн попал не реализованный метод API, то скорее всего, он мало приоритетный. На мой взгляд, это всё равно лучше, чем если бы на продакшн сервисе оказался неверно имплементированный метод или несовпадение со спецификацией.
Не совсем. Agile не отрицает написание документации перед выполнением самой задачи. Как раз при использовании agile фреймворков и возникают разлады с несогласованными протоколами общения из-за частых изменений и релизов. Подход как и раз и позволяет держать единый формат спецификации.
Для меня scrum - это способ создать хорошее по с нулевой командой, которая даже никогда не работала в команде; с владельцем продукта, который никогда не был владельцем продукта. Вы можете слепо следовать инструкциям и у вас что-то получится. Чтоб получить хороший результат нужно следовать инструкциям обдуманно.
Как и любой "язык", scrum адаптируется под вас. Владелец продукта (возможно совместно с мастером и командой) шлифует книжные процессы и это нормально. И всегда будут ситуации, которые не встраиваются в идеальный процесс. И умение руководителей - это способность с этой ситуацией справиться. Если руководитель не имеет богатого опыта, то он будет работать по книжке и это нормально.
Оценка и "ритуал оценки" - это собрание на котором вы можете обратить внимание на отклонение. Если кто то задачи не может или дает очень большую оценку, то это сигнал как минимум поговорить о задаче. И на этом собрании команды вы можете задать вопросы, которые помогут вам с оценкой и улучшить качество постановки задачи. И оценки даются интуитивно, никто не запрещает так давать оценки задачам.
Про отсутствие скрам мастера или владельца продукта. Все в команде должны быть взаимозаменяемы. Это даже в манифесте прописано. Взаимозаменяемость среди тех специалистов полноценную я не встречала (очень ограничено), а вот роли между собой мы вполне могли менять.
Выбрать правильную методологию и адаптировать ее под свою команду - это задача руководителя. И да на некоторые проекты не ложится идеи scrum, некоторые должны работать по водопаду, а кто-то работает по Extreme programming (XP).
Во-первых, речь идёт не только о Кафка - мы её взяли для примера. Во-вторых, с помощью schema registry можно сгенерировать только модели - не учитываются хедеры, которые по спецификации api могут быть обязательны. Третье - мы пытаемся сгенерировать не только dto , но и обвязку вокруг. Ну и последнее - мы пытаемся именно объединить описание двух спецификаций - чтоб использовать один язык (OpenAPI) и один процесс генерации кода - openapi plugin.
Генерация кода - это хорошее дополнение к процессу.
API First как процесс не имеет ничего общего с генерацией кода. Это процесс при котором сначала разрабатывается API. Потом всё остальное. Поэтому не рекомендовать процесс я не могу :-).
Генерация кода - это хорошее дополнение к процессу. Почему бы не сгенерировать код, если команда определилась как будет описывать API . В нашем случае то самое единое информационное поле - это спецификации в OpenAPI формате (имхо: wsdl немного архаично смотрится, json scheme не содержит всю информацию об API).
Мы не упаковывали npm - мы именно отдавали спеку. На мой взгляд, это удачный пример мягкого перехода на описанные процессы генерации кода. Никто не мешает поочередно переходить на использование спецификации в качестве источника информации об API.
Переход на какой либо процесс - это всегда нетривиальная задача. У меня был опыт гибрида: мы клиенту (js+react) отсылали спеку (сложную с обобщёнными типами), а сами эту спеку создавали автоматически по моделям java. В итоге клиент перешел на генерацию кода, а мы (бек) нет. Но это нас вполне устроило. Немного смягчит сценарий перехода.
По поводу крупный или не крупный проект: постановка вопроса от размера проекта абсолютно не зависит. Ломать что-то работающее всегда сложно. Прекрасно видела систему из множества сервисов (ты даж не знал, кто твои клиенты) и единственное чем обменивались была подобная спецификация.
По поводу коммон библиотек: распространение коммон библиотек у нас привело к тому, что в одном общем классе было 100500 групп валидаций. Да и как только коммон библиотека меняет версию начинается очень большая беготня (или если версии где-то разошлись). Если используются спеки эта проблема пропадает (при полной поддержке обратной совместимости).
С дженериками при неудачном стечении обстоятельств действительное были проблемы (сейчас уже лучше - начиная с 3.1).
генераторы кода для Async API на node JS - по крайней мере то что я нашла на их сайте. Соответственно для сборки проекта с генерацией кода в инфраструктуру для сборки Java приложений надо тянуть ноду (не хочу). Я хочу такой же процесс сборки - плагин (в моем случае gradle plugin). Надо посмотреть внимательнее на плагин, который вы прислали (спасибо).
Так же, когда речь идет о переходе на api-first, то изучение двух DSL станет большим препятствием. Мы решили немного приблизить спецификацию асинхронного общения к OpenAPI
Добрый день. Про AsyncAPI написано в статье. Мы его рассматривали. Но у него для нас есть критичные недостатки: инфраструктура вокруг него вся на JS и это еще один DSL.
Количество идей не бесконечно. Предлагаю это не только я ) Это весьма популярная тема. OpenAPI обрел свою популярность - поэтому вокруг него много софта.
Вести документацию через MR давняя мечта.) Это весь практично - взять тот же md формат.
Спасибо за совет. Громкий ЛОГ при выходе действительно хорошо подсвечивает то, что несколько запусков по прохождении тестов.
Под тестами контроллеров имеются в виду тесты @MockMvc - они полностью имитируют запрос и ответ к нему. Обращение к методу контроллера происходит с помощью URL.
На мой взгляд, основная проблема работы с техдолгом - это отсутствие у команды политики создания задач типа "техдолг". Попытаюсь объяснить, что я имею в виду. Команда хочет перейти на новую версию библиотеки. Задача заводится. Но оснований перехода нет - старая версия работает, нового функционала в новой версии не добавили, дефекты критичные для вашего продукта не исправлены. Формально это можно считать техдолгом. Но на деле, получается, что техдолг заполнен неприоритетными задачами, которые и создают такое пренебрежительное отношение к важной проблеме.
В плане проектирования, да Вы правы, ничего нового. Но если посмотреть с точки зрения разработчика, то весьма редко начинают программировать сервис именно с API. В итоге много ожиданий и неожиданных находок, когда уже, казалось бы, всё готово.
Конечно, использование подхода не гарантирует наличие имплементации. Это гарантирует процесс тестирования (который в этом случае начинается рано - сразу после разработки спецификации). Если уж на продакшн попал не реализованный метод API, то скорее всего, он мало приоритетный. На мой взгляд, это всё равно лучше, чем если бы на продакшн сервисе оказался неверно имплементированный метод или несовпадение со спецификацией.
Не совсем. Agile не отрицает написание документации перед выполнением самой задачи. Как раз при использовании agile фреймворков и возникают разлады с несогласованными протоколами общения из-за частых изменений и релизов. Подход как и раз и позволяет держать единый формат спецификации.