Явно показывать менеджеру рефакторинг
или
Добавлять работы по рефакторингу к feature merge requests
 Публичный пост 25 ноября 2023  713

Давайте сначала договоримся о терминах. Рефакторинг в данном случае - это изменение кода без изменения внешнего поведения. Чаще всего - упрощение логики, выкидывание устаревших фрагментов, вынос в отдельные модули.

Пререквизит участия в баттле - мы исходим из того, что рефакторинг полезен.

Одна опция - явная работа по рефакторингу (отдельный тикет например). С этим существуют некоторые проблемы. Бывает, что менеджеры не дают на это ресурс, считая ненужным (или аргументы за - неубедительными). Есть даже пособия "как продать рефакторинг своему менеджеру".

Другая опция - скрытый рефакторинг. Когда разработчик делает это, включая в feature merge requests. Аргументы за эту опцию -
в этом подкасте. В основном - чтобы не подставлять менеджера перед вышестоящим за "непонятную ненужную активность".

Интересно послушать мнения как разработчиков, так и менеджеров.

12 аргументов и 76 плюсиков
за «Явно показывать менеджеру рефакторинг»
6 аргументов и 32 плюсика
за «Добавлять работы по рефакторингу к feature merge requests»
за «Явно показывать менеджеру рефакторинг»
Если менеджер не даёт мне время/ресурсы рефакторить, мы находим другого менеджера

Примерно так, да.

А смысле поменяв работу?

  Развернуть 1 комментарий

@mdogx, В смысле поменяв менеджера

  Развернуть 1 комментарий

@RishadMustafaev, были успешные кейсы как команда меняла менеджера? а если менеджер — на стороне заказчика?

  Развернуть 1 комментарий
за «Добавлять работы по рефакторингу к feature merge requests»
Вижу говно — исправляю говно.

Встану на другую сторону.
Да, рефакторинг нужен отдельно, но его нельзя закончить. Никогда.
Просто видишь говно - исправляешь говно. Видишь большое говно - делаешь тикет/таску.

его нельзя закончить. Никогда.

Льзя. В моей сфере встречается код, который менять очень дорого. Нам периодически приходится ревьюить код с мыслью "это можно будет изменить не раньше чем через год и заплатив пару годовых зарплат разработчика".
Всё получается. Успешно находятся решения, к которым не возникает вопросов годами, есть примеры кода, работающего с конца нулевых без изменений.

  Развернуть 1 комментарий

@civilian, Нет, это просто ОЧЕНЬ ДОРОГО, а не законченный рефакторинг.

Я могу так же просто сказать "Что мы ничего не делаем с сервисом Х" - как была куча проблем и говна в коде, так и осталась. Просто мы решили по каким-то причинам не трогать её.

  Развернуть 1 комментарий

@urtow, я же говорю

Успешно находятся решения, к которым не возникает вопросов годами

это именно законченный рефакторинг. Мы тратим недели и месяцы чтобы произвести такой код. Его пересматривает много людей из разных организаций. Его независимо верифицируют несколько групп математиков. Он тестируется до дыма. Там не доебаться. В нём не бывает ошибок.

  Развернуть 1 комментарий

@civilian, тестирование может доказать наличие ошибок, но не может доказать его отсутствие.

То есть я верю, что можно сделать идеальный код, который будет работать годами и не надо будет его менять (сам делал код , который годами работает без изменений), но отсутвие ошибок в таком коде - увы, миф :(

  Развернуть 1 комментарий

@urtow, отсутствие ошибок гарантируется верификацией. Этот код ломается только в случае ошибок в JVM и CPU - но и против этого есть меры.

  Развернуть 1 комментарий

@civilian, Любопытно, видимо это другая сторона. Мы не тратим много денег на постоянные изменения, а тратим сразу много денег, но один раз.

  Развернуть 1 комментарий

@civilian, а что за сфера?

  Развернуть 1 комментарий

@zahhar, казино

  Развернуть 1 комментарий

@civilian, генераторы случайных чисел?

  Развернуть 1 комментарий

@urtow, ГПСЧ как самое очевидное, но ещё целый список функциональностей, который комлпаенс-бояре любят помечать "strictly confidential". Там всё довольно предсказуемо и описано в публичных стандартах, например, вот тут https://gaminglabs.com/gli-standards/, стандарты client-server systems, разделы типа "verification of control program".

  Развернуть 1 комментарий

@civilian, Ну да, в таком случае можно сказать что рефакторинг закончен, соглашусь. Сомневаюсь, что через пол года поменяются требования и надо будет переписывать.

  Развернуть 1 комментарий

@civilian, Не понятно при чём тут верификация. Она доказывает соотвествие кода некоторой модели, формализованным требованиям. Рефакторинг обычно реакция на изменение требований или прояснение ожиданий.

  Развернуть 1 комментарий

@civilian, гм... интересно тогда почему у крупных корпораций постоянно выходят апдейты и заплатки на найденные уязвимости и баги... а тут вжух проверили и говорим что все ошибок нет и не будет?
Так не бывает :-)

  Развернуть 1 комментарий

