да миллион кейсов которые не позволяют взять и договориться без реализации

Это редкие, исключительные случаи

У меня к примеру не может быть сущность создана если у нее проверочный код не введен

Да нифига.

В активной разработки таких случаев вагон.

Значит хуево договаривались

Они все мелкие но их много.

Ну збс, давай код в голове писать, чо.

Эмм

Это редкие, исключительные случаи

ну что значит редкие? 5-10% уже не редкость и такое говно будешь долго помнить

такое ощущение что тут все пишут апи для разработчиков а не для бизнеса.

Ну збс, давай код в голове писать, чо.

Это вообще-то хорошая идея

Это вообще-то хорошая идея

А зачем его писать в голове если за полчаса я накидаю черновую реализацию и вылью в ветку уже РАБОТАЮЩЕЕ апи?

ну что значит редкие? 5-10% уже не редкость и такое говно будешь долго помнить

Значит хуево обсуждали

и заодно разрулю все подводные камни.

Ну йопт, все мегаархитекторы и помнят все 100 фич проекта.

Это вообще-то хорошая идея

конечно хорошая, но есть реальность нельзя просто так взять и согласовать работу всех узлов

А зачем его писать в голове если за полчаса я накидаю черновую реализацию и вылью в ветку уже РАБОТАЮЩЕЕ апи?

И потом 10 раз переделаешь

зачем7

А фронт будет ебаться

такое ощущение что тут все пишут апи для разработчиков а не для бизнеса.

бизнесу апи нахер не нужно, его разработчики пользуют

Фронт ебется, перепишем еще раз.

Это проще чем каждый раз поднимать все фичи проекта.

Стараясь следовать за полетом твоей фантазии

А фронт будет ебаться

фронт всегда будет ебаться :) у них технологический ад

бизнесу апи нахер не нужно, его разработчики пользуют

Разработчики не смогут реализовать два требования которые противоречат друг другу

фронт всегда будет ебаться :) у них технологический ад

Это другой вид ебли :)

а такое в формальных требованиях встречается часто, и эти кейсы на этапе планирования действительно не видны.

Например?

например манагер ошибся при постановке задачи 50/50 таких случаев

Например?

например забыли что одна фича мешает другой, потому что одна фича написана год назад и ей никто не пользовался

пользовался

например манагер ошибся при постановке задачи 50/50 таких случаев

Для этого обсуждения и придуманы, нет?

просто про нее никто не помнил при постановке второй фичи

Для этого обсуждения и придуманы, нет?

Да никто про нее не вспомнит до реализации поймите уже.

Для этого обсуждения и придуманы, нет?

да, но манагер же не знает что он ошибся?

например забыли что одна фича мешает другой, потому что одна фича написана год назад и ей никто не пользовался

Сложно такую коллизию представить

фич, на среднем проекте, МНОГО.

Запросто.

Сложно такую коллизию представить

легко

Мне тоже

В интернет магазине (типичная вещь) таких кейсов может быть полно.

крайне редко это делаю, ну может быть в пятницу вечером бухой

Если ты хочешь узнать были ли у меня нормальные процессы разработки то могу сразу резюмировать: не было.

Не утруждайся

На 100% уверен что не попадешь.

У тебя будет свой собственный сад не волнуйся.

Я хз над чем ты работаешь что у тебя фичи на бумаги все согласованы и одна не мешает другой

На картоне? где работаешь?

мальчики, идите в https://telegram.me/ruby_talks ссориться

ну там мало фич, потому ты и не сталкивался.

Сложно такую коллизию представить

вот у меня бизнес состоит из 6 типов взаимодействующих независимых участников рынка мне их нужно заставить всех дружить количество b2b интеграций приближается к сотне, разных интеграций данные лежат в общей апишке итоговое взаимодействие обслуживается третьим сервисом для каждой интеграции обычно нужен свой костыль, потому, что задача не имеет общего решения интеграция без костыля - редкое событие коллизии в сложных системах случаются на каждом шагу

мне кажется что чуваки, которые говорят про “договориться” никогда не работали с 10ками разных приложений, которые должны одно API использовать, иначе такой хуйни бы не несли

что пошло не так?

ERROR: S client not available

агрегатор какой нибудь

а почему манагер ставит задачи разработке?)

в нормальных условиях манагер должен работать над беклогом

бинго

вот у нас есть бэклог

теперь у нас есть две фичи

который разгребает тимлид, уточняет у манагера и причастных детали и составляет задачи для разработки

при реализации мы обнаруживаем что старая фича не дает 1в1 реализовать новую

и новую приходится переосмысливать

который разгребает тимлид, уточняет у манагера и причастных детали и составляет задачи для разработки

сферическая команда разработки в вакууме

но это вскрывается уже на реализации, потому что не получится 100+ фич проекта помнить.

> @bikolya необязательно твои эндпоинты в итоге будут разниться с хотелками мобильных разработчиков, и будешь под каждого что-то допиливать.

> сферическая команда разработки в вакууме почему?

я не утверждаю, что такой подход исключает коллизии

при реализации мы обнаруживаем что старая фича не дает 1в1 реализовать новую

и в api нужно выпилить старую фичу и впилить новую?

но он их минимизирует

> сферическая команда разработки в вакууме почему?

потому что редко так бывает кризис, нужно экономить, на ПМ-ах например

и в api нужно выпилить старую фичу и впилить новую?

Зачем выпиливать старую фичу если она нужна и реализована?

тимлид вроде не равно пм

но в целом, да, мысль об экономии понятна

Зачем выпиливать старую фичу если она нужна и реализована?

а в чём проблема тогда? Берёшь и реализуешь новую фичу. DONE.

скорее всего в бэклоге на 100+ фич будут несостыковки.

а в чём проблема тогда? Берёшь и реализуешь новую фичу. DONE.

Нельзя один в один реализовать новую фичу т.к мешает допустим валидация из старой

нужно переосмысливать фичу.

вот у меня бизнес состоит из 6 типов взаимодействующих независимых участников рынка мне их нужно заставить всех дружить количество b2b интеграций приближается к сотне, разных интеграций данные лежат в общей апишке итоговое взаимодействие обслуживается третьим сервисом для каждой интеграции обычно нужен свой костыль, потому, что задача не имеет общего решения интеграция без костыля - редкое событие коллизии в сложных системах случаются на каждом шагу

ну мы тут как бы не интеграции обсуждаем, а взаимодействие фронтенд-бекенд

Нельзя один в один реализовать новую фичу т.к мешает допустим валидация из старой

валидация где? В модели?