Перевод статьи «When to refactor legacy code vs. when to stay focused on your current project».
При работе с различными проектами я часто натыкаюсь на код, который можно подправить. Сделать его более читаемым, тестируемым, соответствующим стилю, принятому в настоящее время.
Особенно сильно тянет заняться рефакторингом, когда проведешь хороший кусок времени, пытаясь понять отрывок беспорядочного кода. Этот код просто выносит мне мозг, и я не хочу, чтобы то же самое происходило с другими разработчиками, которым он попадется. Как гласит известное правило, «Оставь код в лучшем виде, чем он был до тебя».
Но в то же время я хочу сохранять концентрацию и добиваться прогресса в своих текущих проектах. Меня беспокоит, что я могу увлечься и отвести слишком много времени на рефакторинг.
И такая дилемма возникает часто. Мне хочется быть доброй самаритянкой и оставлять код в лучшем виде, чем я его нашла. Как инженеру, мне хочется превращать весь встреченный беспорядочный код в нечто чистое и элегантное. Но я также хочу быть прагматичной и делать быстрые поставки текущих проектов.
Поддержание баланса между рефакторингом legacy-кода и сохранением концентрации на текущем проекте может быть непростой задачей.
Поговорив на эту тему со своим менеджером, я получила своего рода руководство по сохранению этого баланса. Надеюсь, эти советы и вам будут полезны.
Вам не обязательно делать код безукоризненным. Маленькие улучшения тоже полезны
Когда я читаю кусок legacy-кода, мой мозг моментально начинает продумывать, каким этот код должен быть в идеале. Но рефакторинг этого кода из текущего состояния до идеального порой требует большого труда. В самом лучшем случае на это просто уйдет много времени. В худшем – все это может оказаться кроличьей норой, прыжок в которую приведет к задержке всего проекта.
Раньше, когда мне попадались такие варианты, я делала одно из двух: или занималась обширным рефакторингом, наплевав на последствия, или зажимала нос и оставляла код вонять дальше. Теперь я понимаю, что есть золотая середина. Мне не нужно делать этот код совершенным. Можно просто немного его улучшить, потратив на это столько времени, сколько могу себе позволить.
Маленькие изменения, которые я вношу в старый код, все равно могут принести пользу другим разработчикам. И, возможно, у этих разработчиков буде время внести дальнейшие изменения на основе сделанных мной улучшений.
Следует помнить, что такой вещи как идеальный код в принципе не существует. Как только вы что-то поменяете, вы увидите еще больше возможностей для улучшений.
Ограничивайте время для рефакторинга
Time-boxing это отличный способ избежать «кроличьих нор». Прежде чем заняться рефакторингом legacy-кода, сделайте быструю оценку того, сколько времени вы можете уделить этому занятию без риска слишком задержать текущий проект. Запишите это число.
Ограничение времени, отводимого на внесение изменений в старый код, позволит вам не переживать насчет прогресса основного проекта. Благодаря этому и сам рефакторинг доставит вам больше удовольствия.
Учитывайте время на рефакторинг при оценке проекта
Все может стать гораздо проще, если вы учтете время на рефакторинг еще до начала работ над проектом. Делая прикидки, сколько времени может занять работа над проектом, просмотрите код, с которым придется работать. Когда он был написан? Насколько он читаемый, есть ли в нем возможности для расширения? Какое у него покрытие тестами? Если у вас нет очень жестких требований относительно даты поставки, включите в общий счет и немного времени на рефакторинг.
В конечном счете, если мы строим что-то поверх существующей сарой кодовой базы, рефакторинг это лучший способ поддерживать ее в здоровом состоянии. А это, в свою очередь, позволит нам создавать новый функционал быстрее и безопаснее.
Рефакторинг имеет и образовательную функцию
Улучшение отрывка кода это лучший способ разобраться в этом коде. Погружение в код и его изменение дают вам более глубокое понимание этого кода по сравнению с безучастным чтением.
Пытаясь внести свой вклад, вы начинаете замечать вещи, на которые прежде не обращали внимания. Таким образом можно заметить и кое-какие ограничения, а благодаря этому – понять, почему автор изначально написал свой код именно так.
Хотя рефакторинг кода вроде бы не приносит немедленной пользы бизнесу, для вас это отличная возможность получить новые знания. А вот это принесет несомненную пользу как вам, так и бизнесу.
Рефакторинг это мышцы, которые можно наращивать
Чем больше вы им занимаетесь, тем быстрее становитесь. Еще одна – последняя – причина заниматься улучшением старого кода, это возможность нарастить «мышцы рефакторинга».
Это самоокупаемые инвестиции: чем больше вы занимаетесь рефакторингом, тем лучше у вас получается и тем быстрее вы сможете делать это в дальнейшем. Чем больше изменений вы вносите, тем лучше становится ваша кодовая база и тем быстрее вы сможете создавать новый функционал.
Очень удачно, что мой следующий проект связан с кодом, написанным три года назад. Думаю, у меня будет много возможностей для нахождения баланса между рефакторингом старого кода и прогрессом нового проекта.
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]
Совершенству нет предела. Именно поэтому лучше стоит доводить до идеала то, что получается лучше всего. Конечно, никто не запрещает изучать новые языки программирования. Но делать это лучше в свободное от основной деятельности время.