В микросервисах обычно не позволяют кому-попало в базу лезть своими руками немытыми.
Есть у меня на примете вполне рядовой и понятный пример: таблица с пользовательскими данными, которые нужны множеству потребителей. То есть одно приложение управляет данными, другие их читают, ожидая определенный формат. Как в таких случаях быть? Все 20 команд направлять делать одновременно изменения? Ни дублирование пользовательских данных, ни какая-то модификация на лету не будут правильными решениями с точки зрения управления разработкой, так как "чем больше костылей, тем громче они упадут".
Всегда было интересно, как при таком подходе решили такие задачи (упрощено для обсуждения): 1. Нужно изменить одну функцию, которая затрагивает 20 других сервисов. При этом эти в этих сервисах еще нет изменений (и текущая команда не может их сделать, делают другие команды). При этом нужна миграция данных. Пример: хочу в БД хранить массив JSON'ов вместо одного JSON'а, аналогичные конструкции записывать в БД, это используют 20 потребителей через вычитку из БД. 2. Как делать хотфикс, если функционал из убежавшего вперед мастера еще не должен быть выпущен? Аналогично Git Flow? 3. Как при таком подходе делать рефакторинг? Или все-таки пропущен процесс управления, разрешающий, к примеру, только ATDD и не менее 99.5% покрытия?
Если для API предусмотрен контракт с версионностью, обратной совместимостью и интеграционными тестами, то на уровне приложения изменения выглядят следующим образом: меняем код -> меняем unit-тесты. И зачем они тогда вообще нужны? Если на уровне бизнес-требований все покрыто тестами, то какая мне разница что там под капотом меняется?
Всегда считал unit-тесты чем-то почти бесполезным. Они легко увеличивают трудозатраты на разработку в полтора и более раз. А долгосрочной пользы от них я не вижу. Другое дело - полноценные интеграционные и системные тесты. А еще лучше посмотреть в сторону ATDD. Да, разработчик и автотесты на кейсах, и сам код пишет/конструктор использует. Увеличивает бюджет в краткосрочной перспективе. В долгосрочной - продукт с минимумом багов, который без проблем лет 5 проработает. Если еще и с продуманной архитектурой - части системы можно изолированно заменять на более современные с некоторой периодичностью - продукт и 50 лет проживет.
Просьба сделать статью (серию статей) про организацию серверной комнаты (с планами и субъективными комментарии). Относится ко всем заинтересованным — кинье ссылкой (ами).
И почему в этой статье нет ни одного австрийца (европейца)? По опыту сотрудничества с Райфом — они на приоритетные проекты главными австрийцев (европейцев) назначают. Даже если они не разбираются в теме.
Что-то тут не так. Либо не в приоритете все это.
UPD: хотя в статье же нет проектных и линейных менеджеров, которые все решения принимают; все понятно.
Проходил через почти все. На каком-то этапе сбор тестового проекта начинает быть похожим на сборку-разборку-подпирание-перепланирование-сборку и т.д. дома. То есть очень долго, тяжело, много истории (кода, миграций), забытая логика, неотслеживаемые баги...
Одномоментные миграции запросами прямо в базу — заманчиво, очень заманчиво, но не в энтэрпрайзе.
Если приложение большое, то я выбираю подход "циклической эволюции". Миграции делаем только на мажорных версиях приложения. Минорные — без изменений в базе. Делаем микросервисы, где возможно, чтобы раздробить миграции несколькими базами. Когда история миграций доходит до критической отметки (можно научно определить, а можно субъективно), то пишем новую версию приложения/микросервиса (не допиливаем мажорную, а пишем с нуля), делаем миграцию в него и заново начинаем наращивать миграции.
Сложно? Разработчики довольны, что пишут новое, а не ковыряются в старом, архитектор пересматривает базовые решения (иначе не мог бы) в пользу оптимальных, старые языки/фреймворки и т.п. заменяются новыми, четкая и понятная бизнес-логика. Кто на поддержке наследия мамонтов работал, тот точно оценит.
Так это к аналитику или владельцу продукта тогда. Это один из признаков наличия у них минимального (я подчеркиваю это) опыта — понятная разработчику постановка задачи (из этого вытекает необходимость привлечения разработчика для ревью).
PM в данном случае только процесс коммуникации может наладить, если у аналитика или владельца продукта не хватает опята для этого.
Мне, как PM'у, не очень понятен момент, где я должен влиять на культуру разработки. Может, я другой смысл вкладываю в эти слова, поэтому прошу пояснить.
Судя по вашим ответам (без конкретики по ускорению и стабильности — не указаны статистические данные при заявленном ускорении в 15 раз; так и не получил никаких конкретных пояснений по версионности и веткам в Git, только общие пояснения), у вас SOA, а не микросервисы (увидел только одно место, где может быть микросервис); очень скромный функционал (только мобильный клиент со скромным для универсального (без жесткой специализации — кредитный или обменный) банка функционалом, если судить по описанным сервисам), который можно и монолитом с мажорной версионностью делать быстро и просто без особых трудностей. Как вывод, с учетом ваших ответов, использование микросервисов и ряда представленных решений здесь экономически и технически нецелесообразно.
Уточняю по третьему вопросу: если в системе используется интеграция с несколькими вендорами (такими, как BankMaster) — идет типизация и перетипизация счетов для продуктов запросами во внешние системы. Из-за этого никаких адекватных (быстрых) вариантов с кэшем быть не может. Как реализовано у вас?
Уточняю по второму вопросу: как именно вы обходите конфликт версий? Если версия 1.4.123, к примеру, использовала адрес клиента одной строкой, а в новой версии 1.5.0 необходимо использовать две строки, то как вы это обходите? Делаете костыль для склеивания строк для старой версии (соответветственно, это идет адаптация под старые версии), дублируете данные (для старой и для новой версии), изначально предусматриваете в старой версии гибкость (дозагрузка атрибутов и ключей с бэка — в приложении просто абстрактная логика работы с тремя-четырьмя типами полей), предусматриваете более жесткие меры (отключение функционала для старых версий)?
Следует из названия Scrum и его принципов. Товарищ все верно написал.
Scrum изначально сделан для авральной ситуации, когда стейкхолдеров много, когда стейкхолдеры не могут или не хотят договариваться, нет понимания ограничений (capacity), нужно быстро делать изменения, качество приносится в жертву частым релизам (именно так — достаточно почитать Scrum: The Art of Doing Twice the Work in Half the Time — к слову, в книге нет ни слова про то, как продукт поддерживался после разработки, а это очень хитрый и важный момент).
Именно поэтому я придумал более продвинутый фреймворк, который дает средний стабильный результат как в краткосрочной, так и в долгосрочной перспективе. Обкатываю.
Проблема Scrum в мотивации в долгосрочной перспективе.
Команда наемных программистов в итоге просто делает все медленно, так как в скорости заинтересован лишь владелец/клиент (про качество скажут пару раз — теперь это забота разработки — кто уже это вспомнит через год-два?..). И многие даже не заметят этого, если не будут иметь аудит или консалтинг. Не заметят, пока бюджет не будет превышен или продукт не будет очень плохим (про качество владелец/клиент уже вспомнит, когда получит отток пользователей и придет «разбираться»).
Можно тут сказать про премию и нематериальные поощрения — инженер, который проработал с этим 10 лет, просто будет улыбаться и очень убедительные доводы приводить. Уходить по часам — ведь он и так другую работу найдет, если что. И будет скрам-мастер всякую дичь предлагать, будут совещаться… Банкротство.
Именно поэтому я придумал более совершенный фреймворк, чем Scrum, Kanban, Scrumban, SAFe, LeSS, DaD… Намного проще, намного приятнее. Без подмены понятий. Обкатываю сейчас. Пока полет отличный. Если смогу убедиться, что все в рамках моих ожиданий, то поделюсь с миром и мир вздохнет с облегчением.
Не один. Тут даже архитектурно у них микросервисы нарисованы, а по рисунку и описанию дальше — чистый веб SOA. Вот Middle сервис счетов — это уже не микросервис, а часть веб SOA; сервис вызывается, когда данные отличаются от хранимых в кэше, что еще раз не микросервисная реализация. При этом написано, что данные обновляются только, если они изменились, при этом: «сервис получает сообщение о входе пользователя в приложение и сразу же обновляет данные по счетам»… Могу единственно предположить, что говорится про запуск проверки актуальности данных. Так?
Ряд вопросов:
1. Как именно вы поддерживаете совместимость мобильного и веб клиентов с логикой бэка (совместимость старых версий через подмену статусов и логики из новых)?
2. Как идет разработка и поставка мобильного клиента и интеграции в бэке (отдельная ветка в Git для каждой версии клиента и описание интеграции в бэке под каждую версию или как-то иначе)? Сюда же неплохо было бы пояснение про стабильные релизы и вашу версионность — тема не раскрыта.
3. Как именно идет обработка счетов (так как счета нужны практически для любых продуктов банка)? Что за логика под Middle сервисом счетов?
4. Как у вас организовано получение данных клиента (так как данные клиента нужны для любых продуктов банка)? Все хранится в какой-то БД и подгруажется в кэш? Или внешняя система -> кэш? Шина -> кэш? Как обеспечивается отказоустойчивость?
5. В случае критической ошибки на минорной версии (например, берется не тот счет для операции, что не противоречит автотестам, но противорчит логике) — она у вас сразу деплоится с ошибкой? Не слишком ли это рискованно?
6. Как у вас организован процесс электронной подписи? Вы храните подпись где-то или клиент каждый раз для каждого сервиса должен подгружать ключ?
Там сейчас очень много глупостей пишут и говорят. Поверьте, на наемной работе менеджера мне абсолютно все равно, какого вы пола, цвета, возраста, национальности, религии, ориентации и т.д. Для меня важно качество работы, моя мотивация и комфорт тех нескольких человек, с которыми я дружу из-за сочетания характеров.
Опять же аргумент в пользу выбора крупных компаний невалиден.
Как корпоративное звено, могу ответить просто — RN очень легко «продать» (получить спонсорство, финансирование). То есть я могу легко собрать пять статей, где его расхваливают, рассказать про одно приложение на две платформы силами только дешевой JS разработки, большое стабильное сообщество со звездами у репозиториев, множество библиотек, универсальные автотесты, примеры от многих компаний. Все это под соусом позитива (хотя в каждом пункте есть нюансы, которые уничтожат возможность развития продукта на каком-то этапе).
Flutter на данный момент я не могу «продать», не хватает материала для убеждения, статей, где кто-то брызжа слюной доказывает (аналогия с RN), что он космос.
Вот и все.
Есть у меня на примете вполне рядовой и понятный пример: таблица с пользовательскими данными, которые нужны множеству потребителей. То есть одно приложение управляет данными, другие их читают, ожидая определенный формат. Как в таких случаях быть? Все 20 команд направлять делать одновременно изменения? Ни дублирование пользовательских данных, ни какая-то модификация на лету не будут правильными решениями с точки зрения управления разработкой, так как "чем больше костылей, тем громче они упадут".
Всегда было интересно, как при таком подходе решили такие задачи (упрощено для обсуждения):
1. Нужно изменить одну функцию, которая затрагивает 20 других сервисов. При этом эти в этих сервисах еще нет изменений (и текущая команда не может их сделать, делают другие команды). При этом нужна миграция данных.
Пример: хочу в БД хранить массив JSON'ов вместо одного JSON'а, аналогичные конструкции записывать в БД, это используют 20 потребителей через вычитку из БД.
2. Как делать хотфикс, если функционал из убежавшего вперед мастера еще не должен быть выпущен? Аналогично Git Flow?
3. Как при таком подходе делать рефакторинг? Или все-таки пропущен процесс управления, разрешающий, к примеру, только ATDD и не менее 99.5% покрытия?
Если для API предусмотрен контракт с версионностью, обратной совместимостью и интеграционными тестами, то на уровне приложения изменения выглядят следующим образом: меняем код -> меняем unit-тесты. И зачем они тогда вообще нужны? Если на уровне бизнес-требований все покрыто тестами, то какая мне разница что там под капотом меняется?
Всегда считал unit-тесты чем-то почти бесполезным. Они легко увеличивают трудозатраты на разработку в полтора и более раз. А долгосрочной пользы от них я не вижу. Другое дело - полноценные интеграционные и системные тесты. А еще лучше посмотреть в сторону ATDD. Да, разработчик и автотесты на кейсах, и сам код пишет/конструктор использует. Увеличивает бюджет в краткосрочной перспективе. В долгосрочной - продукт с минимумом багов, который без проблем лет 5 проработает. Если еще и с продуманной архитектурой - части системы можно изолированно заменять на более современные с некоторой периодичностью - продукт и 50 лет проживет.
Просьба сделать статью (серию статей) про организацию серверной комнаты (с планами и субъективными комментарии). Относится ко всем заинтересованным — кинье ссылкой (ами).
И почему в этой статье нет ни одного австрийца (европейца)? По опыту сотрудничества с Райфом — они на приоритетные проекты главными австрийцев (европейцев) назначают. Даже если они не разбираются в теме.
Что-то тут не так. Либо не в приоритете все это.
UPD: хотя в статье же нет проектных и линейных менеджеров, которые все решения принимают; все понятно.
Проходил через почти все. На каком-то этапе сбор тестового проекта начинает быть похожим на сборку-разборку-подпирание-перепланирование-сборку и т.д. дома. То есть очень долго, тяжело, много истории (кода, миграций), забытая логика, неотслеживаемые баги...
Одномоментные миграции запросами прямо в базу — заманчиво, очень заманчиво, но не в энтэрпрайзе.
Если приложение большое, то я выбираю подход "циклической эволюции". Миграции делаем только на мажорных версиях приложения. Минорные — без изменений в базе. Делаем микросервисы, где возможно, чтобы раздробить миграции несколькими базами. Когда история миграций доходит до критической отметки (можно научно определить, а можно субъективно), то пишем новую версию приложения/микросервиса (не допиливаем мажорную, а пишем с нуля), делаем миграцию в него и заново начинаем наращивать миграции.
Сложно? Разработчики довольны, что пишут новое, а не ковыряются в старом, архитектор пересматривает базовые решения (иначе не мог бы) в пользу оптимальных, старые языки/фреймворки и т.п. заменяются новыми, четкая и понятная бизнес-логика. Кто на поддержке наследия мамонтов работал, тот точно оценит.
Так это к аналитику или владельцу продукта тогда. Это один из признаков наличия у них минимального (я подчеркиваю это) опыта — понятная разработчику постановка задачи (из этого вытекает необходимость привлечения разработчика для ревью).
PM в данном случае только процесс коммуникации может наладить, если у аналитика или владельца продукта не хватает опята для этого.
Мне, как PM'у, не очень понятен момент, где я должен влиять на культуру разработки. Может, я другой смысл вкладываю в эти слова, поэтому прошу пояснить.
Уточняю по второму вопросу: как именно вы обходите конфликт версий? Если версия 1.4.123, к примеру, использовала адрес клиента одной строкой, а в новой версии 1.5.0 необходимо использовать две строки, то как вы это обходите? Делаете костыль для склеивания строк для старой версии (соответветственно, это идет адаптация под старые версии), дублируете данные (для старой и для новой версии), изначально предусматриваете в старой версии гибкость (дозагрузка атрибутов и ключей с бэка — в приложении просто абстрактная логика работы с тремя-четырьмя типами полей), предусматриваете более жесткие меры (отключение функционала для старых версий)?
Scrum изначально сделан для авральной ситуации, когда стейкхолдеров много, когда стейкхолдеры не могут или не хотят договариваться, нет понимания ограничений (capacity), нужно быстро делать изменения, качество приносится в жертву частым релизам (именно так — достаточно почитать Scrum: The Art of Doing Twice the Work in Half the Time — к слову, в книге нет ни слова про то, как продукт поддерживался после разработки, а это очень хитрый и важный момент).
Команда наемных программистов в итоге просто делает все медленно, так как в скорости заинтересован лишь владелец/клиент (про качество скажут пару раз — теперь это забота разработки — кто уже это вспомнит через год-два?..). И многие даже не заметят этого, если не будут иметь аудит или консалтинг. Не заметят, пока бюджет не будет превышен или продукт не будет очень плохим (про качество владелец/клиент уже вспомнит, когда получит отток пользователей и придет «разбираться»).
Можно тут сказать про премию и нематериальные поощрения — инженер, который проработал с этим 10 лет, просто будет улыбаться и очень убедительные доводы приводить. Уходить по часам — ведь он и так другую работу найдет, если что. И будет скрам-мастер всякую дичь предлагать, будут совещаться… Банкротство.
Именно поэтому я придумал более совершенный фреймворк, чем Scrum, Kanban, Scrumban, SAFe, LeSS, DaD… Намного проще, намного приятнее. Без подмены понятий. Обкатываю сейчас. Пока полет отличный. Если смогу убедиться, что все в рамках моих ожиданий, то поделюсь с миром и мир вздохнет с облегчением.
Хотелось бы получить хоть какие-то ответы от автора на вопросы выше. А то все выглядит, как рекламная статья.
Ряд вопросов:
1. Как именно вы поддерживаете совместимость мобильного и веб клиентов с логикой бэка (совместимость старых версий через подмену статусов и логики из новых)?
2. Как идет разработка и поставка мобильного клиента и интеграции в бэке (отдельная ветка в Git для каждой версии клиента и описание интеграции в бэке под каждую версию или как-то иначе)? Сюда же неплохо было бы пояснение про стабильные релизы и вашу версионность — тема не раскрыта.
3. Как именно идет обработка счетов (так как счета нужны практически для любых продуктов банка)? Что за логика под Middle сервисом счетов?
4. Как у вас организовано получение данных клиента (так как данные клиента нужны для любых продуктов банка)? Все хранится в какой-то БД и подгруажется в кэш? Или внешняя система -> кэш? Шина -> кэш? Как обеспечивается отказоустойчивость?
5. В случае критической ошибки на минорной версии (например, берется не тот счет для операции, что не противоречит автотестам, но противорчит логике) — она у вас сразу деплоится с ошибкой? Не слишком ли это рискованно?
6. Как у вас организован процесс электронной подписи? Вы храните подпись где-то или клиент каждый раз для каждого сервиса должен подгружать ключ?
Там сейчас очень много глупостей пишут и говорят. Поверьте, на наемной работе менеджера мне абсолютно все равно, какого вы пола, цвета, возраста, национальности, религии, ориентации и т.д. Для меня важно качество работы, моя мотивация и комфорт тех нескольких человек, с которыми я дружу из-за сочетания характеров.
Как корпоративное звено, могу ответить просто — RN очень легко «продать» (получить спонсорство, финансирование). То есть я могу легко собрать пять статей, где его расхваливают, рассказать про одно приложение на две платформы силами только дешевой JS разработки, большое стабильное сообщество со звездами у репозиториев, множество библиотек, универсальные автотесты, примеры от многих компаний. Все это под соусом позитива (хотя в каждом пункте есть нюансы, которые уничтожат возможность развития продукта на каком-то этапе).
Flutter на данный момент я не могу «продать», не хватает материала для убеждения, статей, где кто-то брызжа слюной доказывает (аналогия с RN), что он космос.
Вот и все.