Каковы ограничения рефакторинга?

Question

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

Answer 1

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

Answer 2

Рефакторинг может быть рискованным

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

Это может быть особенно актуально, когда новый или молодой член команды, не имеющий полного опыта работы с этой системой, решает внедрить новые крутые технологии или идеи в стабильную в остальном систему.Часто, когда новые члены команды недостаточно хорошо интегрированы в команду и не получают достаточного руководства, они могут начать продвигать проект в направлениях, не предусмотренных всей командой.

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

Эти проблемы часто возникают в команде, работающей над устаревшими системами.Зачастую никакие улучшения, изменяющие мир, не планируются, поэтому команда консервативна в своем дизайне.Их цель — предотвратить появление новых ошибок и исправить старые с помощью пары дополнительных функций.Новый член команды может прийти и расстроить тележку с яблоками, настаивая на том, что он перепишет определенные подсистемы кода.Создаются новые ошибки, и пользователи довольно стабильного продукта расстраиваются, потому что с этой точки зрения программное обеспечение становится все хуже.

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

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

Answer 3

Я не совсем уверен, что ваш вопрос верен.Вы спрашиваете об ограничениях рефакторинга.Однако рефакторинг предполагает переписывание кода.Как могут быть ограничения на то, что вы переписываете?Вы можете полностью заменить старый код в ходе масштабного рефакторинга, по частям.По сути, вы можете завершить рефакторинг, не сохранив ни единого символа исходного кода, хотя это, по общему признанию, крайность.Учитывая столь дальний предел возможностей рефакторинга, как вы можете предполагать, что могут быть какие-либо ограничения?Если бы весь окончательный код мог быть совершенно новым, у вас не было бы больше ограничений, чем если бы вы написали окончательный код с нуля.Однако написание одного и того же итогового кода с нуля дает вам меньше оснований для дальнейшего развития и меньше возможностей для итеративной разработки, поэтому я должен ответить встречным вопросом:Разве любой рефакторинг по своей сути не имеет меньших ограничений, чем любое переписывание?

Answer 4

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

Таким образом, существует риск, что на рефакторинг уйдет слишком много времени.

Answer 5

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

Answer 6

На превосходный ответ Кева: «Эффективная работа с устаревшим кодом» Майкла Фезерса должна быть обязательной к прочтению для людей, работающих в области разработки программного обеспечения.