@dgatsura, потому что их код не верифицируют? :-) Мне кажется, тебе стоит перейти по ссылке на Википедию выше. Верификация это формальное доказательство, что алгоритм корректный. До тех пор, пока система (процессор, ОС, виртуальная машина) выполняет свою часть контрактов (a + b это всегда сумма a и b), код в команде Василия выполняет свою часть контрактов.

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

  Развернуть 1 комментарий
за «Явно показывать менеджеру рефакторинг»
Потому что всё остальное — поощрение сказок

Рефакторинг нужен чтобы поддерживать в порядке developer experience (в широком смысле), поддерживать условия работы на производстве.

Ухудшение условий производства -> хуже работается -> быстрее выгорание -> медленнее результаты у бизнеса

Менеджер отрицает это или пытается перевесить ответственность и заботу об этом на нас? Увольняем менеджера или увольняемся сами.

Рефакторинг это зачастую уменьшение багов.

  Развернуть 1 комментарий

@slonoed, а как рефакторинг (если придерживаться определения из поста - изменение кода без изменения внешнего поведения) может уменьшить количество багов?
Я могу понять, как при рефакторинге можно увеличить количество багов, - при любом изменении кода можно внести дефект.
Разве что существующие дефекты были случайно найдены и исправлены при рефакторинге. Но, если они без этого оставались незамеченными, насколько они важны.

  Развернуть 1 комментарий
за «Явно показывать менеджеру рефакторинг»

Нужно заниматься полезными рефакторингами, и не нужно - бесполезными.
Если есть явная польза - ускорение time to market, уменьшение багов, подготовка к выходу новой платформы у iOS/Android, то такие штуки без проблем продаются менеджеру. А если не продаются - надо менять менеджера или валить.

А если у рефакторинга нет явных причин кроме - ну чёт так хочется, то такой и не нужен:)

за «Явно показывать менеджеру рефакторинг»
альтернатива — работать бесплатно

Если рефакторинг не оформлен как задача и вы о нём не отчитались, то его не заметят, не оценят, и за него не заплатят (за исключением случаев где вам платят просто за присутствие на работе). Если у вас есть практика код-ревью, то вашим коллегам придётся ещё и ревьюить вашу самодеятельность.

Если вам правда хочется поделать что-то полезное бесплатно - пожалуйста, сделайте что-нибудь в опенсорсе, которым пользуетесь. В этом случае вы тоже будете делать кого-то другого богаче за свой счёт, но есть чуть больший шанс нанести пользу обществу.

за «Добавлять работы по рефакторингу к feature merge requests»
Потому что это не касается менеджера

Никто же не спрашивает менеджера о том как назвать переменную или можно ли использовать хешмапу? Может кто-то спрашивает можно ли писать тесты на код?

Спрашивать подобные вещи - показывать свою некомпетентность и расписываться в неумении принятия решений.

за «Явно показывать менеджеру рефакторинг»
Чтобы была чище история коммитов

Когда в коммит запихивают рефакторинг (я сейчас не говорю об изменение 2ух строчек кода, или исправление опечаток), то этот коммит стаовится менее читаем.

Поэтому, если в рефакторинге есть хоть какая-то сложность и логика, выносим его в отдельный коммит. Это уважение к людям, которые делают ревью.

Ну и если коммит вдруг сломает билд - ты будешь точно знать, виновата новая фича или неудачный рефакторинг.

за «Явно показывать менеджеру рефакторинг»
Рефакторинг не имеет ценности без её коммуникации

Менеджеры, в числе прочего, управляют рисками проекта/продукта и зачастую отвечают/отчитываются по неким KPI/OKR, которые могут перетекать на команду — в виде распределения бонусов например.

Если команда будет коммуницировать менеджеру потенциальные узкие места, риски, рост хрупкости продута — менеджер сможет дальше по управленческой линии постоять за команду и её интересы, соотнести работу команды KPI/OKR, отчитаться на верхнем уровне по достижению оных и возможно принести команде какие-то плюшки.

Если же команда будет делать всё тайно — то лишает себя шанса на позитивную коммуникацию.

за «Добавлять работы по рефакторингу к feature merge requests»
3 вариант — фича рефакторинг

Я, будучи менеджером, каждый спринт выделял 20% времени на произвольный рефакторинг. Не важно какой.

