Методы рефакторинга для Clojure

Question

Я знаком с рефакторингом довольно больших баз кода в C # и Java, но Clojure - это нечто другое, особенно потому, что он:

• Имеет сочетание макросов и функций в типичном коде (т. е. вам может понадобиться рефакторинг из макроса в функцию или наоборот?)
• В большинстве случаев использует динамическую типизацию (поэтому вы не получаете проверки на время компиляции на правильность вашего рефакторизованного кода)
• Функционально, а не объектно-ориентировано в стиле
• Имеет меньшую поддержку рефакторинга в текущих средах разработки
• Менее терпимо к циклическим зависимостям в базах кода (что усложняет перемещение блоковкод / ​​определения вокруг!)

Учитывая вышесказанное, как лучше всего подойти к рефакторингу кода в Clojure?

Answer 1

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

супер краткий и полностью неполный обзор его подхода к добавлению порядка в неструктурированный код:

• разделите код на «Legacy» (без тестов) и все остальное.
• создать тест
• повторяется на обеих половинах.

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

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

Answer 2

Я не эксперт.Но в любом случае:

• Держитесь подальше от God функций.Если у вас есть большая функция, разбейте ее на более мелкие функции, и каждая из этих функций выполняет одно и делает это хорошо.
• Если вы обнаружите использование массивов Java (и нет необходимостииспользуйте их), конвертируйте их в последовательности Clojure.
• Embrace defrecord и defprotocol.
• Держитесь подальше от макросов, если вы действительно не можете продолжить работу без написания макроса.
• Когда это возможно, отдавайте предпочтение ленивым последовательностям, а не рекурсии.
• При создании службы поместите контракт в свое собственное пространство имен, а реализацию - в собственное пространство имен.передача функций в качестве параметров другим функциям.
• Используйте деструктуризацию для arglist функции, когда это возможно.Это облегчит понимание реализации функции.
• Рассмотрите возможность использования проекта Prismatic Schema.

Также взгляните на CursiveClojure.Я думаю, что это действительно многообещающе.

Я не создатель CursiveClojure.

Answer 3

Я не знаком с рефакторингом довольно больших баз кода в C # или Java, но здесь идет речь.

Clojure:

• Имеет сочетание макросов и функций : я могу ошибаться, но я думаю, вы обнаружите, что рефакторинг редко движется интерфейс между макросами и функциями.

• Использует динамическую типизацию (поэтому вы не получаете проверки времени компиляции для реорганизованного кода) : ... ни для любого другого кода: вам нужно больше тестов вв любом случае.

• Функционально, а не объектно-ориентировано в стиле Рефакторинг выражается в терминах ОО, но часто выдерживает простую транскрипцию: метод для функции, класс для функции или замыкание иликарта.

• Имеет меньшую поддержку рефакторинга в текущих IDE True: больше занятой работы.

• Менее терпимо к циклическим зависимостям в базах кода Два случая: взаимная рекурсия в пространстве имен / файле должна быть легче справляться, чем она есть;но циклические зависимости между пространствами имен / пакетами вызывают путаницу и неоднозначность.Я думаю, что Java только позволил им, потому что C ++ сделал, и C # следовал примеру.

Мне показалось полезным просмотреть каталог рефакторингов Мартина Фаулера *1042*.Большинство переживают перевод с ОО на функциональный жаргон.Некоторые (например, Изменить значение на Ссылка ) исчезают.