Проблем из-за того, что разработчики вносили несовместимые изменения в микросервисы не было?
На старте проекта были, потом научились бороться.
Как их избегали?
За последний год полностью всё публичное апи генерируется на основе OPEN-api спек (swagger 3.0, так же пришлось кастомных генераторов написать, ибо стандартный под джаву далеко не всё умеет генерировать, хотя спека вроде как и позволяет это делать), проблема ушла сама собой. Условно репозиторий с апи-спеками один общий на всю систему. Ты завязываешься на product-api v.1.x.x.x и у тебя гарантированно не будет проблем что /api/v1/ вдруг получит потерю обратной совместимости + для всех сервисов генерируются врапперы для вызовов. Да, немного избыточно, но весь код автогенерируется, с точки зрения разработчика нужно написать только yaml со спекой. Если же версия становится v.2.x.x.x просто сборка упадёт, ибо все импорты нужно менять. В этот момент придётся править вызовы апишек и т.д. И да, такой подход заставляет ещё тратить время на проектирование АПИ, перед тем как что-то начинать делать. Оверхэд примерно 10% от общих трудозатрат на задачку. Зато ОЧЕНЬ удобно лиду сформировать совместно с архитекторами апи и отдать на реализацию джуну/мидлу, Который просто не имеет шанса наделать себе в штаны.
Размер приложения: примерно 25 бэкендных микросервисов и около 10 фронтэндов. На фронтах, к сожалению, не генерируем по спекам, ибо оказалось это очень неудобным. Да и в целом, отвал фронтов обычно не является блокером для системы, ибо наши фронты это скорее конфигурационные тулы + парочка бизнесовых.
А потом «молодые дарования» в слезах покидают фирму, потому что им указали на говно в их коде на очередном ревью мёрдж реквеста. Знаем, плавали. Уже тошнит от этой всеобщей натянутой вежливости там, где это ну совершенно не нужно. Не на приёме же у королевы.
У нас в фирме есть продукт (на самом деле много продуктов, думаю порядка 10). Но каждое внедрение это проект. Чаще всего первое внедрение (решение проблемы заказчика) это проект, который при повторной продаже обязан превратиться в новый продукт. И вот тут начинается самое интересное: трансформация проекта в продукт. Когда необходимо отрезать всё лишнее, но не убить возможность сверху навернуть специфику нового проекта.
С точки зрения сложности первое внедрение самое простое, второе самое сложное (ибо уши первого заказчика торчат из всех щелей). 3+ внедрение уже идёт по накатанной. Ну и нужно учитывать, что деньги фирма начинает зарабатывать чаще всего только после 3 внедрения. Ибо на первом собирает все шишки, на втором тратит большое количество ЛОЕ на рефакторинг.
В статье не хватает обзора «проекта/продукта» с точки зрения симбиоза. Было бы интересно почитать мысли автора на этот счёт.
Тут главная ошибка в том, что это не одна задача, а целая куча задач. Необходимо для начала сделать груминг. Итого у вас примерно выйдет следующий набор эпиков:
Функциональный блок:
Уметь строить отчёты;
Уметь строить статистику;
Уметь настраивать фильтрации;
Не функциональный блок:
Время выполнения менее 3х секунд;
Отчёт в реальном времени;
Бизнес-блок:
Список необходимых отчётов;
Дальше будет приоритезация. Строить отчёт и статистика, это максимальный приоритет. Без этого бизнес не может начинать работу. В этот момент фильтрации для списка необходимых отчётов можно захардкодить, а по поводу 3х секунд и реального времени, ну такое. Для начала нужно хотя бы РоС сделать. Нужен ли UI сразу или достаточно вывести в эксель, тоже вопрос для обсуждения. Итого эти задачки можно разбить на 2-3 спринта и обозначить возможные риски. Так же не забываем, что каждый эпик разбивается ещё на истории.
На сумму от 100к рублей не дадут на платёж свыше 50% от белого дохода за вычетом иждевенцев, их считают за МРОТ. Условно если у вас зарплата 100к + жена в декрете с ребёнком, то выйдет: (100к — 12к — 12к) / 2 = 38к. Дадут кредит с максимальным платежом 38 тысяч в месяц. В расчёт не беру всякие бандитские займы.
Самое смешное, что после аудита может вскрыться что нужно не 16 миллионов, а, например, 25… А фирма, которая должна была исполнять заказ просто переоценила свои силы.
Так, и что из этого G900, а что офисная китайская мышь за $2?
Вроде как речь шла про сравнение брендовых мышей и нонейм говна за 3 копейки. Так то очевидно, что геймерские мышки в плане сенсора все примерно равны, но ценник стартует с 2к рублей (на каком нибудь g102 уже не стыдно играть).
Некоторые не ощущают разницу в звуке между гитарой табуретной фабрики им. Красного октября и средненьким фендером. Вы вот не ощущаете разницы в мышках, бывает.
Есть реальность, которая очень хорошо ощущается. Например в шутерах. Я суммарно наиграл несколько тысяч часов в Counter-Strike 1.6, Source и GO. Могу сказать за себя, хорошая мышка ОЧЕНЬ сильно решает в плане чёткости наведения и движений в целом. Некоторые вещи попросту невозможно сделать на офисной/медленной/беспроводной (из-за хреновой связи) мышке. Я так понимаю вы далеки от мира игр, но погуглите ради интереса в контексте Couner-Strike: Global Offensive: flick shot (при исполнении на плохой мышке прицел улетит вверх/вниз экрана), spray control + spray transfer (при исполнении на плохой мышке много пуль улетит «не туда» из-за этих самых «неровных кругов», траектория движения должна быть идеально выверенной, на уровне рефлексов). Обе этих вещи невозможны на офисных мышках из-за технических ограничений оных.
Почти все прогеймеры во всех играх (разве что кроме карточных, типа хёртстоуна) используют хват ладонью и двигают мышь предплечьем, кистью/пальцами же делают небольшие доводки.
На старте проекта были, потом научились бороться.
За последний год полностью всё публичное апи генерируется на основе OPEN-api спек (swagger 3.0, так же пришлось кастомных генераторов написать, ибо стандартный под джаву далеко не всё умеет генерировать, хотя спека вроде как и позволяет это делать), проблема ушла сама собой. Условно репозиторий с апи-спеками один общий на всю систему. Ты завязываешься на product-api v.1.x.x.x и у тебя гарантированно не будет проблем что /api/v1/ вдруг получит потерю обратной совместимости + для всех сервисов генерируются врапперы для вызовов. Да, немного избыточно, но весь код автогенерируется, с точки зрения разработчика нужно написать только yaml со спекой. Если же версия становится v.2.x.x.x просто сборка упадёт, ибо все импорты нужно менять. В этот момент придётся править вызовы апишек и т.д. И да, такой подход заставляет ещё тратить время на проектирование АПИ, перед тем как что-то начинать делать. Оверхэд примерно 10% от общих трудозатрат на задачку. Зато ОЧЕНЬ удобно лиду сформировать совместно с архитекторами апи и отдать на реализацию джуну/мидлу, Который просто не имеет шанса наделать себе в штаны.
Размер приложения: примерно 25 бэкендных микросервисов и около 10 фронтэндов. На фронтах, к сожалению, не генерируем по спекам, ибо оказалось это очень неудобным. Да и в целом, отвал фронтов обычно не является блокером для системы, ибо наши фронты это скорее конфигурационные тулы + парочка бизнесовых.
С точки зрения сложности первое внедрение самое простое, второе самое сложное (ибо уши первого заказчика торчат из всех щелей). 3+ внедрение уже идёт по накатанной. Ну и нужно учитывать, что деньги фирма начинает зарабатывать чаще всего только после 3 внедрения. Ибо на первом собирает все шишки, на втором тратит большое количество ЛОЕ на рефакторинг.
В статье не хватает обзора «проекта/продукта» с точки зрения симбиоза. Было бы интересно почитать мысли автора на этот счёт.
Функциональный блок:
Не функциональный блок:
Бизнес-блок:
Дальше будет приоритезация. Строить отчёт и статистика, это максимальный приоритет. Без этого бизнес не может начинать работу. В этот момент фильтрации для списка необходимых отчётов можно захардкодить, а по поводу 3х секунд и реального времени, ну такое. Для начала нужно хотя бы РоС сделать. Нужен ли UI сразу или достаточно вывести в эксель, тоже вопрос для обсуждения. Итого эти задачки можно разбить на 2-3 спринта и обозначить возможные риски. Так же не забываем, что каждый эпик разбивается ещё на истории.
Вроде как речь шла про сравнение брендовых мышей и нонейм говна за 3 копейки. Так то очевидно, что геймерские мышки в плане сенсора все примерно равны, но ценник стартует с 2к рублей (на каком нибудь g102 уже не стыдно играть).