Если команде что-то было неудобно или что-то тревожило, они ничего не обосновывали. Просто брали и делали. Не успевали доделать? Доделывали в следующем спринте. Благо гит позволяет растягивать это удовольствие.

В случае если нужен масштабный рефакторинг в целые спринты, то это отдельная история и там задействован обычно не только менеджер проекта и ПО, но и топ-манагеры компании.

за «Явно показывать менеджеру рефакторинг»
Ломать менеджерские фантазии о разработке

Если не показывать, то менеджеры начинают думать, что его нет.

за «Явно показывать менеджеру рефакторинг»
75% времени на фичи, 25% на рефакторинг

Мы сразу на берегу договорились и больше этот вопрос никогда не поднимали: каждая команда тратит 75% времени на фичи, баги и прочие продуктовые задачи; 25% времени — на dev задачи, рефакторинг, возврат техдолга, «заточку топора». Задачи ни от кого не скрываем, но и «продажей» рефаторинга менеджерам каждый спринт не занимаемся.

Оценили задачи. Продакт менеджеры выбрали свои задачи условно на 50 сторипоинтов, разработчики с тимлидом выбрали свой набор задач на рефакторинг на 16 сторипоинтов. Взяли всё в спринт и работаем.

Вторая, не менее важная договорённость внутри компании — любые изменения в коде не должны добавлять техдолг. Если для встраивания новой фичи, нужно две соседние переписать, чтобы сделать без костылей, то у разработчиков есть только два пусти:

  1. либо сразу переписать соседний код и сразу сделать всё хорошо
  2. либо вначале сделать как-нибудь новую фичу (просто, чтобы она как можно раньше попала на прод, потому что менедежеры очень просят), и следом сразу же заняться рефакторингом и переделать написанные код на хороший вариант. Разумеется продактов о таком заранее предупреждают. Подобные задачи не считаются рефакторингом, а идут в продуктовые 75%.

Это как выносить мусор. Мы просто не гадим у себя дома. А если так уж случилось, что нам пришлось намусорить, то сразу делаем уборку.

Продать эти договорённости нужно ровно один раз.
Желательно в самом начале сотворения организации.

Я не очень понял. Если вы не порождаете новый техдолг, на что уходят 25% бюджета?

  Развернуть 1 комментарий

@glader, совсем не порождать сразу в процессе работы всё равно не получается. То есть даже если есть правило «поел — помой посуду», то иногда нужно ещё окна мыть и генеральную уборку устраивать.

  1. Что-то упустили на ревью, по невнимательности. А потом это заметили и поняли, что надо переделывать. Запланировали в рефакторинг.
  2. Инфраструктурная команда выпустила новую версию внутреннего фреймворка, надо обновиться. Версия языка или вендорной бибилиотеки устарела, тоже хотим обновиться. Тоже берём в 25%.
  3. Разработка давно хотела написать какую-то автоматизацию или скрипт, чтобы в будущем себе жизнь упростить и ускорить фичевую разработку, перейти на новый статический анализатор кода в своём сервисе, допокрыть тестами сложный участок и т. д. Что-то конечно делают отдельные инфраструктурные команды, но и им бывает нужна помощь.
  4. В любой системе есть архитектурные ошибки, которые были допущены давным давно. И их исправление это долгая история. Такие эпики разбиваем на маленькие кусочки и планомерно делаем в теже 25%.
  Развернуть 1 комментарий
за «Добавлять работы по рефакторингу к feature merge requests»
Большая часть часть кода умрет ненужной, а причесывать надо только активно трогаемое

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

за «Явно показывать менеджеру рефакторинг»
Скоуп работ должен быть явный, иначе едут сроки сдачи фичи

Если рефакторинг реально необходим, то его можно доказать, у меня получалось много раз.
Если рефакторинг необязательный - это преждевременная оптимизация, она не нужна.
Если речь идет про переделку структуры микросервиса, то, вероятно, это много работы и эта работа вызовет много багов на интеграционном и e2e тестировании (еще больше работы).
Если подобные вещи не подсвечивать менеджеру, то не будет понимания почему разработчик провалил сроки по фиче. Еще и багов дофига. А если такая история уже не в первой, может быть, с ним пора 1-2-1 и расставаться?

В общем, тут как в личных отношениях: скрытно ничего не надо делать, лучше быть честным и открытым.

за «Добавлять работы по рефакторингу к feature merge requests»
Если про это надо знать менеджеру — это не рефакторинг

Тут всё время сравнивают теплое и мягкое. Рефакторинг это изменение структуры кода без изменения поведения. Если вы переименовываете функцию или создаёте структуру - это рефакторинг. Про это может стоит поговорить с теми кто читает и пишет тот же кусок кода, но зачем этим занимать голову менеджмента непонятно.

