Ещё вопрос, но наверное больше к вашей практике. На проекте Golang прошел все стадии адаптации и принят в тех. радар. Около 3-5 команд запустили микросервисы на нём. Сейчас я хочу вынести общий инфра код в библиотеки(логгирование, работа с mq и тд). Естественно сейчас зоопарк, у кого ZeroLog, у кого zap и тд. Такая же история с кодом работы с очередями.
Подскажите, как бы вы стали действовать с такими вводными?
Первая проблема, это редко когда есть возможность спроектировать вместе с бизнесом весь домен. А ведь с этого книжка Эванса и начинается. Надо много сессий и времени менеджмента. Часто бизнес и сам не знает точно как и что происходит. А постоянные синки разработки и бизнеса трудно продать бизнесу.
Вторая проблема вытекает из первой. Разработчики пытаются спроектировать домен на урывках информации. Ребята что помоложе пишут код по аналитики "в лоб", скатываясь в процедурное программирование. Кто поопытнее, делает архитектуру более поддерживаемой, часто выбирая DDD или гексагональную. Но поскольку не обладают всей полнотой знаний о домене, делают много догадок. От этого, либо неправильные абстракции, или переусложнение решения. И то и другое потом лечат костылями, а после костылей это поддерживать невозможно.
Идеально не сделать. Надо смотреть по ситуации.
РС Догадываюсь, что "огромный бойлерплейт" это про маппинг, верно?
Странно, что в списке литературы нет Принципов Юнит-тестирования Владимира Хорикова. Как будто конспект прочитал. Кто хочет более фундаментальные знания по данному подходу очень рекомендую к прочтению.
Когда работал руководителем разработки в "соседнем" банке, я внедрял похожую схему на основе git-flow. У нас было побольше контуров, ИФТ было два и по пути на прод код успевал побывать ещё на ПСИ(приемо-сдаточные испытания). Держать такое количество веток было бы тяжело и привело бы к множеству ошибок, поэтому у нас было 3 ветки: develop, release, master. В начале спринта мы отводили релизную ветку от дева. Чаще всего с головы ветки. Очень-очень редко приходилось брать с предидущих коммитов. От релизной ветки отводили фичи и делали merge назад. Если требовалось тестирование на develop, то мержили release в dev. По окончанию работ проставляли теги RC(release candidate) на release ветке и выкатывали на ифт. Когда тетстирование давало добро, то RC отправлялся на ПСИ. После прохождения AppSec и прочих радостей мержили в мастер и ставили релизный тег. Ветка релиз мержилась как в master так и в develop. При обнаружении бага на проде от мастера отводили bugfix, далее он проходил ИФТ->ПСИ->AppSec и мержился в мастер и проставляли тэг с инкрементом патча(по SemVer). В develop ветке вели разработку на следующий спринт либо очень долгих фичей.
P.S. У вас знакомый ник, мне кажется мы с вами году в 2016 вместе проходили курс Кислина. Или я ошибаюсь?
Ищите специальность отдельно. Она не обязательно должна быть связана с университетом. Самое главное, чтоб переводчик использовал название учебного заведения и специальности из базы анабин. Я на всякий распечатки из анабин прикладывал. Вопросов не возникло.
Спасибо за ответ.
Ещё вопрос, но наверное больше к вашей практике. На проекте Golang прошел все стадии адаптации и принят в тех. радар. Около 3-5 команд запустили микросервисы на нём. Сейчас я хочу вынести общий инфра код в библиотеки(логгирование, работа с mq и тд). Естественно сейчас зоопарк, у кого ZeroLog, у кого zap и тд. Такая же история с кодом работы с очередями.
Подскажите, как бы вы стали действовать с такими вводными?
Спасибо за статью.
Пару вопросов:
Как на практике происходит распространение решений? Канал с обновлениями, синки с лидами команд, knowledge sharing сессии и ТД
Является DevP команда неким "архитектором" платформы? Ваши ADR проходят ревью или другие процессы?
Мне кажется тут есть пара проблем.
Первая проблема, это редко когда есть возможность спроектировать вместе с бизнесом весь домен. А ведь с этого книжка Эванса и начинается. Надо много сессий и времени менеджмента. Часто бизнес и сам не знает точно как и что происходит. А постоянные синки разработки и бизнеса трудно продать бизнесу.
Вторая проблема вытекает из первой. Разработчики пытаются спроектировать домен на урывках информации. Ребята что помоложе пишут код по аналитики "в лоб", скатываясь в процедурное программирование. Кто поопытнее, делает архитектуру более поддерживаемой, часто выбирая DDD или гексагональную. Но поскольку не обладают всей полнотой знаний о домене, делают много догадок. От этого, либо неправильные абстракции, или переусложнение решения. И то и другое потом лечат костылями, а после костылей это поддерживать невозможно.
Идеально не сделать. Надо смотреть по ситуации.
РС Догадываюсь, что "огромный бойлерплейт" это про маппинг, верно?
Спасибо за статью.
Странно, что в списке литературы нет Принципов Юнит-тестирования Владимира Хорикова. Как будто конспект прочитал. Кто хочет более фундаментальные знания по данному подходу очень рекомендую к прочтению.
Спасибо за статью! Было интересно почитать.
Когда работал руководителем разработки в "соседнем" банке, я внедрял похожую схему на основе git-flow. У нас было побольше контуров, ИФТ было два и по пути на прод код успевал побывать ещё на ПСИ(приемо-сдаточные испытания). Держать такое количество веток было бы тяжело и привело бы к множеству ошибок, поэтому у нас было 3 ветки: develop, release, master. В начале спринта мы отводили релизную ветку от дева. Чаще всего с головы ветки. Очень-очень редко приходилось брать с предидущих коммитов. От релизной ветки отводили фичи и делали merge назад. Если требовалось тестирование на develop, то мержили release в dev. По окончанию работ проставляли теги RC(release candidate) на release ветке и выкатывали на ифт. Когда тетстирование давало добро, то RC отправлялся на ПСИ. После прохождения AppSec и прочих радостей мержили в мастер и ставили релизный тег. Ветка релиз мержилась как в master так и в develop. При обнаружении бага на проде от мастера отводили bugfix, далее он проходил ИФТ->ПСИ->AppSec и мержился в мастер и проставляли тэг с инкрементом патча(по SemVer). В develop ветке вели разработку на следующий спринт либо очень долгих фичей.
P.S. У вас знакомый ник, мне кажется мы с вами году в 2016 вместе проходили курс Кислина. Или я ошибаюсь?
Ищите специальность отдельно. Она не обязательно должна быть связана с университетом. Самое главное, чтоб переводчик использовал название учебного заведения и специальности из базы анабин. Я на всякий распечатки из анабин прикладывал. Вопросов не возникло.