За редкими исключениями - очень плохо, на мой взгляд, если кто-то организовал продукт так, что работа над обычными фичами постоянно требует значимых ресурсов для анализа на дыры в безопасности.
Не надо писать даже в MVP-фиче то, что поставит раком нагруженную базу при согласованных ограничениях развертывания MVP. Часто можно дешевле сделать фичу, которая "не ставит раком базу", если заранее известно, что с ней будет работать, скажем, не более 5% от общего числа юзеров и на интервале, скажем, не более 6 месяцев.
Уверены, что знаете что такое MVP, когда пишете, что он не должен встречаться с реальными пользователями и живыми данными?
На всякий случай замечу, что из вашего описания не понял, в чем же проблема в этом проекте в итоге была у компании. Провалили дедлайн? Качество? Бюджет? Не сделали все фичи?
Из описания - да, иногда так можно растить из джунов в сеньёры, если есть откуда брать подходящие задачи класса "не бей лежачего" + "выкинуть через полугода", ну и повышать градус постепенно. Особенно хорошо заходит, когда есть какие-то образцы кодовой базы, откуда джуны могут черпать мудрость.
Я правильно понял, что СТО сначала допустил самостоятельную работу 3 джунов приведшую к серьезному техдолгу, а затем еще и не смог корректно его оценить? Т.к. между "два человекогода" и "полгода параллельно основной работе" разница очень серьезная.
Это МОЖЕТ не тормозить, если грамотно это использовать. В прошлом году разбирал рабочий пример, человек запиливает на Spring Boot / Hibernate сервис, который умудряется карточку контрагента с десятком полей читать из БД по 30 секунд, просто потому что настроил ORM и вызовы её так, что при этом с карточкой контрагента извлекают все его сотни магазинов и тысячи сотрудников со всеми их параметрами. После модификации запрос выполняется за 0.5 сек.
Звучит волшебно, снимаю шляпу по поводу того, как у вас организован процесс, если 300 разработчиков не мешают друг другу с релизами, видимо, несколько раз в неделю.
Прочитал, спасибо. Кстати, в appsignal форпост постоянно стучится в цитадель, да еще и асинхронно через кафку. Так что вся эта история с цитаделью и форпостами - по сути про микросервисы, как бы не хотелось сделать вид, что это не они. И да, видимо вы тоже их применяете, надеюсь успешно :)
Можно тогда пример форпоста? Потому что если он самодостаточен и ходит к соседям не часто, то он прям совсем хороший микросервис. А в целом, откуда это название "форпост", сами придумали или это какой-то более менее сложившийся шаблон и где-то можно прочитать, чтобы вас не мучать вопросами?
Поясню про асинхронность. У вас форпост стучиться в монолит с некоторой регулярностью и либо он должен туда стучаться, условно, очень часто, либо мы будем добавлять задержку в среднем в половину периода опроса.
Интересный и масштабный опыт, моё уважение! А сколько у вас проходит от постановки задачи до появления фичи в продакшене? Как вы скейлите по нагрузке свой модульный монолит? Запускаете десяток инстансов?
Из всего выходит так, что форпост = микросервис, да еще и с микрофронтендом. И очень странно, что админ туда у вас не ходит. А то что вы решили отстрелить микросервису ногу (асинхронность) - ну такой себе "плюс".
Если не секрет, какого максимального масштаба продукты вы разрабатывали, сколько разработчиков/команд в них было, сколько было бизнес-доменов (см. Domain Driven Design), сколько длился самый длинный проект?
Монолитное приложение характеризуется высокой связанностью частей системы.
На мой взгляд классическое "смешать тёплое с мягким". Можно сильно запутать между собой микрофронтенды, аналогично тому, как из микросервисов создают "распределенный монолит". А можно создать слабо связанное между модулями одно веб-приложение.
Концепция и конкретная реализация - сильно разные вещи. Эволюционный отбор как раз позволил выработать достаточный уровень громкости и понятность другим крика боли. Как эффективно вопить на весь космос о боли - та еще задача. В указанном произведении, как максимум, раскрывались координаты звездной системы.
Первый шаг к устройству такого союза — оповещение потенциальных жертв об охотнике. Этот принцип настолько всеобъемлющ, что присутствует даже у неразумных существ. Да, я о криках испуга или боли, издаваемых особями, схваченными хищником. Саму жертву они не спасают, но помогают выжить другим членам стаи, закрепляя, таким образом, этот паттерн через эволюционный отбор.
Как вам удалось применить подходы эволюционного отбора к цивилизациям? Сколько поколений "скрещиваний" и "отмираний" цивилизаций может привести к закреплению этого паттерна, учитывая, что отправка сигнала "боли" достаточно ресурсоёмка, а в случае нападения ресурсов скорее всего будет не хватать на оборону?
Скорее всего не просто мало, а экстремально мало.
Скорее всего целесообразнее будет поменять место работы.
Назовите уровень оплаты создавшего это и будет гораздо проще угадать, кто виноват.
За редкими исключениями - очень плохо, на мой взгляд, если кто-то организовал продукт так, что работа над обычными фичами постоянно требует значимых ресурсов для анализа на дыры в безопасности.
Не надо писать даже в MVP-фиче то, что поставит раком нагруженную базу при согласованных ограничениях развертывания MVP. Часто можно дешевле сделать фичу, которая "не ставит раком базу", если заранее известно, что с ней будет работать, скажем, не более 5% от общего числа юзеров и на интервале, скажем, не более 6 месяцев.
Уверены, что знаете что такое MVP, когда пишете, что он не должен встречаться с реальными пользователями и живыми данными?
На всякий случай замечу, что из вашего описания не понял, в чем же проблема в этом проекте в итоге была у компании. Провалили дедлайн? Качество? Бюджет? Не сделали все фичи?
Из описания - да, иногда так можно растить из джунов в сеньёры, если есть откуда брать подходящие задачи класса "не бей лежачего" + "выкинуть через полугода", ну и повышать градус постепенно. Особенно хорошо заходит, когда есть какие-то образцы кодовой базы, откуда джуны могут черпать мудрость.
Я правильно понял, что СТО сначала допустил самостоятельную работу 3 джунов приведшую к серьезному техдолгу, а затем еще и не смог корректно его оценить? Т.к. между "два человекогода" и "полгода параллельно основной работе" разница очень серьезная.
Это МОЖЕТ не тормозить, если грамотно это использовать. В прошлом году разбирал рабочий пример, человек запиливает на Spring Boot / Hibernate сервис, который умудряется карточку контрагента с десятком полей читать из БД по 30 секунд, просто потому что настроил ORM и вызовы её так, что при этом с карточкой контрагента извлекают все его сотни магазинов и тысячи сотрудников со всеми их параметрами. После модификации запрос выполняется за 0.5 сек.
Звучит волшебно, снимаю шляпу по поводу того, как у вас организован процесс, если 300 разработчиков не мешают друг другу с релизами, видимо, несколько раз в неделю.
Прочитал, спасибо. Кстати, в appsignal форпост постоянно стучится в цитадель, да еще и асинхронно через кафку. Так что вся эта история с цитаделью и форпостами - по сути про микросервисы, как бы не хотелось сделать вид, что это не они. И да, видимо вы тоже их применяете, надеюсь успешно :)
Тут я ожидал ответ вида "в среднем N недель".
Можно тогда пример форпоста? Потому что если он самодостаточен и ходит к соседям не часто, то он прям совсем хороший микросервис. А в целом, откуда это название "форпост", сами придумали или это какой-то более менее сложившийся шаблон и где-то можно прочитать, чтобы вас не мучать вопросами?
Поясню про асинхронность. У вас форпост стучиться в монолит с некоторой регулярностью и либо он должен туда стучаться, условно, очень часто, либо мы будем добавлять задержку в среднем в половину периода опроса.
Интересный и масштабный опыт, моё уважение! А сколько у вас проходит от постановки задачи до появления фичи в продакшене? Как вы скейлите по нагрузке свой модульный монолит? Запускаете десяток инстансов?
Из всего выходит так, что форпост = микросервис, да еще и с микрофронтендом. И очень странно, что админ туда у вас не ходит. А то что вы решили отстрелить микросервису ногу (асинхронность) - ну такой себе "плюс".
Пара вопросов:
Если не секрет, какого максимального масштаба продукты вы разрабатывали, сколько разработчиков/команд в них было, сколько было бизнес-доменов (см. Domain Driven Design), сколько длился самый длинный проект?
Чем "форпост" отличается от микросервиса?
Если тут 0 не лишний, то выглядит как серьезнейшая проблема.
На мой взгляд классическое "смешать тёплое с мягким". Можно сильно запутать между собой микрофронтенды, аналогично тому, как из микросервисов создают "распределенный монолит". А можно создать слабо связанное между модулями одно веб-приложение.
На мой взгляд если вам не надо релизиться независимо, то скорее всего микрофронтенды будут ненужным оверхедом.
"Сборка релиза" убивает большую часть отличий микрофронтендов от модульного фронта.
Мечтал о 3000$/месяц, а получил ... много "бесценного опыта"? (с) кто-то
Очень смелое утверждение, впрочем как и это:
Концепция и конкретная реализация - сильно разные вещи. Эволюционный отбор как раз позволил выработать достаточный уровень громкости и понятность другим крика боли. Как эффективно вопить на весь космос о боли - та еще задача. В указанном произведении, как максимум, раскрывались координаты звездной системы.
Как вам удалось применить подходы эволюционного отбора к цивилизациям? Сколько поколений "скрещиваний" и "отмираний" цивилизаций может привести к закреплению этого паттерна, учитывая, что отправка сигнала "боли" достаточно ресурсоёмка, а в случае нападения ресурсов скорее всего будет не хватать на оборону?