Здравствуйте, Codealot, Вы писали:

C>То есть рефакторинг вообще никак не планируется менеджером и он про него ничего не знает, ты хочешь сказать?

Именно. Исключение составляют те случаи, когда вынужденный глобальный рефакторинг по той причине, что он затрагивает слишком большое количество мест. Обоснование лежит на девелоперах в единицах business value. Например

в прошедшем релизе выявлено много проблем, предполагается, эту часть менеджер понимает, т.к. тут KPI или внятные подтверженные факты
— сильно выросло время ожидания, время на фичу, см KPI
— слишком много трудновоспроизводимых багов, см KPI
— слишком много реопенов, см KPI
— слишком много багов из за мерж конфликтов, см KPI
— слишком большое время на пулл-реквест, см KPI
— слишком много мелких багов связаных с A..Z, см баклог
Анализ показывает
— работа блокируется из за кривого дизайна — если один меняет А, другие ждут его изменений, аналогично с B, C ... Z
— мерж-конфликты — слишком много изменений в чужих местах
— логирование, диагностика, телеметрия, инструментирование не выполняет свою функцию
— кривой API для логирования, диагностики, телеметрии, инструментирования итд
— кривой дизайн API для операций дата-время, что дает трудновоспроизводимые баги
Решение:
— работу над новой версии начать с рефакторинга API A...Z, для чего надо поставить на паузе все смежные фичи
— рефакторинг делают два толстых и лысых сеньора
— остальные во время рефакторинга девелоперы переключаются на тесты или инвестигируют тикеты от суппорта
— после рефакторинга все девелоперы фиксают баклог по вещам связаным с логированием, диагностике, телеметрии, инструментированию и тд
— по окончанию багфикса делаем бакпорт в релиз-бранч 24.0.0 и выкатываем патч 24.0.1, тикеты от суппорта фиксаем в 24.0.2 если они будут релевантны к тому времени.
— бакпорт можно не делать, но тогда суппорту говорим "до свидания"

I>>Похоже, хамство это один из основных твоих аргументов

C>Не больше, чем твой и многих других здесь. Даже намного меньше, на самом деле.

Ога!
У тебя 4 нарушения в пересчете на 1000 сообщений, у меня — меньше двух.
У тебя 4 нарушения за 9 месяцев, у меня 3 в год в среднем, при этом за два последних года всего 3 нарушения

Вобщем, ты всеми силами рвёшься в лидеры. Давай, покажи уже всем!!!111

Здравствуйте, Codealot, Вы писали:

C>То есть рефакторинг вообще никак не планируется менеджером и он про него ничего не знает, ты хочешь сказать?

Именно. Исключение составляют те случаи, когда вынужденный глобальный рефакторинг по той причине, что он затрагивает слишком большое количество мест и существенно замедляет активности. Обоснование лежит на девелоперах в единицах business value. Например

в прошедшем релизе выявлено много проблем, предполагается, эту часть менеджер понимает, т.к. тут KPI или внятные подтверженные факты
— сильно выросло время ожидания, время на фичу, см KPI
— слишком много трудновоспроизводимых багов, см KPI
— слишком много реопенов, см KPI
— слишком много багов из за мерж конфликтов, см KPI
— слишком большое время на пулл-реквест, см KPI
— слишком много мелких багов связаных с A..Z, см баклог
Анализ показывает
— работа блокируется из за кривого дизайна — если один меняет А, другие ждут его изменений, аналогично с B, C ... Z
— мерж-конфликты — слишком много изменений в чужих местах
— логирование, диагностика, телеметрия, инструментирование не выполняет свою функцию
— кривой API для логирования, диагностики, телеметрии, инструментирования итд
— кривой дизайн API для операций дата-время, что дает трудновоспроизводимые баги
Решение:
— работу над новой версии начать с рефакторинга API A...Z, для чего надо поставить на паузе все смежные фичи
— рефакторинг делают два толстых и лысых сеньора
— остальные во время рефакторинга девелоперы переключаются на тесты или инвестигируют тикеты от суппорта
— после рефакторинга все девелоперы фиксают баклог по вещам связаным с логированием, диагностике, телеметрии, инструментированию и тд
— по окончанию багфикса делаем бакпорт в релиз-бранч 24.0.0 и выкатываем патч 24.0.1, тикеты от суппорта фиксаем в 24.0.2 если они будут релевантны к тому времени.
— бакпорт можно не делать, но тогда суппорту говорим "до свидания"

I>>Похоже, хамство это один из основных твоих аргументов

C>Не больше, чем твой и многих других здесь. Даже намного меньше, на самом деле.

Ога!
У тебя 4 нарушения в пересчете на 1000 сообщений, у меня — меньше двух.
У тебя 4 нарушения за 9 месяцев, у меня 3 в год в среднем, при этом за два последних года всего 3 нарушения

Вобщем, ты всеми силами рвёшься в лидеры. Давай, покажи уже всем!!!111