Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 17
Сейчас работаю над махровым легаси, при том в достаточно специфичной сфере. В проекте не было тестов изначально, код пребывает не в лучшем виде, тестами удастся покрыть не более 10% кода (да и то, это новая функциональность). Проект надо поддерживать и развивать, ибо им активно пользуются и периодически хотят новые фичи, но к сожалению он становится настолько запутанным, что каждая новая задача или багфикс приводит к тому, что нужно судорожно протыкивать весь проект и молиться, что ничего не сломалось (привет, отсутствие тестов!)
В связи с этим у меня два вопроса: «как жить если тестов не бывает?» и «как продать бизнесу рефакторинг?»
В связи с этим у меня два вопроса: «как жить если тестов не бывает?» и «как продать бизнесу рефакторинг?»
В точку прямо.
Без тестов грустно. Иногда помогает — вместо честных юнит-тестов автоматизировать хотя бы функциональные. По принципу — все контролы на месте, ничего не пропало. Инструмент не посоветую, но можно поспрашивать тестировщиков они должны знать. Ну и покрыть юнит-тестами для начала хотя бы «стыки» между компонентами. По опыту, самая большая засада — именно при интеграции.
По второму вопросу точно буду отдельно что-то писать. В двух словах — бизнес говорит на языке денег, поэтому разговаривать с ним надо на языке денег. Поддержка кода и внедрение стоят времени. Цель рефакторинга — сэкономить время на внедрение новых фич и избавиться от части багов (обычно попутно получается). Соответственно, я обычно некоторое время собираю статистику по таким задачам — сколько времени уходит на их решение, а потом прихожу и говорю, что рефакторинг займёт X часов и сэкономит Y часов на каждой фиче — вот список.
Надо понимать, что затраты на рефакторинг — это инвестиции, и бизнес должен чётко видеть ROI для него.
Без тестов грустно. Иногда помогает — вместо честных юнит-тестов автоматизировать хотя бы функциональные. По принципу — все контролы на месте, ничего не пропало. Инструмент не посоветую, но можно поспрашивать тестировщиков они должны знать. Ну и покрыть юнит-тестами для начала хотя бы «стыки» между компонентами. По опыту, самая большая засада — именно при интеграции.
По второму вопросу точно буду отдельно что-то писать. В двух словах — бизнес говорит на языке денег, поэтому разговаривать с ним надо на языке денег. Поддержка кода и внедрение стоят времени. Цель рефакторинга — сэкономить время на внедрение новых фич и избавиться от части багов (обычно попутно получается). Соответственно, я обычно некоторое время собираю статистику по таким задачам — сколько времени уходит на их решение, а потом прихожу и говорю, что рефакторинг займёт X часов и сэкономит Y часов на каждой фиче — вот список.
Надо понимать, что затраты на рефакторинг — это инвестиции, и бизнес должен чётко видеть ROI для него.
Как то работал над кодом которому лет 7-10, написанному еще на Java 1.6. И впечатления, мягко говоря, печальные. Из того что самое печальное из воспоминаний — местами не юзались темплейт енджайны и данные юзеру отдавались слепленные стрингбилдером…
Проблема в таких проектах даже не в том, что языковые конструкции устарели, или что фрэймворки/либы старых версий. А проблема в том, что раз они дошли до нас в таком состоянии, то разработка изначально была построена не правильно. Проект не обновлялся из версии к версии языка/либы/фрэймворка, не рефакторился и т.д. Отношение к коду в этих проектах было такое — что сделай быстро запладку, не важно как. И проект весь на запладках и разобрать что, где и как — это еще та проблема.
В общем мораль такова — жадный заказчик платит дважды, а то и трижды, а то и весь жизненный цикл своего кривого проекта…
Проблема в таких проектах даже не в том, что языковые конструкции устарели, или что фрэймворки/либы старых версий. А проблема в том, что раз они дошли до нас в таком состоянии, то разработка изначально была построена не правильно. Проект не обновлялся из версии к версии языка/либы/фрэймворка, не рефакторился и т.д. Отношение к коду в этих проектах было такое — что сделай быстро запладку, не важно как. И проект весь на запладках и разобрать что, где и как — это еще та проблема.
В общем мораль такова — жадный заказчик платит дважды, а то и трижды, а то и весь жизненный цикл своего кривого проекта…
Редко комментирую, ну уж очень статья на злобу дня.
А не надо продавать никакой рефакторинг никому.
Более того рефакторинг ради рефакторинга — зло.
Его можно и нужно делать тогда, когда есть хотя-бы два три четких изменения, которые действительно значительные настолько, что проще переписать, читай отрефакторить, чем снова дописывать код.
А вся история с рефакторингом ни во что не выльется, после рефакторинга туда внесут такие-же изменения, о которых тот кто рефакторил, даже не задумывался и как результат не подготовил код…
А не надо продавать никакой рефакторинг никому.
Более того рефакторинг ради рефакторинга — зло.
Его можно и нужно делать тогда, когда есть хотя-бы два три четких изменения, которые действительно значительные настолько, что проще переписать, читай отрефакторить, чем снова дописывать код.
А вся история с рефакторингом ни во что не выльется, после рефакторинга туда внесут такие-же изменения, о которых тот кто рефакторил, даже не задумывался и как результат не подготовил код…
Если под рефакторингом понимать написание нового движка, чтобы фичи программировались просто настройкой этого движка, то весьма вероятно, что завтра появится требование, никак не вписывающееся в стройную схему и придётся снова вбивать костыль.
Но если под рефакторингом понимать переименование переменных и функций в актуальное (бывает, ф-ция писалась под одно, а теперь делает совсем другое), вынесение больших кусков копипасты в функции, вынесение побочного кода, который размазан повсюду (кеширование, сервисные функции) в отдельные классы, то такое всегда полезно.
Но если под рефакторингом понимать переименование переменных и функций в актуальное (бывает, ф-ция писалась под одно, а теперь делает совсем другое), вынесение больших кусков копипасты в функции, вынесение побочного кода, который размазан повсюду (кеширование, сервисные функции) в отдельные классы, то такое всегда полезно.
Рефакторинг ради эстетики, действительно несёт мало пользы, Однако, он необходим, если:
— изменения в проекте становятся дорогими и долгими из-за низкого качества кода и архитектуры
— в ближайшее время планируется развитие продукта с добавлением новых фичей (у нормального живого продукта это состояние перманентно)
— как альтернатива предыдущему — команда проекта будет расширяться
А вот этот абзац серьёзно настораживает. Во-первых, мы не можем подготовить код к любым изменениям, поэтому такое положение дел совершенно нормально. С другой стороны, что значит «внесут изменения»? Придёт незнакомый человек в офис и испортит красивый код?
Если с командой всё в порядке, то такие изменения как минимум обсуждаются заранее. В том числе и с тем, кто делал рефакторинг. Уверяю вас, чтобы сделать кривой костыль в условиях, когда код обсуждается и регулярно проводится ревью, надо очень постараться. Особенно после того, как код приведён в относительный порядок.
А вот если даже небольшие правки ведут к костылям, то надо прежде всего настраивать коммуникацию и распределение ролей в команде, а делать рефакторинг в такой ситуации — действительно, пустая трата времени и денег заказчика. Это симптомы того, что у кода нет владельца (aka code owner) или он не справляется.
— изменения в проекте становятся дорогими и долгими из-за низкого качества кода и архитектуры
— в ближайшее время планируется развитие продукта с добавлением новых фичей (у нормального живого продукта это состояние перманентно)
— как альтернатива предыдущему — команда проекта будет расширяться
А вся история с рефакторингом ни во что не выльется, после рефакторинга туда внесут такие-же изменения, о которых тот кто рефакторил, даже не задумывался и как результат не подготовил код…
А вот этот абзац серьёзно настораживает. Во-первых, мы не можем подготовить код к любым изменениям, поэтому такое положение дел совершенно нормально. С другой стороны, что значит «внесут изменения»? Придёт незнакомый человек в офис и испортит красивый код?
Если с командой всё в порядке, то такие изменения как минимум обсуждаются заранее. В том числе и с тем, кто делал рефакторинг. Уверяю вас, чтобы сделать кривой костыль в условиях, когда код обсуждается и регулярно проводится ревью, надо очень постараться. Особенно после того, как код приведён в относительный порядок.
А вот если даже небольшие правки ведут к костылям, то надо прежде всего настраивать коммуникацию и распределение ролей в команде, а делать рефакторинг в такой ситуации — действительно, пустая трата времени и денег заказчика. Это симптомы того, что у кода нет владельца (aka code owner) или он не справляется.
Переписать такой код с нуля не удастся, даже и не мечтайте :). Самое эффективное, что можно сделать — это точечно переписывать наиболее страшные куски, которые доставляют больше всего боли. А то, что не переписывается, инкапсулировать и не трогать. В результате получится, что части, в которых изменения происходят чаще всего, будут более-менее приличными, а старый древний копролит мамонта будет изолирован, и вам не надо будет туда лезть. Несколько лет назад я работал над продуктом, которому такой подход помог.
В нашем легаси проекте (Java 7, hybris, SAP и другие страшные слова) мы поставили на микросервисы. А что не получается выделить как сервис, делаем плагинами на scala. Но рефакторинг как таковой это конечно не заменит.
а еще есть старая инженерская поговорка, которая гласит, «если что-то работает — не трогай его»)))
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Старый код: почему он такой