В недавних постах (мой, комментарии читателей) я рассказывал, как отличить плохой рефакторинг от хорошего и какие три обязательных условия последний должен соблюдать. Сегодня покажу конкретный пример правильной рефакторинга — на основе миграции с Objective‑C (далее — ObjC) на Swift, которую ранее я вообще не отнес к рефакторингу. Но в сегодняшнем посте мы увидим, что и эту работу при правильной организации можно превратить в рефакторинг, соблюдая 3 необходимых условия правильного рефакторинга.

Apple выпустила отличную инструкцию по миграции (Migrating Your Objective‑C Code to Swift), и её принципы работают не только для пары ObjC/Swift, но и для других языковых переходов — например, Java → Kotlin или Java -> C#.

Разберу ключевые моменты из неё — и покажу, как они стыкуются с нашими правилами «правильного рефакторинга».

Миграция — это не просто «переписать на Swift»

Apple прямо говорит: смысл миграции в том, чтобы улучшить архитектуру, логику или производительность. Это ровно то, о чём я говорил в прошлом посте (ссылка): простое переписывание кода с одного языка на другой — не рефакторинг, а пустая трата времени и риск. Если в итоге ничего не стало лучше, а только изменился синтаксис — вы не сделали рефакторинг. Вы просто «переписали» и бесполезно потратили бесценные ресурсы.

Итеративность: маленькими кусочками

Второй важный момент: миграцию не нужно делать «всё и сразу». Можно и нужно двигаться маленькими шагами, потому что ObjC и Swift отлично работают вместе — как на уровне компиляции, так и на уровне ABI. Это напрямую связано с нашим правилом: сокращать объём кода, который необходимо подвергнуть рефакторингу. Чем меньше код, который вы трогаете, тем проще контролировать результат и тем ниже риск сломать что‑то важное.

Совместимость и читаемость

Третий момент, на который делает упор Apple: ObjC специально модернизировали, чтобы он был максимально овместим с концепциями Swift. Это не про «чтобы было удобно компилировать», а про читаемость и понимание взаимодействия двух языков. Когда вы видите в одном проекте ObjC‑классы и Swift‑код, важно, чтобы они не выглядели как два разных мира. И это снова пересекается с нашими критериями рефакторинга: главная его цель – сделать код проще читаемым и более понятным.

Самый эффективный подход: класс за классом, снизу вверх

Apple рекомендует мигрировать файл за файлом или класс за классом, начиная с самых «нижних» элементов в цепочке наследования — то есть с конечных потомков.

Почему это работает: вы локализуете изменения и не трогаете базовые абстракции раньше времени. Это и есть та самая локализация изменений, о которой мы столько говорили.

Мой личный приём: пустой Swift‑наследник

От себя добавлю ещё один приём, который радикально сокращает объём изменений: не переписывайте сразу даже самый нижний класс. Вместо этого создайте пустой Swift‑класс, который наследуется от ObjC‑класса.

Что это даёт: * Вы сразу получаете возможность писать новый функционал на Swift, не трогая старый код. * Старый ObjC‑код остаётся нетронутым — а значит, сохраняется его поведение (это и есть гарантиястабильности). * Вы следуете принципу Open/Closed (вот тут мы подробнее об этом рассказываем): класс открыт для расширения (через Swift‑наследника) и закрыт для модификации (оригинальный ObjC‑класс не правим).

Это не «хитрость», а вполне рабочий способ минимизировать риски и объём работ.

Тесты: страховка при миграции

Apple в своей инструкции ничего не говорит про тесты — но мы‑то знаем, что без них любая миграция превращается в лотерею. Тесты дают гарантию, что поведение не изменилось. А это — обязательное условие рефакторинга. Если вы меняете код, но не можете доказать, что он делает то же самое — это не рефакторинг.

При этом, если вы используете подход с пустым Swift‑наследником и минимально трогаете старый код, объём потенциально опасных изменений сильно сокращается. В таких случаях даже поверхностного тестирования может быть достаточно, чтобы поймать критические ошибки.