Чет думал-думал, писал-писал продолжение предыдущего поста, какие-то там пункты чето как-то формулировал, но потом понял, что тут даже и по пунктам раскладывать не надо. Все, что нужно было сделать иначе в этом проекте, это нормально его спроектировать. И чем больше команда и масштабней проект, тем детальней всё это надо расписывать. Какие мэйлстоуны? Кто ответственные? Какие новые фичи? Какие старые фичи? Как тестировать? Как интегрироваться? Зачем GRPC? Зачем распиливать на микросервисы? В каком порядке всё это пилить? Где команда может ознакомиться с результатами проектирования? Если на эти и подобные вопросы нет ответов, то это не должно проходить ревью и передаваться дальше в работу.    Отдельно отмечу про переписывание проекта с нуля. Вот это вообще для меня загадка, как такое получилось продать бизнесу. ИМХО, хоть все и говорят (скорее рофлят) всегда, мол, вот, тут только выбросить на помойку и написать с нуля, но в реальности это настолько должен быть исключительный случай, настолько там должны быть убедительные аргументы чтобы всё дропнуть и начать кодить с нуля, что я бы даже сказал, что это какие-то 1% проектов, где вот иначе никак и вот прям надо. В остальных случаях лучше переписывать параллельно и постепенно: сохраните нервы себе и своей команде и сохраните деньги заказчика 👍    Про всё остальное, про GRPC, про микросервисы, еще какие-то архитектурные решения в этом проекте, тут даже сказать особо нечего, просто выглядит как недоработка конкретного "архитектора", которые вроде обычно достаточно прошаренные челы, но вот тут походу был не очень, что уж греха таить. Не знаю тоже, какие шишули там надо было курить и как вообще всё это прошло ревью дальше, но вот было что было.    Еще раз: больше проектируйте проекты, особенно, если это чьи-то деньги. Потратьте x2 времени на анализ, встречи и обсуждения, документирование вообще всего, и попробуйте донести, что здесь нельзя экономить время и пушить всё быстрее-быстрее закрыть, потому что иначе на разработке потом будет у вас обсёр жопы.