M0№£yU5ER.COM / it-юмор :: программист :: monkeyuser :: Смешные комиксы (веб-комиксы с юмором и их переводы) :: geek (Прикольные гаджеты. Научный, инженерный и айтишный юмор)

И это правильный ответ, но ваше очко все равно уходит в зрительный зал

Мало тулов позволяют смотреть диапазоны коммитов. И например в ситуации "первые 3 коммита это рефакторинг остальные 10 это фича" посмотреть отдельно и то и другое сложно, причем нужно использовать какую-нибудь продвинутую иде типа идеи, а в каком-нибудь веб интерфейсе гитхаба/гитлаба увидеть ничего не выйдет.

Вторая проблема это конфликты с другими людьми - рефакторинг может поломать работу другим людям, и в случае если бы это были 2 раздельные задачи мы могли бы например попросить пару дней не трогать этот компонент, зарефачить и чтобы другие задачи делались от уже исправленного кода. В случае если это одна задача то мы 2 дня рефачили и потом 5 дней пилили задачу, и в последние 4 дня (т.е. уже после того как рефакторинг закончился но мы его не замержили) коллеги накидали кучу кода. И теперь у нас есть код коллег использующий старыый код и своя фича использующая новый. Это весьма нетривиально может быть.

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

тлдр: делайте отдельные задачи на рефакторинг, в нормальном проекте не будет проблем выделять часть времени на техдолг. А с идиотами лучше не работать, нервы целее будут

Хорошей практикой если задача Х непонятна заводить новую "понять как нам делать Х", её уже оценить, и если успеваем сделать Х то загружаем её в спринт, если нет то мы в любом случае уже представляем сколько она стоит и можем впихнуть куда она может влезть