AB
Конечно, не улучшились.
Size: a a a
2021 October 30
AB
Ну, вы думаете это как то измеряется прям?
AB
Еще раз: типичному проекту это не нужно.
AS
да, думаю что что бы что то улучшать надо это для начала измерять
AS
не важно не смогли ли люди или подвела техника
AS
если после рефакторинга проект стало проще обслуживать значит рефакторинг был не зря
AS
блеймить людей легко. поддерживать системы сложно
AB
Ну, есть проблема с тайм ту маркет. Начали плясать от нее. Увидели, что сервис слишком редко деплоится == тайм ту маркет так себе. Стали дальше анализировать, увидели условно что на тестировании затык или не настроен деплой => стали вот этими проблемами заниматься.
AB
Т.е. проседает метрика лид тайм, например, от нее нужно пытаться понять в чем на самом деле проблема. Менять любой подход архитектурный можно менять на любой другой и показать лид тайм лучший, но будет вопрос "а в этом ли было дело", пушо это может быть косвенным результатом.
AB
Соотв. нужно понимать что измерять и иметь соотв. сформированное хоть на уровне гипотезы представление.
AS
да согласен. надо измерять на большом колве проектов
AB
Я не очень сейчас вас понял. Вы про попытку выработать набор общих метрик?
AB
Ну для разных проектов оно будет разное. Всё сильно будет от специфики зависеть. Т.е. от потребности условно клиентов продукта будут подбираться метрики.
AS
да. сейчас за эту тему ближе всего как мне кажется DORA
AS
вероятно нужен метаанализ после того как эти метрики будут измерены
AB
А, ну, да, DORA вероятно можно рассматривать как такие red alert метрики, от которых плясать.
AS
я жду чего то такого от коллег из EPAM или express42 или похожих ребят
AB
Но имхо по опыту окажется что просаживаются метрики типа время на анализ задачи, время на тестирование и т.д. Но арх стилю оно вполне перпенд. как правило.
AS
у низ достаточно стандартные процессы и можно делать измерения
AB
Да все говорят, что у них стандартные, особенно как всё хорошо на конференциях, на практике, к сожалению, бывает по разному, но это к слову :)