"Балансировка бэклога", который позволяет командам самим определять, сколько времени они могут выделить на устранение технического долга
Как мне кажется, этот подход работает, потому что вы уже выросли и у вас уже есть продукт, который достиг, или почти достиг, точки кипения по скорости разработки/деплоя и т.д.
А как быть, или чтобы вы посоветовали, оглядываясь назад, когда идет фаза активного роста и техдолг создается вот прямо сейчас в угоду новых фич и развития проекта?
Прикольно видеть синтаксис модулей Angular и jsx в одном фреймворке, крутая работа! :)
Вопрос про экшены: если идет запрос на какой-то "секретный" API, который может отрабатывать дольше лимита и который не хотим светить клиенту, как в таком случае происходит перезапрос?
Если сесть и разобраться, когда уже есть готовый код перед глазами - то вполне, особенно если это будет знакомый стек - тот же язык или соседний фреймворк
Делал кандидатскую по машинному обучению и выступал с ней на конференции WMO в Франции, участник научного проекта по расчету переноса радиационных выбросов при аварии на АС - система внедрена и стоит на "вооружении" у государства.
Кроме этого, 9 лет коммерческого опыта разработки, запустил несколько крупных проектов с нуля, в том числе и на международном рынке, но санкции в 22 году поставили на них крест, к сожалению. В Тинькофф проработал архитектуру для нескольких больших продуктов Кассы, и сделал еще несколько внутренних инициатив.
Сейчас занимаюсь логистикой в Европе, если будете в Италии и отправите родным открытку - она с большой долей вероятности поедет через систему, которую я с коллегами строим в настоящий момент.
Тестовое задание я могу списать, или дать решить другому человеку, вопросы по стеку - заучить и подглядеть по ходу собеса.
Лайв-кодинг интервью направлены в первую очередь, чтобы оценить, как человек думает, какие решения он принимает и как он формулирует их в структуры данных. Если интервьер адекватный, он даже засчитает ее как плюс, даже если задача была не доведена до конца, но был набросан правильный план решения, и интервьеры тоже люди и в большинстве случаев тоже понимают, что не все решают алгоритмические задачи каждый день.
А вот если кандидат не способен за час интервью решить задачу про морской бой, у меня бы лично возникли сомнения, а можно ли такого кандидата вообще оценить выше уровня джуниор+
А как тогда все же писать сложные тяжелые запросы с несколькими уровнями вложенности, кучей джойнов и т.д.? Это получается такая же игра с синтаксисом и оптимизациями, только на уровне ORM-либы, а не SQL-запроса.
Я сам сторонник использования ORM, но некоторые запросы отладить и написать кажется гораздо проще на чистом SQL. Если вы используете ORM уже 13 лет, хотелось бы узнать ваш опыт по решению таких кейсов.
А в чем преимущество генерации SDK из SQL по сравнению с использованием ORM с поддержкой построения авто-миграций и генерации запросов?
Плюс как вы отслеживаете актуальность версии SDK: есть две команды, одна использует версию 1.0, вторая 1.1, выпускаете версию 1.2, в которой переименовываете табличку, а какой-то из клиентов все еще использует старое название?
А как вы теперь справляетесь с тестированием? Вот был монолит, большая связанность, тесты и моки (если есть) покрывают различные сервисы/базы/итд, все в одном месте и максимально переиспользуется (в теории). В пайплайне юнит и интеграционные тесты позволяют отловить какие-либо недокументированные изменения. Изменили табличку, упал юнит-тест, изменили DTO - упал интеграционный.
Теперь вместо таблички с списком стран - сервис стран, который нужно мокать, описывать его контракты у себя и т.д. Как теперь прогнать тесты, когда зависимость стала от внешнего сервиса, а не внутренней реализации. Например, сервис стран поменял контракт, но моки у вас остались старые, пайплайн прошел, а вот у пользователя на проде ошибки. Как вы такое отлавливаете, если не секрет?)
А как вы решали проблему дублирования функционала в сервисах при распиле? Вынос части функционала в новый сервис явно занимает не пару дней, как балансировать между переписыванием и новыми большими фичами, которые хочет бизнес? Делать их параллельно на php и C++ в монолите и микросервисе, или договаривались с бизнесом, что пока идет распил, вот конкретно эти фичи ставим на паузу?
Спасибо большое за статью, было очень интересно почитать про ваш тернистый путь по распилу и рефакторингу и стратегиям, которых вы придерживаетесь. После прочтения осталося несколько вопросов:
предварительно рассчитав предполагаемый RPS
А как вы рассчитывали, сколько ресурсов необходимо выделить на новый сервис? Вы знаете, какая нагрузка приходится на эту часть монолита, или вы сначала выделяете какой-то базовый лимит для 1% пользователей, потом увеличиваете их число до 10% от общего трафика, смотрите как себя чувствует сервис, и если что - подкручиваете новый лимит?
И второй вопрос: а как вы рассчитывали/прогнозировали время ответа после переезда на новый сервис? Вот был раньше джоин в несколько табличек в монолите, это занимает N миллисекунд на запрос, и мы знаем, что при высокой нагрузке этот запрос не просядет, а теперь надо пойти в несколько новых, как быть в данном случае?
У нас еще не сложилась четкая практика, когда стоит использовать глобальный, а когда компонентный стор. Но и у глобального есть свой плюс - например, если какой-то компонент должен взаимодействовать с данными, которые затем могут переиспользоваться в других местах.
В этом случае гораздо удобнее положить эти данные в глобальный стор, обновить их там и все нужные компоненты получат их автоматически. А с компонентным придется продумывать логику передачи этих данных по цепочке компонентов.
Спасибо, с использованием нового синтаксиса стало гораздо понятнее разрабатывать такие интерфейсы.
Интересно было бы почитать, как организовать виртуальный скролл без
material/cdkПоздравляю с релизом!
Как же приятно видеть, что теперь работа с чекбоксами и полями ввода стала настолько элегантной и лаконичной!
Снимаю шляпу 🎩
Как мне кажется, этот подход работает, потому что вы уже выросли и у вас уже есть продукт, который достиг, или почти достиг, точки кипения по скорости разработки/деплоя и т.д.
А как быть, или чтобы вы посоветовали, оглядываясь назад, когда идет фаза активного роста и техдолг создается вот прямо сейчас в угоду новых фич и развития проекта?
Прикольно видеть синтаксис модулей Angular и jsx в одном фреймворке, крутая работа! :)
Вопрос про экшены: если идет запрос на какой-то "секретный" API, который может отрабатывать дольше лимита и который не хотим светить клиенту, как в таком случае происходит перезапрос?
Еще один пунктик: облачный провайдер может сам стереть всю вашу инфраструктуру и данные совершенно случайно
Точнее: в 43% случаев новая версия справлялась так же или хуже.
Интересно узнать, сколько процентов из этих 43% было именно ухудшение переводов, и как оно исправлялось?
Прошу прощения за такой слишком прямой и перенасыщенный ответ ?
Но и в век интернета все довольно легко проверяется :)
Не знал про это, думал на все около-разработческие позиции это обязательный этап, спасибо за уточнение!
Если сесть и разобраться, когда уже есть готовый код перед глазами - то вполне, особенно если это будет знакомый стек - тот же язык или соседний фреймворк
Делал кандидатскую по машинному обучению и выступал с ней на конференции WMO в Франции, участник научного проекта по расчету переноса радиационных выбросов при аварии на АС - система внедрена и стоит на "вооружении" у государства.
Кроме этого, 9 лет коммерческого опыта разработки, запустил несколько крупных проектов с нуля, в том числе и на международном рынке, но санкции в 22 году поставили на них крест, к сожалению. В Тинькофф проработал архитектуру для нескольких больших продуктов Кассы, и сделал еще несколько внутренних инициатив.
Сейчас занимаюсь логистикой в Европе, если будете в Италии и отправите родным открытку - она с большой долей вероятности поедет через систему, которую я с коллегами строим в настоящий момент.
Я правильно понимаю, что вы в статье предлагаете исключить этот этап из процесса интервью?)
Тестовое задание я могу списать, или дать решить другому человеку, вопросы по стеку - заучить и подглядеть по ходу собеса.
Лайв-кодинг интервью направлены в первую очередь, чтобы оценить, как человек думает, какие решения он принимает и как он формулирует их в структуры данных. Если интервьер адекватный, он даже засчитает ее как плюс, даже если задача была не доведена до конца, но был набросан правильный план решения, и интервьеры тоже люди и в большинстве случаев тоже понимают, что не все решают алгоритмические задачи каждый день.
А вот если кандидат не способен за час интервью решить задачу про морской бой, у меня бы лично возникли сомнения, а можно ли такого кандидата вообще оценить выше уровня джуниор+
А как тогда все же писать сложные тяжелые запросы с несколькими уровнями вложенности, кучей джойнов и т.д.? Это получается такая же игра с синтаксисом и оптимизациями, только на уровне ORM-либы, а не SQL-запроса.
Я сам сторонник использования ORM, но некоторые запросы отладить и написать кажется гораздо проще на чистом SQL. Если вы используете ORM уже 13 лет, хотелось бы узнать ваш опыт по решению таких кейсов.
А в чем преимущество генерации SDK из SQL по сравнению с использованием ORM с поддержкой построения авто-миграций и генерации запросов?
Плюс как вы отслеживаете актуальность версии SDK: есть две команды, одна использует версию 1.0, вторая 1.1, выпускаете версию 1.2, в которой переименовываете табличку, а какой-то из клиентов все еще использует старое название?
А как вы теперь справляетесь с тестированием? Вот был монолит, большая связанность, тесты и моки (если есть) покрывают различные сервисы/базы/итд, все в одном месте и максимально переиспользуется (в теории). В пайплайне юнит и интеграционные тесты позволяют отловить какие-либо недокументированные изменения. Изменили табличку, упал юнит-тест, изменили DTO - упал интеграционный.
Теперь вместо таблички с списком стран - сервис стран, который нужно мокать, описывать его контракты у себя и т.д. Как теперь прогнать тесты, когда зависимость стала от внешнего сервиса, а не внутренней реализации. Например, сервис стран поменял контракт, но моки у вас остались старые, пайплайн прошел, а вот у пользователя на проде ошибки. Как вы такое отлавливаете, если не секрет?)
Спасибо большое за развернутый ответ!
А как вы решали проблему дублирования функционала в сервисах при распиле? Вынос части функционала в новый сервис явно занимает не пару дней, как балансировать между переписыванием и новыми большими фичами, которые хочет бизнес? Делать их параллельно на php и C++ в монолите и микросервисе, или договаривались с бизнесом, что пока идет распил, вот конкретно эти фичи ставим на паузу?
Спасибо большое за статью, было очень интересно почитать про ваш тернистый путь по распилу и рефакторингу и стратегиям, которых вы придерживаетесь. После прочтения осталося несколько вопросов:
А как вы рассчитывали, сколько ресурсов необходимо выделить на новый сервис? Вы знаете, какая нагрузка приходится на эту часть монолита, или вы сначала выделяете какой-то базовый лимит для 1% пользователей, потом увеличиваете их число до 10% от общего трафика, смотрите как себя чувствует сервис, и если что - подкручиваете новый лимит?
И второй вопрос: а как вы рассчитывали/прогнозировали время ответа после переезда на новый сервис? Вот был раньше джоин в несколько табличек в монолите, это занимает N миллисекунд на запрос, и мы знаем, что при высокой нагрузке этот запрос не просядет, а теперь надо пойти в несколько новых, как быть в данном случае?
У нас еще не сложилась четкая практика, когда стоит использовать глобальный, а когда компонентный стор. Но и у глобального есть свой плюс - например, если какой-то компонент должен взаимодействовать с данными, которые затем могут переиспользоваться в других местах.
В этом случае гораздо удобнее положить эти данные в глобальный стор, обновить их там и все нужные компоненты получат их автоматически. А с компонентным придется продумывать логику передачи этих данных по цепочке компонентов.
На мой взгляд "свой велосипед" - это практически всегда путь к легаси и рефакторингу, особенно если его поддерживает только один разработчик.