Лекция: MIGRATE DATA (МИГРАЦИЯ ДАННЫХ)

Каким образом можно перейти от одного представления к другому? Временно дублируйте данные.

Как

Вначале рассмотрим версию «от внутреннего к внешнему». В рамках этого под­хода вы вначале изменяете внутреннее представление, а затем меняете внешний

интерфейс.

1. Создайте экземплярную переменную в новом формате.

2. Инициализируйте переменную нового формата везде, где инициализиру­ется переменная старого формата.

3. Используйте переменную нового формата везде, где используется пере­менная старого формата.

4. Удалите старый формат.

5. Измените внешний интерфейс таким образом, чтобы использовать новый формат.

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

1. Добавьте параметр в новом формате

2. Обеспечьте преобразование параметра в новом формате во внутреннее представление, обладающее старым форматом.

3. Удалите параметр в старом формате.

4. Замените использование старого формата на использование нового формата.

5. Удалите старый формат.

EXTRACT METHOD (ВЫДЕЛЕНИЕ МЕТОДА)

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

Как

Выделение метода на самом деде является несколько более сложным атомар­ным рефакторингом. Здесь я опишу самый типичный случай. К счастью, многие среди разработки поддерживают автоматическое выполнение этого рефакторнига. Итак, чтобы выделить метод:

1. Определите фрагмент кода, который можно выделить в отдельный метод. Хорошими кандидатами являются тела циклов, сами циклы, а также ветви условных опера юрой.

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

3. Скопируйте код из старою метода в новый метод. Откомпилируйте его.

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

5. Сделайте так, чтобы в нужном месте старый метод обращался к новому ме­тоду.

Зачем

Я использую Extract Method (Выделение.метода), когда пытаюсь понять сложный код. «Значит так, этот кусок кода делает вот это. А этот кусок делает это. К чему мы там дальше обращаемся?* После получаса код выглядит гораздо лучше, ваш партер начинает понимать, что выдействительно оказываете ему помощь» а вы существенно лучше понимаете, что же все-таки происходи! внутри кода.

Я использую выделение метода для 70ix>. чгобы избавиться ог дублирования, когда вижу, что два метода обладают сходными участками кода. В этом случае я выделяю схожие участки в отдельный метод. (Браузер рефакторинги Smalltalk Rcfactonng Browser выполняет еще более полезную задачу: он просматривает код в поисках метода, аналогичного коду, который вы намерены выделить, и в случае, если такой метод уже есть, предлагает вале использовагь уже существующий ме­тод вместо того, чтобы создавать новый.)

Разделение методов на множество мелких кусочков может зайти слишком да­леко. Если я не вижу, кула идти дальше, я часто использую Inline Method (Встраи­вание метода), чтобы собрать код в одном месте и увидеть новый, более удобный способ разделения.

33. Понятие рефакторинга. Рефакторинги «Встраивание метода», «Выделение интерфейса», «Перемещение метода».

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

Отсюда следует, что на программиста, работающею о стиле TDD, возлагается важная обязанность: он должен иметь лопаточное количество тестов» описываю­щих семантику программы. Достаточное по крайней мере настолько, настолько он может судить на момент завершения работы над кодом. Необходимо понимать, что рефакторинг выполняется не с учетом всех существующих тестов, а с учетом всех шзможнмх гсстов. Фраза наподобие: «Я знаю, что там была проблема, но все тесты сработали, поэтому я посчитал код завершенным и интегрировалсто и сис­тему», — не может считаться оправданием. Пишите больше тестов.