Давайте сначала договоримся о терминах. Рефакторинг в данном случае - это изменение кода без изменения внешнего поведения. Чаще всего - упрощение логики, выкидывание устаревших фрагментов, вынос в отдельные модули.
Пререквизит участия в баттле - мы исходим из того, что рефакторинг полезен.
Одна опция - явная работа по рефакторингу (отдельный тикет например). С этим существуют некоторые проблемы. Бывает, что менеджеры не дают на это ресурс, считая ненужным (или аргументы за - неубедительными). Есть даже пособия "как продать рефакторинг своему менеджеру".
Другая опция - скрытый рефакторинг. Когда разработчик делает это, включая в feature merge requests. Аргументы за эту опцию -
в этом подкасте. В основном - чтобы не подставлять менеджера перед вышестоящим за "непонятную ненужную активность".
Интересно послушать мнения как разработчиков, так и менеджеров.
за «Явно показывать менеджеру рефакторинг»
за «Добавлять работы по рефакторингу к feature merge requests»
Примерно так, да.
Встану на другую сторону.
Да, рефакторинг нужен отдельно, но его нельзя закончить. Никогда.
Просто видишь говно - исправляешь говно. Видишь большое говно - делаешь тикет/таску.
Рефакторинг нужен чтобы поддерживать в порядке developer experience (в широком смысле), поддерживать условия работы на производстве.
Ухудшение условий производства -> хуже работается -> быстрее выгорание -> медленнее результаты у бизнеса
Менеджер отрицает это или пытается перевесить ответственность и заботу об этом на нас? Увольняем менеджера или увольняемся сами.
Нужно заниматься полезными рефакторингами, и не нужно - бесполезными.
Если есть явная польза - ускорение time to market, уменьшение багов, подготовка к выходу новой платформы у iOS/Android, то такие штуки без проблем продаются менеджеру. А если не продаются - надо менять менеджера или валить.
А если у рефакторинга нет явных причин кроме - ну чёт так хочется, то такой и не нужен:)
Если рефакторинг не оформлен как задача и вы о нём не отчитались, то его не заметят, не оценят, и за него не заплатят (за исключением случаев где вам платят просто за присутствие на работе). Если у вас есть практика код-ревью, то вашим коллегам придётся ещё и ревьюить вашу самодеятельность.
Если вам правда хочется поделать что-то полезное бесплатно - пожалуйста, сделайте что-нибудь в опенсорсе, которым пользуетесь. В этом случае вы тоже будете делать кого-то другого богаче за свой счёт, но есть чуть больший шанс нанести пользу обществу.
Никто же не спрашивает менеджера о том как назвать переменную или можно ли использовать хешмапу? Может кто-то спрашивает можно ли писать тесты на код?
Спрашивать подобные вещи - показывать свою некомпетентность и расписываться в неумении принятия решений.
Когда в коммит запихивают рефакторинг (я сейчас не говорю об изменение 2ух строчек кода, или исправление опечаток), то этот коммит стаовится менее читаем.
Поэтому, если в рефакторинге есть хоть какая-то сложность и логика, выносим его в отдельный коммит. Это уважение к людям, которые делают ревью.
Ну и если коммит вдруг сломает билд - ты будешь точно знать, виновата новая фича или неудачный рефакторинг.
Менеджеры, в числе прочего, управляют рисками проекта/продукта и зачастую отвечают/отчитываются по неким KPI/OKR, которые могут перетекать на команду — в виде распределения бонусов например.
Если команда будет коммуницировать менеджеру потенциальные узкие места, риски, рост хрупкости продута — менеджер сможет дальше по управленческой линии постоять за команду и её интересы, соотнести работу команды KPI/OKR, отчитаться на верхнем уровне по достижению оных и возможно принести команде какие-то плюшки.
Если же команда будет делать всё тайно — то лишает себя шанса на позитивную коммуникацию.
Я, будучи менеджером, каждый спринт выделял 20% времени на произвольный рефакторинг. Не важно какой.
Если команде что-то было неудобно или что-то тревожило, они ничего не обосновывали. Просто брали и делали. Не успевали доделать? Доделывали в следующем спринте. Благо гит позволяет растягивать это удовольствие.
В случае если нужен масштабный рефакторинг в целые спринты, то это отдельная история и там задействован обычно не только менеджер проекта и ПО, но и топ-манагеры компании.
Если не показывать, то менеджеры начинают думать, что его нет.
Мы сразу на берегу договорились и больше этот вопрос никогда не поднимали: каждая команда тратит 75% времени на фичи, баги и прочие продуктовые задачи; 25% времени — на dev задачи, рефакторинг, возврат техдолга, «заточку топора». Задачи ни от кого не скрываем, но и «продажей» рефаторинга менеджерам каждый спринт не занимаемся.
Оценили задачи. Продакт менеджеры выбрали свои задачи условно на 50 сторипоинтов, разработчики с тимлидом выбрали свой набор задач на рефакторинг на 16 сторипоинтов. Взяли всё в спринт и работаем.
Вторая, не менее важная договорённость внутри компании — любые изменения в коде не должны добавлять техдолг. Если для встраивания новой фичи, нужно две соседние переписать, чтобы сделать без костылей, то у разработчиков есть только два пусти:
Это как выносить мусор. Мы просто не гадим у себя дома. А если так уж случилось, что нам пришлось намусорить, то сразу делаем уборку.
Продать эти договорённости нужно ровно один раз.
Желательно в самом начале сотворения организации.
Есть разные стадии жизни проекта, сначала добавляется много фичей, но пользоваться будут не всеми, главное потом не забыть их грохнуть оптом.
После стабилизации бизнес-модели и окончания всяких пивотов бывает, что начинают выделять процент на рефакторинг, но поздно пить боржоми, его всегда оказывается мало, чтобы выгрести накопленное к тому моменту легаси.
Если рефакторинг реально необходим, то его можно доказать, у меня получалось много раз.
Если рефакторинг необязательный - это преждевременная оптимизация, она не нужна.
Если речь идет про переделку структуры микросервиса, то, вероятно, это много работы и эта работа вызовет много багов на интеграционном и e2e тестировании (еще больше работы).
Если подобные вещи не подсвечивать менеджеру, то не будет понимания почему разработчик провалил сроки по фиче. Еще и багов дофига. А если такая история уже не в первой, может быть, с ним пора 1-2-1 и расставаться?
В общем, тут как в личных отношениях: скрытно ничего не надо делать, лучше быть честным и открытым.
Тут всё время сравнивают теплое и мягкое. Рефакторинг это изменение структуры кода без изменения поведения. Если вы переименовываете функцию или создаёте структуру - это рефакторинг. Про это может стоит поговорить с теми кто читает и пишет тот же кусок кода, но зачем этим занимать голову менеджмента непонятно.
Если вы меняете бибилиотеку логирования или формат конфига или схему БД - это изменение архитектуры. Его стоит обсуждать не только с менеджером, а в принципе с широким кругом коллег.
Хороший, правильный рефакторинг это ДОХУЯ изменений во множестве файлов. Скорее всего, вы ставите целью выпилить какую-то парадигму целиком, либо заменить её новой.
Походя вынести кусок кода на N строчек в функцию - это не рефакторинг, это обычное программирование. Взять и переписать целый компоненты(ы) с сотнями строк со старого реакта на новый - это рефакторинг. Проапгрейдить коровые тулы (например для билда), что приведёт к переписыванию кусков кода под новые версии - это рефакторинг. Это по оконцовке тысячи изменных строк кода, множество возможных тикетов, эпиков или что у вас там
И за такие изменения в скоупе нового функционала никто спасибо не скажет. Ни разрабы, которым это ревьювать, ни тестеры (кто бы ни выполнял эту функцию), которым теперь вместо понятного набора фичей надо проверять ВСЁ, ни менеджер, который увидит в качестве результата только лишние баги. Не надо так делать, вот просто не надо
Нужно отстаивать свою обязанность поддерживать проект в надлежащем техническом состоянии. Будь то хреновое легаси, осознанный техдолг в угоду скорости релизов, что-то ещё - всё равно нужно находить время и выгребать это говнище, иначе однажды будет произнесена волшебная фраза: "ну тут проще с нуля переписать"
И да, я употребляю слово обязанность, потому что никто кроме собственно инженеров не может и не должен за этим следить и обращать внимание. Равно как и глубоко понимать, зачем это нужно. Если вы не имеете достаточного авторитета, чтобы это обосновать менеджеру любого уровня, вы явно что-то делаете не так (имха)
Менеджеру о таких вещах не надо знать - это поточка и часть работы над фичей
Довольно долго приходилось сидеть на двух стулях одновременно:
Сразу оговорюсь, что поменять название переменной или интерфейс класса, добавить тестов etc - это не то, о чем менеджер хочеть слышать про рефакторинг, это должо делаться командой исходя из своих внутернних договоренностей. Меня как менедера это не интересует.
Истории про смену протоколов, изменения архитектуры, выделения микросервисов из монолита, серьезная смена модели данных - это тот рефакторинг который надо обсуждать с менеджером. Далека не всегда целесообразано выделять ресурсы, даже если рефакторинг очень проситься. Вот пара очевидных примеров:
Если менеджер упирается рогом и не хочет такие вещи аппрувить вообще, то или вы плохо приводите аргументы, или менеджер дурак. А если менеджер дурак и его нет возможности заменить или повлиять на него, зачем тратить свою жизнь на компанию в которой приходится действовать партизанскими методами?