> С монолитом просто так взять и обновиться нельзя, нужно переписывать кучу кода и заново его тестировать.
С микросервисами тоже просто так обновится нельзя, переписали сервиси — надо так же все тестировать, где гарантия что сервис переписан коректно.
> Микросервисы решают этот вопрос тем, что позволяют себя переписать на новой либе или вообще новом языке за те пару месяцев, пока версии ключевых либ считаются «свежими».
Пока переписываем микросервис — либы опять устаревают? тут наверное нужно гнаться не за либами — а найти компромисс между «старыми» либами и работающим функционалом.
Проблемы такие есть, но это не так страшно как написанно
1. Отвлекающие факторы: Тут наверное достаточно просто, шум, ходьба и тп — наушники, которые изолируют от внешнего мира, а избыточные совещания и тп — донесите до менагера — что часы проекта(списывайте часы на митинги) и он сам будет меньше вас лишний раз беспокоить.
2. Второе — это скорей всего про первый пункт.
3. Неясность — это вообще не проблема, не ясно что делать с задачей отправляйте ее тому кто ее завел и не важно дефект или фича. Лучше вернуть ее чем гадать и делать на свое усмотрение неверно(потому что как приавльно не понятно)
4. Чайки и чайки
5. Кража «лавров» — какие лавры, мы делаем один продукт, и задача разработчика решать задачи, а самоутвердится — можно на митапе выступить или в opensource
6. шум и другие отвлекающие факторы — см пункт 1.
7. Это рабочй процесс, продукт развивается и в первой версии был один функциона(скорей всего MVP), а дальше функционал наращивается.
8. см пункт 5.
9. Технический долг — это все вовласти разработчика и выстраивания процесса разработки, при решении той или иной задачи, технический олг должен закрыватся, а завести задачу на рефакторинг — никто не даст.
10. ХЗ вот тут не понятно, тут можно спорить что решает за производительность, рабочее место или проффесионализм разработчика, потому что можно оргонизовтаь работу таким образом, что тяжелые процессы можно вынести в облако и тп.
11. Это к вопросу про ясность, не понятно — задавай вопросы, возвращай на доработку.
12. Ну что значит примерно оценить, есть куча методологий оценки задачь — плюс менеджер должен риски закладывать, либо тогда вопрсы к менеджеру.
> Зачем вы считаете средний показатель? Средний показатель — это способ подвести комманду под over-commitment.
На самом деле нет, это средний показатель наоборот позволят лишнего ничего не втянуть, что мы точно не успеем(бизнес старается под завязку спринт нафаршировать), но как правила в спринте нужно место оставить для различных форсмажоров, плюс задачи по улучшению процесса. Бывает даже так что, бизнесу точно нужна небольшая фича которая делаться достаточно просто, она ставится целью спринта, а остальное по возможности.
Вроде да можно сказать — а зачем они нужны пользы от них никакой(со стороны бизнеса), но тут главное донести их необходимость/суметь продать. И если что то идет не так, лучше завалится с задачами которые не влияют на цель спринта.
Конечно никто вам не скажет что есть четкие критерии которых вы должны придерживаться для оценки сложности задач, НО каждая команда выбирает для себя эталон который берет за 1SP и уже этой задачей меряют все остальные.
И данный процесс итеративный и со временем эталонная задача изменится.
А про ту проблему про которую вы говорите — что фикс на 3 строчки кода, превращается в 3х недельную правку кода — Это должно разбиратся на ретро и понимать почему так вышло(потому что вы начали рефракторить все вокруг — большой технический долг, или задачу не разобрали — потому что задачи оцениваются не в строчках и оценка делается всей командой(тестирование, аналитика, разработка) — если так вышло, то тут либо все под забили на разбор задачи(да там 3 строчки поправить, ерунда).
Всякое бывает и каждый случай надо разбирать, именно разбирать, а не искать крайнего. Если технический долг большой, то наверное надо в бизнесовые задачи, как минимум вводить написание тестов, автотестов и тп.
sp про сложность и не разу про скорость. с задачей в 1 sp можно 3 дня делать монтонную просту работу, и с задачей в 5 sp -3 дня разбиратся и за полчаса доделать ее.
И оценить мы примерно можем сколько мы sp делаем, считаем среднее кол-во sp за 6 месяцев, вот он и средний показатель.
Ну а если не уложились и сильно всохатились, есть ретро на котором можно обсудить как улучшить ситауцию.
scrum — это процесс в котором надо научится жить. и менеджеры которые привыкли все возводить в абсолют(скорость разработки) для них трудно переключится на sp.
ну почему же от балды, sp это сложность задачи как ее видит вся команда и есть очень четкие правила как считать их(нужен эталон в 1 sp и уже с ним сравнивать).
От балды берется только там где scrum для галочки
добавлю еще одно:
Спец из Гугла не смог настроить вам компании что бы они приносили вам клиентов. Спец настраивал под те задачи которые Вы озвучивали, под те фразы которые Вы давали. Контекст эта таже реклама и тут мало вливать денег, а надо разбиратся в рекламе + разбиратся в контексте.
— потому что все легло на плечи разработчиков, а где же devops?
Некоторые проблемы так и остались нерешенными. Протестированное ПО не всегда соответствовало тому, что ставили в продуктив. Разработчик всегда мог в последний момент что-то поменять в подготовленной программе, руководствуюсь своим видением правильности работы системы
— а как насчет ставить протестированные сборки?
В экстренных ситуациях даже служба поддержки может внести небольшие изменения в код и отправить исправление в продуктив, не обладая ценными знаниями о компиляции, сборке и установке ПО.
— а как же кровавый ынтэрпрайз! служба поддержки вносит изменения, а эти изменения нигде не отраженны в документации и тп, а потом гадай зачем это сделали и возникают старые проблемы — Протестированное ПО не всегда соответствовало тому, что ставили в продуктив
К мнению о том, что Hibernate оклеветали, я не компетентен и тп
От части в этом есть смысл. Знания и опыт по Hibernate — у мня не глубоки и подозревал что будет такое мнение. Начал я эту статью писать с того, что необходимо было определить что быстрее и целесообразно ли использовать MyBatis. Я проводил тестирование с помощью labs.carrotsearch.com/junit-benchmarks.html, да и опыта такого не было. Посмотрев на скудность данных и не было уверенности что я все делаю правильно — сравнивать две ORM без большого опыта использования обоих не верно, но на тех тестах которые мной были проведенный(выборка элементарных объектов со связью один к одному и один к многим), показали что Hibernate процентов на 10 уступает MyBatis со Spring (на аннотациях), а если использовать стандартные механизмы мапинга MyBatis то разрыв становится больше.
Использовать можно и две ORM на проекте — MyBatis для работы с сложными запросами, т.к. он обрабатывает запросы быстрее, а Hibernate использовать для CRUD(без Read) он прекрасно с этим справляется. — IMHO
Если есть опыт проведения сравнений ORM и других библиотек. прошу поделиться опытом.
К вопросам по ужасным xml, громоздкости, мапингу без xml:
Mybatis поддерживает программное конфигурирование, можно с помощью аннотаций запихнуть весь запрос в интерфейсы. Но есть как минимум две причины по которой мне не очень нравиться использовать аннотации в Mybatis
Сам sql становиться менее читаемым, аннотация становится мостроподобной. А в xml файле все аккуратно лежит, подсвечивается.
В интерфейсе было проблематично указать ResultMap для запроса. Когда я только начал использовать аннотации, пришлось несколько раз продублировать ResultMap для каждого метода. Решение было не явным и в документации нигде не описано, что можно использовать уже объявленный ResultMap по имени метода в котором он был объявлен, с суффиксом “-void”(Если ResultMap был объявлен для метода getUsers, дальше данный ResultMap можно будет использовать по имени “getUsers-void”
Использовать или не использовать аннотации и отказываться от xml — это дело вкуса, мне не понравилось писать sql запросы в аннотации.
С микросервисами тоже просто так обновится нельзя, переписали сервиси — надо так же все тестировать, где гарантия что сервис переписан коректно.
> Микросервисы решают этот вопрос тем, что позволяют себя переписать на новой либе или вообще новом языке за те пару месяцев, пока версии ключевых либ считаются «свежими».
Пока переписываем микросервис — либы опять устаревают? тут наверное нужно гнаться не за либами — а найти компромисс между «старыми» либами и работающим функционалом.
1. Отвлекающие факторы: Тут наверное достаточно просто, шум, ходьба и тп — наушники, которые изолируют от внешнего мира, а избыточные совещания и тп — донесите до менагера — что часы проекта(списывайте часы на митинги) и он сам будет меньше вас лишний раз беспокоить.
2. Второе — это скорей всего про первый пункт.
3. Неясность — это вообще не проблема, не ясно что делать с задачей отправляйте ее тому кто ее завел и не важно дефект или фича. Лучше вернуть ее чем гадать и делать на свое усмотрение неверно(потому что как приавльно не понятно)
4. Чайки и чайки
5. Кража «лавров» — какие лавры, мы делаем один продукт, и задача разработчика решать задачи, а самоутвердится — можно на митапе выступить или в opensource
6. шум и другие отвлекающие факторы — см пункт 1.
7. Это рабочй процесс, продукт развивается и в первой версии был один функциона(скорей всего MVP), а дальше функционал наращивается.
8. см пункт 5.
9. Технический долг — это все вовласти разработчика и выстраивания процесса разработки, при решении той или иной задачи, технический олг должен закрыватся, а завести задачу на рефакторинг — никто не даст.
10. ХЗ вот тут не понятно, тут можно спорить что решает за производительность, рабочее место или проффесионализм разработчика, потому что можно оргонизовтаь работу таким образом, что тяжелые процессы можно вынести в облако и тп.
11. Это к вопросу про ясность, не понятно — задавай вопросы, возвращай на доработку.
12. Ну что значит примерно оценить, есть куча методологий оценки задачь — плюс менеджер должен риски закладывать, либо тогда вопрсы к менеджеру.
На самом деле нет, это средний показатель наоборот позволят лишнего ничего не втянуть, что мы точно не успеем(бизнес старается под завязку спринт нафаршировать), но как правила в спринте нужно место оставить для различных форсмажоров, плюс задачи по улучшению процесса. Бывает даже так что, бизнесу точно нужна небольшая фича которая делаться достаточно просто, она ставится целью спринта, а остальное по возможности.
Вроде да можно сказать — а зачем они нужны пользы от них никакой(со стороны бизнеса), но тут главное донести их необходимость/суметь продать. И если что то идет не так, лучше завалится с задачами которые не влияют на цель спринта.
И данный процесс итеративный и со временем эталонная задача изменится.
А про ту проблему про которую вы говорите — что фикс на 3 строчки кода, превращается в 3х недельную правку кода — Это должно разбиратся на ретро и понимать почему так вышло(потому что вы начали рефракторить все вокруг — большой технический долг, или задачу не разобрали — потому что задачи оцениваются не в строчках и оценка делается всей командой(тестирование, аналитика, разработка) — если так вышло, то тут либо все под забили на разбор задачи(да там 3 строчки поправить, ерунда).
Всякое бывает и каждый случай надо разбирать, именно разбирать, а не искать крайнего. Если технический долг большой, то наверное надо в бизнесовые задачи, как минимум вводить написание тестов, автотестов и тп.
И оценить мы примерно можем сколько мы sp делаем, считаем среднее кол-во sp за 6 месяцев, вот он и средний показатель.
Ну а если не уложились и сильно всохатились, есть ретро на котором можно обсудить как улучшить ситауцию.
scrum — это процесс в котором надо научится жить. и менеджеры которые привыкли все возводить в абсолют(скорость разработки) для них трудно переключится на sp.
От балды берется только там где scrum для галочки
Спец из Гугла не смог настроить вам компании что бы они приносили вам клиентов. Спец настраивал под те задачи которые Вы озвучивали, под те фразы которые Вы давали. Контекст эта таже реклама и тут мало вливать денег, а надо разбиратся в рекламе + разбиратся в контексте.
— а как насчет ставить протестированные сборки?
— а как же кровавый ынтэрпрайз! служба поддержки вносит изменения, а эти изменения нигде не отраженны в документации и тп, а потом гадай зачем это сделали и возникают старые проблемы — Протестированное ПО не всегда соответствовало тому, что ставили в продуктив
От части в этом есть смысл. Знания и опыт по Hibernate — у мня не глубоки и подозревал что будет такое мнение. Начал я эту статью писать с того, что необходимо было определить что быстрее и целесообразно ли использовать MyBatis. Я проводил тестирование с помощью labs.carrotsearch.com/junit-benchmarks.html, да и опыта такого не было. Посмотрев на скудность данных и не было уверенности что я все делаю правильно — сравнивать две ORM без большого опыта использования обоих не верно, но на тех тестах которые мной были проведенный(выборка элементарных объектов со связью один к одному и один к многим), показали что Hibernate процентов на 10 уступает MyBatis со Spring (на аннотациях), а если использовать стандартные механизмы мапинга MyBatis то разрыв становится больше.
Использовать можно и две ORM на проекте — MyBatis для работы с сложными запросами, т.к. он обрабатывает запросы быстрее, а Hibernate использовать для CRUD(без Read) он прекрасно с этим справляется. — IMHO
Если есть опыт проведения сравнений ORM и других библиотек. прошу поделиться опытом.
Mybatis поддерживает программное конфигурирование, можно с помощью аннотаций запихнуть весь запрос в интерфейсы. Но есть как минимум две причины по которой мне не очень нравиться использовать аннотации в Mybatis
Использовать или не использовать аннотации и отказываться от xml — это дело вкуса, мне не понравилось писать sql запросы в аннотации.