¿Cómo debería alguien acostumbrarse al pensamiento FP leer el código imperativo?

Me gradué de la universidad hace unos cinco meses, y he estado trabajando en una startup local durante los últimos cuatro meses. Mientras estaba en la universidad, estudié Haskell, F #, etc. por mi cuenta. Nos enseñaron Java en la universidad, pero muy pronto estuve expuesto a la programación funcional y he pasado mucho más tiempo con él que con la programación imperativa. Como resultado, mi cerebro está conectado para un pensamiento funcional. La compañía a la que me he unido usa Python, y el código es muy imperativo. Me está costando mucho leer el código imperativo. No puedo hacer un seguimiento de las mutaciones. Cuando un anidamiento for-if-else-for -... tiene más de cuatro niveles de profundidad, pierdo completamente la noción de lo que sucede en el código. Para agregarle, Python es un lenguaje dinámico, por lo que no hay tipos en el código. Eso' Han pasado semanas desde que he tratado de comprender una parte de nuestra base de código (que supuestamente es "moderadamente compleja"), pero hasta ahora no he logrado ningún progreso apreciable en su comprensión. Por favor, ofrézcame algunas técnicas prácticas sobre cómo debo entender el código. ¡Gracias por adelantado!

Editar:
Tal vez también debería mencionar que en realidad no hay muchos comentarios en el código, y los nombres tampoco son muy intuitivos.

Comprender el código heredado es difícil. No tiene casi nada que ver con funcional versus procesal.

1. Crea un mapa de algún tipo. Un diagrama de componentes de los paquetes y módulos de Python. Para cada módulo, deberá crear diagramas de clase.

2. Utiliza el intérprete de Python. Debería poder importar módulos, crear objetos y ejercitarlos interactivamente. Es por eso que Python es popular. Puede imprimir type(x)para ver qué tipo es realmente una variable ( x ).

3. En caso de duda, asegúrese de leer el código de prueba de la unidad. Si no hay un código de prueba de unidad, tiene grandes problemas inminentes además de aprender una nueva base de código.

4. Escribe cosas. Comience con documentos laterales. Luego, cuando crea que sabe lo que está sucediendo, agregue comentarios de docstring a funciones, métodos y clases. Agregue esto temprano y con frecuencia.

5. Use Sphinx con 'autodoc' para recopilar lo que está aprendiendo.

La parte más importante es esta. Es difícil mantener las cosas en tu cabeza. Es más fácil mantener las cosas en los archivos de documentación.

Me está costando mucho leer el código imperativo. Cuando un anidamiento for-if-else-for -... tiene más de cuatro niveles de profundidad, pierdo completamente la noción de lo que sucede en el código.

Espere ... cualquiera pierde completamente el seguimiento del código con niveles de anidamiento tan profundos. O como dijo Linus Torvalds:

Si necesita más de 3 niveles de sangría, de todos modos está jodido y debe arreglar su programa.

Quizás también debería mencionar que en realidad no hay muchos comentarios en el código, y los nombres tampoco son muy intuitivos.

Esto no parece que su empresa se adhiera a las mejores prácticas comunes.

Si yo fuera tú, solo trataría de entender la base del código por disciplina y fuerza. Simplemente profundiza en él, una y otra y otra vez. Probablemente sea como cualquier cosa. En este momento sientes que estás bajo el agua y no puedes respirar, pero continúa examinando la base de código y pronto nadarás a la superficie.

Me temo que su pregunta carece de los detalles técnicos para ofrecerle un buen consejo sobre cómo entender la base de código, pero nunca está mal analizarla con colegas experimentados en unas pocas sesiones. Permita que le expliquen la arquitectura general y cómo interactúan los diferentes componentes entre sí, junto con las decisiones de implementación que tomaron.

Es difícil dar consejos generales para la transición de los lenguajes funcionales a los imperativos / OO. Claro, podría mencionar algunas frases floridas como "Necesitas pensar en los estados y comportamientos de los objetos", pero estos no te ayudarán mucho, creo que esto es algo que tienes que experimentar.

Si (grande si de las malas prácticas que describe) hay pruebas unitarias, puede verlas para ver cómo se prueba el código. Esto puede ofrecer una buena idea de lo que hace el código.

De lo contrario, sugeriría leer más código genérico de Python para acostumbrarse a la forma en que está escrito.

Puede intentar traducir algunos fragmentos de Python a pseudo-Haskell o lo que quiera. Eso puede darle una idea de qué construcciones imperativas se asignan libremente a qué construcciones funcionales. A medida que obtenga más experiencia, las construcciones imperativas comenzarán a sentirse más nativas.

Pasé de programar OCaml y Haskell a programar Java y Python, y mi experiencia es que la programación imperativa no es un salto tan grande como el tipeo dinámico, que hasta el día de hoy se siente extraño.

Le sugiero que ponga puntos de interrupción y comience a usar el comando Siguiente (como si estuviera depurando), esto lo ayudará a comprender el flujo (probablemente en las ramas, hay caminos que es más probable que se tomen, en los que debe concentrarse para obtener La idea general del código).

(Tuve buenos resultados con Eclipse junto con PyDev como complemento de Eclipse)