Come dovrebbe qualcuno abituato al pensiero di FP leggere il codice imperativo?

Mi sono laureato all'università circa cinque mesi fa e ho lavorato in una startup locale per quattro mesi. Mentre ero all'università, ho studiato Haskell, F # ecc. Per conto mio. Ci è stato insegnato Java all'università, ma sono stato molto presto esposto alla programmazione funzionale e ci ho passato molto più tempo di quanto non avessi fatto con la programmazione imperativa. Di conseguenza, il mio cervello è predisposto per un pensiero funzionale. La società a cui ho aderito utilizza Python e il codice è fortemente imperativo. Sto facendo fatica a leggere il codice imperativo. Non riesco a tenere traccia delle mutazioni. Quando un annidamento for-if-else-for -... supera i quattro livelli, perdo completamente la traccia di ciò che sta accadendo nel codice. Per aggiungerlo, Python è un linguaggio dinamico, quindi non ci sono tipi nel codice. E' Sono passate settimane da quando ho cercato di capire una parte della nostra base di codice (che è presumibilmente "moderatamente complessa"), ma finora non ho compiuto progressi apprezzabili nella sua comprensione. Per favore, offrimi alcune tecniche pratiche su come dovrei capire il codice. Grazie in anticipo!

Modifica:
forse dovrei anche menzionare che non ci sono davvero molti commenti nel codice, e anche i nomi non sono molto intuitivi.

Comprendere il codice legacy è difficile. Non ha quasi nulla a che fare con funzionale vs. 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 di che tipo è effettivamente una variabile ( x ).

3. In caso di dubbi, assicurarsi di leggere il codice di test dell'unità. Se non esiste un codice di test unitario, si hanno problemi grandi e profondi oltre all'apprendimento di una nuova base di codice.

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

5. Usa Sphinx con 'autodoc' per raccogliere ciò che stai imparando.

La parte più importante è questa. È difficile tenere le cose in testa. È più facile tenere le cose nei file di documentazione.

Sto facendo fatica a leggere il codice imperativo. Quando un annidamento for-if-else-for -... supera i quattro livelli, perdo completamente la traccia di ciò che sta accadendo nel codice.

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

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

Forse dovrei anche menzionare che non ci sono molti commenti nel codice e che i nomi non sono molto intuitivi.

Non sembra che la tua azienda stia rispettando le migliori pratiche comuni.

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

Temo che alla tua domanda manchino i dettagli tecnici per offrirti un buon consiglio su come comprendere la base di codice, ma non è mai sbagliato esaminarla con colleghi esperti in poche sessioni. Lascia che ti spieghino l'architettura generale e come i diversi componenti interagiscono tra loro, insieme alle decisioni di implementazione che hanno preso.

È difficile dare consigli generali per il passaggio da linguaggi funzionali a linguaggi imperativi / OO. Certo, potrei citare alcune frasi fiorite come "Devi pensare a stati e 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 test unitari, puoi guardarli per vedere come viene testato il codice. Questo può offrire una buona visione di ciò che fa il codice.

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

Potresti provare a tradurre alcuni frammenti da Python in pseudo-Haskell o qualunque cosa ti piaccia. Ciò può darti un'idea di quali costruzioni imperative si associano liberamente a quali costruzioni funzionali. Man mano che acquisisci 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 è così grande come la digitazione dinamica, che fino ad oggi sembra aliena.

Ti suggerisco di inserire punti di interruzione e iniziare a utilizzare il comando Successivo (come se stessi eseguendo il debug), questo ti aiuterà a capire il flusso (probabilmente sui rami, ci sono percorsi che hanno maggiori probabilità di essere presi, su quelli che dovresti concentrarti per ottenere l'idea generale del codice).

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