Как провести рефакторинг быстро развивающегося кода?

Question

У меня есть некоторый исследовательский код, который является настоящим крысиным гнездом, с дублированием кода повсюду, и его явно необходимо реорганизовать. Тем не менее, кодовая база развивается, так как я придумываю новые варианты темы и встраиваю их в кодовую базу. Причина, по которой я так долго откладывал рефакторинг, заключается в том, что я чувствую, что в ту минуту, когда я провожу несколько дней, придумывая хорошие абстракции, просматривая, какие шаблоны дизайна подходят и т. Д., Я хочу попробовать какую-то новую непредвиденную идею о том, что делает мои абстракции совершенно неадекватными. Другими словами, из-за скорости, с которой развивается код, я действительно понятия не имею, где находятся линии абстракции, даже при том, что нет недостатка в (приблизительном) дублировании, и общая путаница в коде делает добавление материала к нему реальным боль. Каковы общие рекомендации по преодолению такой ситуации?

Answer 1

Не трать так долго на рефакторинг!

Когда вы собираетесь внести изменения в фрагмент кода, рассмотрите возможность его рефакторинга, чтобы облегчить изменение.

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

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

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

Answer 2

Ваша ситуация мне довольно знакома. При выполнении исследовательского кодирования вы часто не представляете, какой будет «правильная» абстракция, и, как вы говорите, она может меняться с каждой новой идеей.
Другие авторы предложили:

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

Однако для следственного исследовательского кода существует другая стратегия: прототип. Похоже, это то, чем вы сейчас занимаетесь: как можно быстрее кодировать, чтобы доказать концепцию. В этом нет ничего плохого, но прототип должен всегда отбрасываться. Изменяйте его до тех пор, пока у вас не будет всех необходимых данных и знаний, затем выбросьте прочь кода и начните заново с TDD и непрерывного рефакторинга, а также всех других стратегий «делать все правильно».

Не храните код. Не копируйте и не вставляйте ничего. Не возвращайтесь к этому. Просто начните с вашего нового знания.

Answer 3

Разработка через тестирование:

Красный, Зеленый, Рефакторинг. Промыть, повторить.

Поскольку это один из этапов в каждом цикле, вы заметите, что это ОЧЕНЬ МНОГО обычно незначительного рефакторинга. Так и должно быть.

Answer 4

Одновременно очищайте код. Всегда, когда вы прикасаетесь к классу, старайтесь оставлять уборщика класса таким, каким он был до того, как вы к нему прикоснулись ( «правило бойскаута» ). Рефакторинг лучше всего выполнять очень маленькими шагами, но очень часто.

Такие вещи, как переименование некоторой переменной, разбиение метода и т. Д., Занимают всего несколько секунд или минут. Большие рефакторинги, такие как разделение или присоединение к классам, могут занять час или два (и вы делаете это небольшими шагами, чтобы все тесты проходили как минимум каждые пять минут - в противном случае вы вошли в Refactoring Hell , и вам следует вернуться к последнему известному рабочему состоянию). Если вам потребуется несколько дней или недель, чтобы что-то реорганизовать, то это уже не «рефакторинг» - это больше похоже на переписывание.

Статья на эту тему: http://blog.objectmentor.com/articles/2007/07/20/whats-your-unit-of-measure

Answer 5

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

Gits Branch merge отлично подходит для подобных вещей, и вы легко поймете, если 2 человека вносят несовместимые изменения параллельно, не беспокоясь об остальной части кода.

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

Answer 6

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

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

Answer 7

CloneDR находит дубликаты кода, как точные копии, так и почти пропуски, в больших исходных системах, параметризованных синтаксисом языка. Он поддерживает Java, C #, COBOL, C ++, PHP и многие другие языки.

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

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

Еще более примечательно, что когда он показывает привязки параметров, используемые на каждом сайте клона, необходимом для вызова абстракции, он часто показывает случайный клонированный экземпляр, легко распознаваемый, когда связанные параметры концептуально несовместимы. Если параметр связан с переменными с именем YYYY-MM-DD, а одна из них - YY-MM-DD, тип параметра «его четырехзначный год» выглядит нарушенным, и в этом случае существует исправленное исправление Y2K. Поэтому при проверке привязок клонов часто обнаруживаются ошибки.

Answer 8

Иногда перезапись является единственным выбором. Похоже, это так.

Answer 9

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