Как кто-то привык к ФП мышления читать императивный код?

Я закончил университет около пяти месяцев назад и проработал в местном стартапе последние четыре месяца. В университете я изучал Haskell, F # и т. Д. Самостоятельно. В университете нас учили Java, но я очень скоро познакомился с функциональным программированием и провел с ним гораздо больше времени, чем с императивным программированием. В результате мой мозг настроен на функциональное мышление. Компания, к которой я присоединился, использует Python, и код крайне необходим. Мне очень трудно читать императивный код. Я не могу отслеживать мутации. Когда вложение для-если-еще-для -... достигает глубины более четырех уровней, я полностью теряю след того, что происходит в коде. Чтобы добавить к этому, Python является динамическим языком, поэтому в коде нет типов. Это' Прошло несколько недель с тех пор, как я пытался понять часть нашей кодовой базы (которая предположительно «умеренно сложна»), но я до сих пор не добился заметного прогресса в ее понимании. Пожалуйста, предложите мне несколько практических приемов о том, как мне лучше понять этот код. Заранее спасибо!

Изменить:
Может быть, я должен также упомянуть, что в коде не так много комментариев, и имена также не очень интуитивно понятны.

Понять старый код сложно. Это почти не имеет ничего общего с функциональным и процедурным.

1. Создайте карту какого-нибудь вида. Компонентная схема пакетов и модулей Python. Для каждого модуля вам нужно создать диаграммы классов.

2. Используйте интерпретатор Python. Вы должны быть в состоянии импортировать модули, создавать объекты и осуществлять их интерактивно. Вот почему Python популярен. Вы можете распечатать, type(x)чтобы увидеть, какой тип переменной ( x ) на самом деле.

3. В случае сомнений обязательно прочитайте код модульного теста. Если нет кода модульного теста, у вас есть большие, надвигающиеся проблемы в дополнение к изучению новой базы кода.

4. Запишите вещи вниз. Начните с дополнительных документов. Затем, когда вы думаете, что знаете, что происходит, добавьте комментарии к документации для функций, методов и классов. Добавляйте их рано и часто.

5. Используйте Sphinx с 'autodoc', чтобы собрать то, что вы изучаете.

Самая важная часть это. Трудно держать вещи в голове. Проще хранить вещи в файлах документации.

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

Подождите ... кто-нибудь полностью теряет след кода с такими глубокими уровнями вложенности. Или, как сказал Линус Торвальдс:

Если вам нужно более 3 уровней отступа, вы все равно облажались и должны исправить вашу программу.

Возможно, я должен также упомянуть, что в коде не так много комментариев, и имена также не очень интуитивны.

Это не звучит так, как будто ваша компания придерживается общих передовых методов.

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

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

Трудно дать общий совет по переходу с функциональных языков на императивные / OO. Конечно, я мог бы упомянуть несколько цветочных фраз, таких как «Вам нужно подумать о состояниях и поведении объектов», но это не очень вам поможет, я думаю, это то, что вы должны испытать.

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

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

Вы можете попробовать перевести некоторые фрагменты из Python в псевдо-Haskell или что угодно. Это может дать вам представление о том, какие императивные конструкции слабо отображаются в какие функциональные конструкции. По мере того, как вы получаете больше опыта, императивные конструкции начнут чувствовать себя более родными.

Я перешел от программирования OCaml и Haskell к программированию на Java и Python, и мой опыт показывает, что императивное программирование не такой большой скачок, как динамическая типизация, которая до сих пор кажется чуждой.

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

(У меня были хорошие результаты с Eclipse вместе с PyDev'ом как плагином Eclipse)