Вполне. Возможно мы вкладываем разные понятия в этот термин)
Бас фактор, приводит к тому, что когда увольняется человек, разобравшийся в electricspock достаточно глубоко, мы получаем проблему когда никто не знает, как исправить ошибку в библиотеке, если она возникнет.
В любом случае это можно назвать даже train factor или как угодно, суть проблемы я описал в полной мере)
Для ванильного junit5 в сложных кейсах это становится неподдерживаемым, в той статье, которую вы скинули как пример рассматриваются только простые кейсы)
По electricspock доработки только в нашем форке, основной репозиторий уже никто не меинтейнит)
Почему это нормально, что на прохождение ревью может уйти в 2 раза больше времени чем на написание кода? — Это нормально, так как на проекте может быть несколько разработчиков и каждый из них может оставить свое замечание к вашему пул реквесту, которое придется либо оспаривать, либо исправлять. Может быть ли это нормально для старичков проекта? — Со старичками проекта такое случается реже, так как они уже больше знают о специфике проекта и правилах код ревью, которые установлены на этом проекте Или сколько времени закладывать на исправление выявленных багов? Сложно дать точный ответ на этот вопрос, опять же все зависит от специфики проекта, сложности вашей задачи и так далее. Очень много факторов имеют влияние. Что будет если половину этого времени переложить на аналитиков, то будет ли здесь экономия? — Не до конца понял вопрос, половину какого именно времени ?)
Ну, большую задачу лучше всего декомпозировать до такой степени, чтобы оценка выходила в районе одной, максимум двух недель. Лучше всего когда задача такого размера, что на нее уходит меньше рабочей недели.
Вполне. Возможно мы вкладываем разные понятия в этот термин)
Бас фактор, приводит к тому, что когда увольняется человек, разобравшийся в electricspock достаточно глубоко, мы получаем проблему когда никто не знает, как исправить ошибку в библиотеке, если она возникнет.
В любом случае это можно назвать даже train factor или как угодно, суть проблемы я описал в полной мере)
Да, думаю стоило это чётче отразить, согласен с вашими поинтами)
Согласен, этот фактор тоже сильно повлиять может)
Для ванильного junit5 в сложных кейсах это становится неподдерживаемым, в той статье, которую вы скинули как пример рассматриваются только простые кейсы)
По electricspock доработки только в нашем форке, основной репозиторий уже никто не меинтейнит)
ахаххахахах))
Отличная статья, было интересно !)
Хороший материал, будет полезен всем кто использует компоуз)
Спасибо, почитаю)
— Это нормально, так как на проекте может быть несколько разработчиков и каждый из них может оставить свое замечание к вашему пул реквесту, которое придется либо оспаривать, либо исправлять.
Может быть ли это нормально для старичков проекта?
— Со старичками проекта такое случается реже, так как они уже больше знают о специфике проекта и правилах код ревью, которые установлены на этом проекте
Или сколько времени закладывать на исправление выявленных багов?
Сложно дать точный ответ на этот вопрос, опять же все зависит от специфики проекта, сложности вашей задачи и так далее. Очень много факторов имеют влияние.
Что будет если половину этого времени переложить на аналитиков, то будет ли здесь экономия?
— Не до конца понял вопрос, половину какого именно времени ?)