Это работает только если ревьюер адекватный. Иначе придётся рефакторинг пихать в отдельную фичу.
И это правильный ответ, но ваше очко все равно уходит в зрительный зал
Мало тулов позволяют смотреть диапазоны коммитов. И например в ситуации "первые 3 коммита это рефакторинг остальные 10 это фича" посмотреть отдельно и то и другое сложно, причем нужно использовать какую-нибудь продвинутую иде типа идеи, а в каком-нибудь веб интерфейсе гитхаба/гитлаба увидеть ничего не выйдет.
Вторая проблема это конфликты с другими людьми - рефакторинг может поломать работу другим людям, и в случае если бы это были 2 раздельные задачи мы могли бы например попросить пару дней не трогать этот компонент, зарефачить и чтобы другие задачи делались от уже исправленного кода. В случае если это одна задача то мы 2 дня рефачили и потом 5 дней пилили задачу, и в последние 4 дня (т.е. уже после того как рефакторинг закончился но мы его не замержили) коллеги накидали кучу кода. И теперь у нас есть код коллег использующий старыый код и своя фича использующая новый. Это весьма нетривиально может быть.
И наконец вопрос то что с точки зрения и управления проектом и понимания что происходит лучше иметь отдельные задачи на такие вещи. Это особенно важно если рефакторинг что-то сломает - тогда нужно ревертить только его, но не фичу. И вот тогда наступает пипец, все бегают с горящей жопой и пытаются понять как нам все зафиксить чтобы не просрать код и при этом чтобы оно вернулось в худо-бедно рабочее состоянее.
тлдр: делайте отдельные задачи на рефакторинг, в нормальном проекте не будет проблем выделять часть времени на техдолг. А с идиотами лучше не работать, нервы целее будут
Вторая проблема это конфликты с другими людьми - рефакторинг может поломать работу другим людям, и в случае если бы это были 2 раздельные задачи мы могли бы например попросить пару дней не трогать этот компонент, зарефачить и чтобы другие задачи делались от уже исправленного кода. В случае если это одна задача то мы 2 дня рефачили и потом 5 дней пилили задачу, и в последние 4 дня (т.е. уже после того как рефакторинг закончился но мы его не замержили) коллеги накидали кучу кода. И теперь у нас есть код коллег использующий старыый код и своя фича использующая новый. Это весьма нетривиально может быть.
И наконец вопрос то что с точки зрения и управления проектом и понимания что происходит лучше иметь отдельные задачи на такие вещи. Это особенно важно если рефакторинг что-то сломает - тогда нужно ревертить только его, но не фичу. И вот тогда наступает пипец, все бегают с горящей жопой и пытаются понять как нам все зафиксить чтобы не просрать код и при этом чтобы оно вернулось в худо-бедно рабочее состоянее.
тлдр: делайте отдельные задачи на рефакторинг, в нормальном проекте не будет проблем выделять часть времени на техдолг. А с идиотами лучше не работать, нервы целее будут
Погоди, каждый коммит - это логически законченное изменение. Если без просмотра суммы всех изменений из всех коммитов ты не можешь понять, о чем тут идет речь - у тебя неправильные коммиты.
Насчет рефакторинга - это уже вопрос процессов в компании, а не инструмента. Например, необязательно мержить все разом, можно смержить рефакторинг, а потом доделывать саму фичу - и все это в рамках одного задания.
> Это особенно важно если рефакторинг что-то сломает - тогда нужно ревертить только его, но не фичу
Ну а если рефакторинг был отдельной задачей, его смержили, он что-то сломал, но пока это выяснили - уже новых коммитов для других задач поверх рефакторинга накидали, что это меняет? Опять же, это вопрос процессов, а не инструментария.
В целом ты, конечно, прав - лучше, когда под рефакторинг выделяется отдельная задача. Но правильная работа с гитом вполне позволяет делать это и в процессе работы над фичами.
Насчет рефакторинга - это уже вопрос процессов в компании, а не инструмента. Например, необязательно мержить все разом, можно смержить рефакторинг, а потом доделывать саму фичу - и все это в рамках одного задания.
> Это особенно важно если рефакторинг что-то сломает - тогда нужно ревертить только его, но не фичу
Ну а если рефакторинг был отдельной задачей, его смержили, он что-то сломал, но пока это выяснили - уже новых коммитов для других задач поверх рефакторинга накидали, что это меняет? Опять же, это вопрос процессов, а не инструментария.
В целом ты, конечно, прав - лучше, когда под рефакторинг выделяется отдельная задача. Но правильная работа с гитом вполне позволяет делать это и в процессе работы над фичами.
Это работает только если ваш продукт чуть сложнее чем хеллоуворлд.
тут есть шанс обосраться с прогнозами и потерять доверие
поэтому лучше объснять, что без рефакторинга разработка новых фич невозможна
поэтому лучше объснять, что без рефакторинга разработка новых фич невозможна
Именно поэтому на рефакторинг надо выделять минимум 4х времени от того, что тебе кажется. Потому что вылезет немало хуйни.
А вот в этом случае манагеру объяснить становится непросто.
Но лучше сразу заложить на рефакторинг больше, и если что сделать раньше, или вообще не делать, чем при подошедшем сроке иметь нахуй разломанный код, который ещё править и править, а менеджменту уже надо фичи, рефакторинг оставляем до лучших времён.
И придется делать параллельно рефакторинг и добавление фич в параллельных ветках. Что полный пиздец.
А вот в этом случае манагеру объяснить становится непросто.
Но лучше сразу заложить на рефакторинг больше, и если что сделать раньше, или вообще не делать, чем при подошедшем сроке иметь нахуй разломанный код, который ещё править и править, а менеджменту уже надо фичи, рефакторинг оставляем до лучших времён.
И придется делать параллельно рефакторинг и добавление фич в параллельных ветках. Что полный пиздец.
"4х времени от того, что кажется" тоже рисковано потому что может "вылезти" больше чем ожидаешь.
Поэтому правильнее все таки перед тем как оглашать оценку времени потратить время на изучение кода и оценить объем работы. Что может выглядить как юзер стори с подтасками в разных скоупах и уже с истимейтами. Что будет звучать более определенно, чем просто "кажется".
Поэтому правильнее все таки перед тем как оглашать оценку времени потратить время на изучение кода и оценить объем работы. Что может выглядить как юзер стори с подтасками в разных скоупах и уже с истимейтами. Что будет звучать более определенно, чем просто "кажется".
Может у них база данных настроена вся в по московскому часовому поясу... с летним временем
Самое смешное, что не так страшны спагетти и легаси, как оверинжинирнутый код с распухшими до потери здравого смысла абстракциями, нашпигованный паттернами не из необходимости, а потому что мамкины программисты начитались умных книжек, и решили пихать новые умения повсюду просто потому что могут.
Работает
Не нравится?
Перепиши в свое нерабочее время за спасибо
Но если что-то перестанет работать - твое очко уходит в зрительный зал