Я работаю в аутсорсе и недавно вернулась на один из проектов, с которого ушла год назад. К своему глубокому удивлению, ознакомившись с кодом, я поняла, что его никто не рефакторил весь этот год. При разговоре с коллегой, который работал над этим проектом, я выяснила, что время на рефакторинг отдельно не выделялось, и он его не успел провести.
Итак, что я имею сейчас? Что стало с кодом, который не рефакторили год? Вопрос риторический, и так понятно, что он превратился в легаси.
Например, эти замечательные константы под гнетом измененных требований превратились в функции:
Было:
const CONST_GET_TEST = "CONST_GET_TEST";Стало:
const CONST_GET_TEST = (isTest: boolean) => {
if (isTest) {
return "CONST_GET_TEST_1";
} else {
return "CONST_GET_TEST_2";
}
};Или вот эти замечательные объекты, которые по-видимому раньше были типами, внезапно превратились в переменные с initial state:
Было:
const Person = { id: number, name: string, age: number };
const Info = { id: number, desc: string, old: number };
const Level = { id: number, level: number };Стало:
const Person = { id: 0, name: "", age: 0 };
const Info = { id: 0, desc: "", old: 0 };
const Level = { id: 0, level: 0 };Этот код получил право на существование только потому, что разработчику никто не выделил времени на рефакторинг, и ему пришлось словно “на коленке” дописывать код (надеюсь, что это всё-таки не какое-то предвзятое отношение ко мне).
На обновление одной из библиотек я потратила неделю, справляясь со всеми болями несовместимости с другими либрами в проекте, очень хотелось оставить как есть, но устаревшие версии библиотек стали бы проблемами попозже, они никуда бы не делись. Примерно три месяца ушло на то, чтобы привести проект в читаемый вид.
Причин такому "наследству" может быть множество, их мы обсудим ниже. Хочется добавить, что методология у этого проекта была водопад, и в таких случаях часто на рефакторинг выделяется время отдельно по достижению каких-то вех. Видимо, на моё время на проекте оно и выпало.
Что такое рефакторинг?
Начну с базы: что из себя представляет рефакторинг. Рефакторинг - это процесс систематического изменения внутренней структуры программного обеспечения с целью улучшения его понимания, упрощения добавления нового функционала или устранения ошибок. Основная цель рефакторинга – улучшить существующий код без изменения его функциональности. Рефакторинг - это как героизм в IT: мало кто знает об этом, но все пользуются плодами.
В чем ценность рефакторинга для проекта?
Зачем он вообще нужен? Ведь всё и так работает, кнопки жмутся, данные приходят и уходят. Я для себя выделяю три основные причины, по которым рефакторинг необходим:
Улучшение читаемости кода: Хорошо структурированный, чистый код легче читается и понимается. Это ускоряет процесс разработки, облегчает поддержку кода и ускоряет вхождение в проект нового разработчика.
Упрощение добавления новых функций: Когда код хорошо организован, добавление новых функций становится проще, менее рискованным и менее трудозатратным для новых сотрудников.
Улучшение производительности: Иногда рефакторинг может включать оптимизацию кода, что приводит к улучшению производительности.
Как часто нужно проводить рефакторинг?
Если бы меня спросили, я бы сказала - каждый спринт! Но все мы понимаем, что проекты разные, команды разработчиков и методологии разработки разные, и все эти факторы влияют на процесс написания и поддержки кода. Я постараюсь здесь рассмотреть самые популярные варианты.
Частота рефакторинга кода на проекте зависит от ряда факторов, включая размер и сложность проекта, как я писала ранее методологию разработки и культуру команды с их требованиями к качеству кода. Вот некоторые ключевые аспекты, которые помогут определить, как часто следует проводить рефакторинг:
-
Методология разработки:
Агильные методологии (например, Scrum): В этих подходах рефакторинг часто выполняется итеративно и инкрементально. Разработчики могут рефакторить код в рамках каждого спринта или даже чаще. На большинстве проектов, где мы работали по Scrum, задачи на рефакторинг создавались на каждый спринт. Например, при постановке задач на спринт мы учитывали, что они должны быть закрыты за два дня до окончания спринта, а последние два дня выделялись на отладку и рефакторинг.
Традиционные методологии: В более традиционных моделях, таких как водопад, рефакторинг может быть запланирован как отдельный этап после достижения определённых вех. Мне кажется, такой подход не самым удобным, потому что “определённые вехи” достигаются в какой-то рандомный момент.
-
Размер и сложность проекта:
Маленькие проекты: Возможно, рефакторинг будет проводиться по мере необходимости, поскольку обзор и изменение кода проще.
Большие и сложные проекты: Требуется более частый и систематический рефакторинг, чтобы поддерживать код в хорошем состоянии.
-
Частота изменений и добавления функционала:
Если проект активно развивается и часто обновляется, рефакторинг может потребоваться чаще для поддержания чистоты кодовой базы и упрощения добавления новых функций.
-
Технический долг:
Если в проекте накопился значительный технический долг, частые сеансы рефакторинга могут помочь постепенно улучшить качество кода и снизить сложность.
-
Ресурсы и приоритеты:
В зависимости от доступных ресурсов (времени, людей) и приоритетов проекта, рефакторинг может быть более или менее частым, или, как часто бывает, отсутствовать вообще.
Заключение
Важно, чтобы команды и руководители понимали ценность рефакторинга и выделяли на него время и ресурсы. Рефакторинг помогает избегать накопления технического долга и снижает риски, связанные с внедрением новых функций. В конечном итоге, это вклад в качество продукта и удовлетворённость команды разработчиков.
Мне сейчас вспомнилась цитата великого человека, написавшего не менее замечательную книгу "Совершенный код":
Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живете. (с) Стив Макконнелл - Совершенный код
Комментарии (37)
DMGarikk
22.05.2024 13:18+5Я работаю в аутсорсе
своему глубокому удивлению, ознакомившись с кодом, я поняла, что его никто не рефакторил весь этот год
вот ни капли не удивлён, никогда клиент не согласует вам 100500 часов на деятельность которая не принесет никакой ценности сиюминутно. Я бы радовался бы чтобы хотябы юниттесты в аутсорсе бы были, куда там про рефакторинг
edogs
22.05.2024 13:18никогда клиент не согласует вам 100500 часов на деятельность которая не принесет никакой ценности сиюминутно
Проблема в том, что современные проекты нередко достаточно динамичные. Рефакторинг же имеет смысл на лонг ран.
Не так уж редко бывает, когда клиент вроде и дает время и деньги на рефакторинг, но месяц спустя окончания рефакторинга требования к проекту меняются и красивый отрефакторенный код вместо "экономии времени годами на его поддержку" просто сливается в унитаз, потому что функционал который он обеспечивал просто перестал быть нужен.
Все же есть разница между полезным рефакторингом и предпохоронной подготовкой.
Как говорил один из наших менеджеров - "если рефакторинг полезен проекту, значит в бизнесе наступила стагнация и вместо рефакторинга надо думать об развитии бизнеса".
Troonsply Автор
22.05.2024 13:18систематический, итерактивный рефактор, отметает идею лонг рана. Если проект написан и сложен на полочку можно и без рефактора обойтись, но потом заказчику придется чуть больше денюжки платить разработчику только за то что бы он справился с поддержкой этого кода, да и на добавление новых фич в такие проекты как правило уходит больше времени
GospodinKolhoznik
22.05.2024 13:18+1если рефакторинг полезен проекту, значит в бизнесе наступила стагнация
Звучит как типичная цыганщина. Почти уверен, что эти мысли ему вложили в голову на трениге успешного успеха.
edogs
22.05.2024 13:18Звучит как типичная цыганщина.
Причина-следствие в другую сторону. Любая цыганщина в основе своей имеет быстрый рост бизнеса. Поэтому естественно, пользуется всеми утверждениями, которые верны для быстрого роста. Возьмите любую книжку про управление проектами и почитайте раздел про проблемы быстрого роста - сплошную цыганщину там увидите:)
GospodinKolhoznik
22.05.2024 13:18Любая цыганщина в основе своей имеет быстрый рост бизнеса
Точно также как и любой карго культ в своей основе имеет то, что туземцы увидели, как у белых людей быстро растет экономика и технических прогресс. Но не понимая реальных причин этого роста они придумали свою доступную для понимания, но совершенно неверную теорию.
edogs
22.05.2024 13:18Именно так. А потом один из туземцев понимает, что их "аэропорт" цыганщина и приехав в европу - автоматом называет все аэропорты цыганщиной, лишь потому, что там тоже "не проводят рефакторинг":)
DMGarikk
22.05.2024 13:18"если рефакторинг полезен проекту, значит в бизнесе наступила стагнация и вместо рефакторинга надо думать об развитии бизнеса".
если вы делаете систему управления складами в рамках вашего завода через оутсорс, то нужен заказчику рефакторинг в таком проекте или в какая стагнация в бизнесе должна наступить чтобы эту систему каждые 2 года надо переписывать?
ИТ проекты это не только продукты на продажу и основные источники дохода, но и просто операционные инструменты для бизнеса которые не приносят прямого дохода, но их пишут теже самые люди, тот же самый аутсорс и программисты
panzerfaust
22.05.2024 13:18+3Этот код получил право на существование только потому, что разработчику никто не выделил времени на рефакторинг
Кто не выделил-то? Единственный, кто волен выделять или не выделять время на рефакторинг - это сам разработчик. Для всех остальных это не их собачье дело. Поэтому тезис несодержателен.
Troonsply Автор
22.05.2024 13:18Предлагаете овертаймить на энтузиазме?
panzerfaust
22.05.2024 13:18+10Предлагаю овладеть искусством органично вписывать рефакторинг в рабочий процесс. Я не овертаймлю в принципе, но рефакторингом в разных формах занимаюсь постоянно.
edogs
22.05.2024 13:18То есть за счет заказчика (часы-то оплачивает он) занимаетесь тем, чем хотите вы (раз заказчик не выделил оплаченного времени на рефакторинг). Это всё конечно не ради обмана заказчика и не что бы было приятно работать, а исключительно ради благородной цели создания идеального кода:)
Не, ну серьезно. Заказчик Вам дает задачу - сдать проект как можно скорее, Вы половине времени тратите на рефакторинг и сдаете его со сроком в два раза больше. Может это и хорошо по отношению к коду и следующим программистам, но вот хорошо ли это по отношению к заказчику.
panzerfaust
22.05.2024 13:18Вы половине времени тратите на рефакторинг и сдаете его со сроком в два раза больше
Это ваша фантазия на пустом месте. У вас есть фактура, что конкретно я проваливаю сроки из-за своих профессиональных взглядов? Если вы сами не можете рефакторить и укладываться при этом в сроки - ну не занимайтесь этим, я не настаиваю. Я конкретно за себя выше написал.
edogs
22.05.2024 13:18Это ваша фантазия на пустом месте. У вас есть фактура, что конкретно я проваливаю сроки
Не наша фантазия, а Ваша. Мы нигде не говорили, что Вы проваливаете сроки.
Если вы сами не можете рефакторить
Те ошибки, что Вы "рефакторите" изначально не должны были возникать при соблюдении культуры кода и гайдлайнов.
constXife
22.05.2024 13:18Что-то у вас очень узкий взгляд на рефакторинг, раз вы этим спокойно в разных формах в рабочем процессе постоянно занимаетесь. Либо вы просто держите заказчика за дурачка, которому не нужно знать ничего. "Я занимаюсь непонятной для вас магией, отвалите."
panzerfaust
22.05.2024 13:18+6Что-то у вас очень узкий взгляд на рефакторинг, раз вы этим спокойно в разных формах в рабочем процессе постоянно занимаетесь
Взгляд у меня самый обычный. Описанные в статье примеры говнокода как раз прекрасно мейнтейнятся в рабочем процессе и не требуют вымаливания времени. Согласен, что есть большой рефакторинг, который надо продавать отдельно. Но легче просто не доводить до такого, поддерживая код в нормальном состоянии.
Либо вы просто держите заказчика за дурачка
Я держу заказчика за заказчика. Это такой чувак, который дал бюджет (не моя епархия, слава б-гу), задачу и время. И интересует его только выполнение задачи к указанному времени. Как я буду выполнять эту задачу - ни разу не его дело. Иначе это уже микроменеджмент, который до добра не доводит. А моя работа для него в любом случае магия. Иначе бы он был моим коллегой, а не заказчиком.
constXife
22.05.2024 13:18Как я буду выполнять эту задачу - ни разу не его дело. Иначе это уже микроменеджмент, который до добра не доводит.
Я, пожалуй, слишком общий термин использовал. Условно говоря, не заказчик, а Product Owner, который заведует общим направлением продукта. В одной фирме PO не вмешивался в техническую часть, он ставил абстрактные задачи и даже выделял время в спринте на различные технические работы.
В другой фирме PO уже активно вмешивается в технические задачи и ставит их, регулярного выделения времени на процесс избавления от технического долга не дают, надо сидеть и мало того, что надо прикинуть какие задачи надо взять, так и надо сидеть и думать как их правильно продать руководству.
И да, лучше не доводить код до ужасного состояния, однако ты не всегда приходишь на проект с 0, иногда приходиться иметь дело с легаси, которое хотелось бы привести в порядок, чтобы не вздыхать, каждый раз когда открываешь IDE.
Возвращаясь к корневому комменту, мне сложно представить, как я говорю PO, руки прочь от моих задач, это всё моя ответственность. И да, это моя ответственность, что я выбрал эту работу, просто я веду к тому, что, блин, ситуации разные бывают и не везде разработчик бог и я не очень понимаю зачем вы все ситуации под одну гребенку так категорично подводите. Это какое-то игнорирование реальности.
DMGarikk
22.05.2024 13:18. И интересует его только выполнение задачи к указанному времени. Как я
буду выполнять эту задачу - ни разу не его дело. Иначе это уже
микроменеджмент, который до добра не доводит. А моя работа для него в
любом случае магия. Иначе бы он был моим коллегой, а не заказчиком.Это вы както совсем на мелком уровне
Бывают заказчики у которых собственный ИТ отдел и компетенции повыше ваших. и как тут рядом писали которые упарываются в бюджеты...я работал на таком проекте, там заказчик (огромная контора с ИТ отделом на десяток департаментов) ревьювил сам каждую задачу и резал часы если сделано чтото свыше того что он просил... типа реализовать фичу N?.окей..тесты написал? выкинуть, мы вам платим за качественную реализацию фичи, а не за написание тестов..вы обещали не косячить... рефакторинг кода в фиче X потому что она рядом? мы за это не платили, вычеркиваем...
panzerfaust
22.05.2024 13:18И? Дальше что? Да, есть мудаки-микроменеджеры, которым все время виднее. От таких надо голосовать ногами. Если мне мешают работать, то я голосую ногами. А кто-то пишет на хабре оправдания про то, как ну просто невозможно рефакторить и писать тесты. Ок, не рефакторите, не пишите тесты, отчитывайтесь перед микроменеджментом за каждую минуту времени - имеете право.
DMGarikk
22.05.2024 13:18+1От таких надо голосовать ногами
не надо вообще идти в аутсорс, там 90% проектов упоротые
Я туда пошел с четко определенными целями, в эпам в свое время ради релока (там правда повезло, я был аутстаффером и проблем таких не было), а в следующую контору ради опыта (и там я подгорел на этом очень сильно)...сейчас славабогу я из аутсорса ушел
тем не менее проекты такие есть и будут и много и вы с ними столкнетесь, вечно бегать по мелким конторам ..ну это тоже путь, хотя как по мне он немного тупиковый
nronnie
22.05.2024 13:18+1От таких надо голосовать ногами.
В нашем мире если от каждого долбо*ба голосовать ногами, то очень скоро не останется места куда этими самыми ногами голосовать.
mamento
22.05.2024 13:18+3Я бы предложил сразу делать нормально. А нам не выделили время на рефакторинг, часто синоним "я не знал как сделать нормально и было лень сразу зариматься, сделал как получилось". Мне ту нравится аналогия со строительством, вызвав себе кого-то переложить пол например и даже договорившись по срокам, вы как заказчик будете ожидать что пол будет уложен ровно и качественно. И вы крайне удивитесь если тот кто его вам сделал скажет постфактум-"я тут сделал как получилось, но по хорошему там его ещё выровнять надо, а ещёсне не хватало ламината который вы дали и я нашёл там в углу остатки какого-то другого, и положил его. Ну и что что другого цвета, но вы же не выделили мне время и средства съездить в магазие и докупить? Задача выполнена, ходить можно и пыли нету"
nronnie
22.05.2024 13:18Это ведь всеми любимый принцип KISS, согласно которому: "Сделаем
через жо*укое-как. Потом когда надо будет товыкинем всё нах*йотрефакторим".
panzerfaust
22.05.2024 13:18+2К сожалению, стараниями всяких шуточек, анекдотов и нигилистов с хабра из ИТ кое-где ушел принцип "делать хорошо сразу". То, что код в принципе можно радикально изменить за N часов создает иллюзию, что у тебя реально всегда будут эти N часов и можно особо не париться здесь и сейчас. Типичный жизненный цикл проекта, где все живут в такой парадигме:
Правила не нужны, лучшие практики не нужны, солид не нужен, разделение на компонетны не нужно, тесты не нужны, DDD не нужен, ревью не нужно, нейминг не нужен. Жгите всех, б-г узнает своих.
Ой, а мне дядя менеджер время на рефакторинг не выделяет
А давайте все на GO перепишем
GOTO 1
DMGarikk
22.05.2024 13:18+1Единственный, кто волен выделять или не выделять время на рефакторинг - это сам разработчик
в аутсорсе мнение разработчика самое последнее
у меня на последнем проекте было примерно так:
Вы написали что сделаете фичу за 14 дней, окей, мы согласуем вам 7 дней, релиз в пятницу, на больше бюджета нет и не просите
nronnie
22.05.2024 13:18+1никто не хочет её начинать
Так никто никогда его (рефакторинг) и не начинает.
я поняла, что его никто не рефакторил весь этот год
Я всякий раз когда смотрю в код, то понимаю, что его никто не рафакторил вообще никогда.
Lewak
22.05.2024 13:18+3Для рефакторинга нужны причины, ими могут быть:
Рефакторинг увеличит производительность проекта;
Проект растет и развивается. Новые доработки делать сложнее, т.к. их не учитывали, когда начинали писать проект. Рефакторинг поможет ускорить дальнейшую разработку.
Могут быть и другие причины. Под этим соусом рефакторинг можно и продавать бизнесу, если он заинтересован в развитии проекта.
Рефакторинг без причин - это значит задач нету и делать на проекте уже нечего.
VFaland
22.05.2024 13:18+1. У нас (биг тех / продукт с десятизначным ревеню) рефакторинг делается перед тем как пишется фича, с конкретным обоснованием для чего. На код ревью например, если увидят трёхэтажные моки в тестах - тоже попросят отдельно отрефакторить сначала, чтобы любой джун разбуженный среди ночи понял что к чему. После того как код ушел в прод - никаких чисток чистоты ради.
minaevmike
22.05.2024 13:18Большие и сложные проекты: Требуется более частый и систематический рефакторинг
Вообще не согласен с этим поинтом. Имхо частота рефакторинга зависит от того как часто в код вносятся изменения (ведь при реализации изначального функционала оно и так должно реализовано нормально) и не сколько изначальная реализация хорошо и расширяемо написано (a.k.a. на сколько изначальный разработчик сделал решение гибким)
DMGarikk
22.05.2024 13:18хорошо и расширяемо написано (a.k.a. на сколько изначальный разработчик сделал решение гибким)
существуют адепты написания кода "максимально эффективно и минималистично" когда люди целенаправленно делают нерасширяемый продукт чтобы он работал быстрее и выглядел понятнее, потому что в сиюсикундных требованиях нет запроса на расширяемость
и в таких проектах внедрение фич обычно всегда сочетается с массовым рефакторингом
я не могу однозначно сказать что это плохая практика, но тут на хабре часто звучат фразы что программисты пишут неоптимальный код ;))
antirek
22.05.2024 13:18+2"никто не рефакторил весь этот год"
ого! тут вернулся к проекту семилетней давности, и к своему глубокому удивлению, ознакомившись с кодом, я понял, что его никто не рефакторил все эти семь лет
KirpaPuto
Раньше на Хабре вроде какая-то "песочница" была. Теперь любая банальщина сразу публикуются?
Troonsply Автор
Да, хабровская "песочница" иногда бывала более строга, чем школьный учитель по русскому. А теперь, кажется, даже чай с печеньками может пройти за техническую статью! Кто знает, может быть, следующим шагом будет гастрономический рецепт "Как правильно варить кофе для программиста"?
ykppon
Про кофе для программиста уже было