У нас все так же прям один в один. Как и у многих. Новый проект, новая команда, все ведут «все по ГОСТу», разрисовывают, расписывают. Как раз для решения проблем на стыке легаси и кросспроектных задач появилась у нас такая альтернатива
Что касается разработки команде обычно хватает стандартные описания микросервисов, эндпоинтов, экранных форм. С версионированием тоже проблем нет. Тут скорее тестировщики выступают с тем, что не понятно, что означают некоторые сущности, какими они бывают, и главное как их на тесте генерировать, а бегать по нескольким статьям они не хотят
Основная проблема, скорее, находится в задачах, когда есть не самое "новое решение", которое начинают дорабатывать сразу несколько команд, причем с разных направлений. У них разные стандарты, по которым их работу оценивают их Лиды. Все тянут одеяло на себя. А если еще и исходная команда распалась, то совсем беда. Мы участвовали в нескольких проектах под условных названием "Единое окно", когда делают приложение, в которое "встраивается" всё, что было сделано до этого. и на таких проектах приходится изобретать велосипед и даже колесо)
Спасибо за комментарий! На самом деле второй подход я встретил только на последнем проекте. Сначала он казался абсурдным, но он показал свою жизнеспособность, так как: 1) часто приходилось дорабатывать решения других команд 2) многие решения являются устаревшими, не имеют спецификаций 3) Только происходит "переходный процесс" унификации всех направлений, при этом все равно все проекты в большей части живут своей жизнью (хотя общий технический стек). В таких реалиях приходится много вопросов отдавать на откуп разработчику и и ему приходится вникать в задачу. В новых решениях, конечно, однозначно первый вариант
У нас все так же прям один в один. Как и у многих. Новый проект, новая команда, все ведут «все по ГОСТу», разрисовывают, расписывают. Как раз для решения проблем на стыке легаси и кросспроектных задач появилась у нас такая альтернатива
Что касается разработки команде обычно хватает стандартные описания микросервисов, эндпоинтов, экранных форм. С версионированием тоже проблем нет. Тут скорее тестировщики выступают с тем, что не понятно, что означают некоторые сущности, какими они бывают, и главное как их на тесте генерировать, а бегать по нескольким статьям они не хотят
Основная проблема, скорее, находится в задачах, когда есть не самое "новое решение", которое начинают дорабатывать сразу несколько команд, причем с разных направлений. У них разные стандарты, по которым их работу оценивают их Лиды. Все тянут одеяло на себя. А если еще и исходная команда распалась, то совсем беда. Мы участвовали в нескольких проектах под условных названием "Единое окно", когда делают приложение, в которое "встраивается" всё, что было сделано до этого. и на таких проектах приходится изобретать велосипед и даже колесо)
Спасибо за комментарий! На самом деле второй подход я встретил только на последнем проекте. Сначала он казался абсурдным, но он показал свою жизнеспособность, так как: 1) часто приходилось дорабатывать решения других команд 2) многие решения являются устаревшими, не имеют спецификаций 3) Только происходит "переходный процесс" унификации всех направлений, при этом все равно все проекты в большей части живут своей жизнью (хотя общий технический стек). В таких реалиях приходится много вопросов отдавать на откуп разработчику и и ему приходится вникать в задачу. В новых решениях, конечно, однозначно первый вариант