Come dovrebbe essere abituato a pensare a FP come leggere il codice imperativo?

Capire il codice legacy è difficile. Non ha quasi nulla a che fare con funzionale e procedurale.

1. Crea una mappa di qualche tipo. Un diagramma componente dei pacchetti e dei moduli Python. Per ogni modulo, dovrai creare diagrammi di classe.

2. Usa l'interprete Python. Dovresti essere in grado di importare moduli, creare oggetti ed esercitarli in modo interattivo. Ecco perché Python è popolare. Puoi stampare type(x) per vedere che tipo è una variabile ( x ) in realtà.

3. In caso di dubbio, assicurati di leggere il codice di test dell'unità. Se non c'è un codice di test unitario, hai problemi grandi e incombenti oltre a imparare un nuovo codice base.

4. Scrivi cose giù. Inizia con documenti laterali. Quindi, quando pensi di sapere cosa sta succedendo, aggiungi commenti di docstring a funzioni, metodi e classi. Aggiungi questi primi e spesso.

5. Usa Sfinge con "autodoc" per raccogliere ciò che stai imparando.

La parte più importante è questa. È difficile mantenere le cose nella tua testa. È più facile conservare le cose sui file di documentazione.

I am having a very hard time reading imperative code. When an for-if-else-for-... nesting goes more than four levels deep, I completely lose the track of what's happening in the code.

Aspetta ... chiunque perde completamente la traccia del codice con livelli di nidificazione così profondi. O come diceva Linus Torvalds:

Se hai bisogno di più di 3 livelli di indentazione, sei comunque fregato e dovresti risolvere il tuo programma.

Maybe I should also mention that there aren't really many comments in the code, and the names are also not very intuitive.

Questo non suona come se la tua azienda seguisse le best practice comuni.

Se fossi in te, proverei solo a capire il codice base per disciplina e forza. Basta scavare dentro, ancora e ancora e ancora. Probabilmente è come niente. In questo momento ti senti come se fossi sott'acqua e non riesci a respirare, ma continui ad esaminare la base di codice e presto salterai in superficie.

Temo che alla tua domanda manchino i dettagli tecnici per offrirti un buon consiglio su come comprendere il codebase, ma non è mai sbagliato sottoporlo a colleghi esperti in alcune sessioni. Lascia che ti spieghino l'architettura generale e in che modo i diversi componenti interagiscono tra loro, oltre alle decisioni di implementazione che hanno preso.

È difficile dare consigli generali per il passaggio dai linguaggi funzionali a quelli imperativi / OO. Certo, potrei citare alcune frasi floreali come "Devi pensare agli stati e ai comportamenti degli oggetti", ma questi non ti aiuteranno molto, penso che questo sia qualcosa che devi provare.

Se (grande se dalle cattive pratiche che descrivi) ci sono dei test unitari, allora puoi guardare quelli per vedere come viene testato il codice. Questo può offrire una buona visione di ciò che fa il codice.

Altrimenti, suggerirei di leggere più codice Python generico per abituarmi al modo in cui è scritto.

Potresti provare a tradurre alcuni frammenti da Python in pseudo-Haskell o qualsiasi altra cosa tu voglia. Ciò può darti un senso per quali costruzioni imperative mappare vagamente in quali costruzioni funzionali. Man mano che ottieni più esperienza, le costruzioni imperative inizieranno a sentirsi più native.

Sono passato dalla programmazione di OCaml e Haskell alla programmazione di Java e Python, e la mia esperienza è che la programmazione imperativa non è il salto più grande della tipizzazione dinamica, che fino ad oggi sembra aliena.

Ti suggerisco di inserire i punti di interruzione e iniziare a usare il comando Successivo (come se si stia eseguendo il debug), questo ti aiuterà a capire il flusso (probabilmente sui rami, ci sono percorsi che sono più probabili da prendere, su quelli che dovresti concentrarsi per ottenere l'idea generale del codice).

(Ho avuto buoni risultati con Eclipse insieme a PyDev come plugin di Eclipse)