Если вы меняете бибилиотеку логирования или формат конфига или схему БД - это изменение архитектуры. Его стоит обсуждать не только с менеджером, а в принципе с широким кругом коллег.

за «Явно показывать менеджеру рефакторинг»
Это слишком масштабно для скоупа фичей

Хороший, правильный рефакторинг это ДОХУЯ изменений во множестве файлов. Скорее всего, вы ставите целью выпилить какую-то парадигму целиком, либо заменить её новой.

Походя вынести кусок кода на N строчек в функцию - это не рефакторинг, это обычное программирование. Взять и переписать целый компоненты(ы) с сотнями строк со старого реакта на новый - это рефакторинг. Проапгрейдить коровые тулы (например для билда), что приведёт к переписыванию кусков кода под новые версии - это рефакторинг. Это по оконцовке тысячи изменных строк кода, множество возможных тикетов, эпиков или что у вас там

И за такие изменения в скоупе нового функционала никто спасибо не скажет. Ни разрабы, которым это ревьювать, ни тестеры (кто бы ни выполнял эту функцию), которым теперь вместо понятного набора фичей надо проверять ВСЁ, ни менеджер, который увидит в качестве результата только лишние баги. Не надо так делать, вот просто не надо

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

И да, я употребляю слово обязанность, потому что никто кроме собственно инженеров не может и не должен за этим следить и обращать внимание. Равно как и глубоко понимать, зачем это нужно. Если вы не имеете достаточного авторитета, чтобы это обосновать менеджеру любого уровня, вы явно что-то делаете не так (имха)

Позволю не согласиться. То, что ты описываешь словом «рефакторинг», это скорее реинжиниринг или просто переписывание. Рефакторинг автор определил корректно, и техник именно рефакторинга всё-таки ограниченное количество, и обычно это всё-таки достаточно локализованный, управляемый процесс.

  Развернуть 1 комментарий

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

А всё, что явно выходит за скоуп и должно быть вынесено в полноценную задачу, это и есть крупные изменения, разве нет?

  Развернуть 1 комментарий

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

Когда в качестве тестировщицы с этим сталкивалась, причем видя лишние изменения только в PR, очень злилась.

  Развернуть 1 комментарий

@redfoks, ну смотря ведь какие три строчки, тут же надо головой уже думать на месте разработчика. Если это какая-то синтаксическая мелочь это одно, а если ты просто берёшь по приколу переписываешь алгоритм который что-то делает, то это уже явный выход за скоуп и как минимум нужно указывать что "функционал Х нужно прогнать по всем тест-кейсам" (если они существуют лол). Ну и само собой тогда тестеры имеют полное право поинтересоваться, а не пошёл ли бы этот выдумщик нахуй, если например дело к релизу и уже всё распланировано

  Развернуть 1 комментарий

@kadron141, в моем опыте это было "а я не думал, что это так повлияет..." Очень хотелось заставить все откатить и чтобы сделал "как договаривались", но там начиналось "ну что уж теперь, ну раз сделал..."

Если делаешь подпольный рефакторинг, то хоть с другими членами команды поговори)

  Развернуть 1 комментарий
за «Добавлять работы по рефакторингу к feature merge requests»
Переименовать функцию можно и без отдельного тикета если того требует фича

Менеджеру о таких вещах не надо знать - это поточка и часть работы над фичей

за «Явно показывать менеджеру рефакторинг»
Рефакторинг далеко не всегда имеет смысл для бизнеса

Довольно долго приходилось сидеть на двух стулях одновременно:

  • определять скоуп работ над фичами как PO
  • писать код самому и ревьювить коллег

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

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

  • Фича работает 10 лет, бизнес требования полностью удовлетворены и никак не меняются. Никто не будет инвестировать деньги в улучшения, которые не нужны и никак не окупаются.
  • Фича или продукт будут выпилены в обозримом будущем. Не всегда осведомлены об этом. Если не начать заранее разговор об этом с менеджером, ресурсы будут потраничены вникуда и команда будет демотивирован выброшенной работой.
за «Явно показывать менеджеру рефакторинг»
Это работа на которую надо тикеты-шмикеты иметь и время (деньги) тратить

Если менеджер упирается рогом и не хочет такие вещи аппрувить вообще, то или вы плохо приводите аргументы, или менеджер дурак. А если менеджер дурак и его нет возможности заменить или повлиять на него, зачем тратить свою жизнь на компанию в которой приходится действовать партизанскими методами?

😎

Автор поста открыл его для большого интернета, но комментирование и движухи доступны только участникам Клуба

Что вообще здесь происходит?


Войти  или  Вступить в Клуб