Импорт модуля сопоставления в Python для упрощения рефакторинга
У меня есть куча модулей Python, которые я хочу очистить, реорганизовать и рефакторинг (есть дублированный код, какой-то неиспользуемый код ...), и мне интересно, есть ли инструмент для создания карты того, какой модуль использует какой другой модуль.
В идеале мне нужна такая карта:
main.py
-> task_runner.py
-> task_utils.py
-> deserialization.py
-> file_utils.py
-> server.py
-> (deserialization.py)
-> db_access.py
checkup_script.py
re_test.py
main_bkp0.py
unit_tests.py
... чтобы я мог сказать, какие файлы я могу начать перемещать в первую очередь (file_utils.py, db_access.py), эти файлы не используются моим main.py и поэтому могут быть удалены, и т. д. (на самом деле я работаю примерно с 60 модулями)
Написание сценария, который делает это, вероятно, было бы не очень сложный (хотя есть разные синтаксисы для обработки импорта), но я также ожидаю, что я не первый, кто захочет это сделать (и если кто-то сделает инструмент для этого, он может включать другие аккуратные такие функции, как сообщение мне, какие классы и функции, вероятно, не используются).
Знаете ли вы какие-либо инструменты (даже простые скрипты), которые помогают реорганизации кода?
Знаете ли вы более точный термин для того, что я пытаюсь сделать? Реорганизация кода?
2 ответа
Python modulefinder делает это. Довольно легко написать скрипт, который превратит эту информацию в график импорта (который вы можете отобразить, например, с помощью graphviz): вот понятное объяснение. Существует также snakefood , который делает всю работу за вас (и использует AST тоже!)
Вы можете заглянуть в pylint или pychecker для получения дополнительной информации. общие задачи технического обслуживания.
Написание скрипта, который делает это, вероятно, не будет очень сложным (хотя существуют различные синтаксис для обработки импорта),
Это тривиально. Есть импорт и из импорта модуля. Два синтаксиса для обработки.
Знаете ли вы более точное определение того, что я пытаюсь сделать? Реорганизация кода?
Дизайн. Это называется дизайн. Да, вы реорганизуете существующий дизайн, но...
Правило первое
Не начинайте разработку с тем, что у вас есть. Если вы это сделаете, вы будете только «кусать по краям», внося небольшие и иногда несущественные изменения.
Правило второе.
Начните разработку с того, что вы должны были иметь, если бы вы были умнее. Подумайте широко и ясно о том, что вы действительно должны делать. Не обращайте внимания на то, что вы сделали.
Правило третье
Проектируйте с нуля (или ново, как говорят некоторые) с правильной архитектурой пакетов и модулей.
Создайте для этого отдельный проект.
Правило четвертое
Сначала проверьте. Напишите модульные тесты для вашей новой архитектуры. Если у вас есть существующие модульные тесты, скопируйте их в новый проект. Измените импорт, чтобы он отражал новую архитектуру, и перепишите тесты, чтобы выразить ваше великолепное новое упрощение.
Все тесты не пройдены, потому что вы не переместили код. Это хорошая вещь.
Правило пятое
Перемещайте код в новую структуру последним. Перестаньте перемещать код, когда тесты пройдены.
Кстати, для этого вам не нужно анализировать импорт. Вы просто используете grep для поиска модулей и классов.Старый импорт и запутанные отношения между старыми импортами не имеют значения, и их не нужно анализировать. Вы выбрасываете это. Вам не нужны инструменты умнее, чем grep.
Если вам хочется переместить код, вы должны быть очень дисциплинированными. (1) у вас должны быть неудачные тесты, а затем (2) вы можете переместить некоторый код, чтобы пройти неудачный тест (ы).