Como alguém deveria pensar em FP para ler código imperativo?

14

Eu me formei na universidade há cinco meses e trabalho em uma startup local há quatro meses. Enquanto na universidade, eu estudei Haskell, F # etc por conta própria. Nos ensinaram Java na universidade, mas eu fui exposto à programação funcional muito em breve, e passei muito mais tempo com ele do que com programação imperativa. Como resultado, meu cérebro está preparado para um pensamento funcional. A empresa à qual eu me juntei usa o Python, e o código é altamente imperativo. Estou tendo muita dificuldade em ler código imperativo. Eu não posso manter um rastro de mutações. Quando um aninhamento for-if-else-for -... vai a mais de quatro níveis de profundidade, perco completamente a noção do que está acontecendo no código. Para adicionar, o Python é uma linguagem dinâmica, portanto, não há tipos no código. Já se passaram semanas desde que eu tenho tentado entender uma parte da nossa base de código (que é supostamente 'moderadamente complexa'), mas eu não fiz nenhum progresso apreciável até agora em entendê-la. Por favor, me ofereça algumas técnicas práticas sobre como eu deveria entender esse código. Obrigado antecipadamente!

Editar:
Talvez eu deva mencionar também que não há muitos comentários no código, e os nomes também não são muito intuitivos.

    
por an0nym0us c0ward 27.09.2011 / 13:15
fonte

5 respostas

14

Entender o código legado é difícil. Não tem quase nada a ver com funcional versus processual.

  1. Crie um mapa de algum tipo. Um diagrama de componentes dos pacotes e módulos do Python. Para cada módulo, você precisará criar diagramas de classes.

  2. Use o interpretador Python. Você deve poder importar módulos, criar objetos e exercitá-los interativamente. É por isso que o Python é popular. Você pode imprimir type(x) para ver qual tipo é uma variável ( x ).

  3. Em caso de dúvida, leia o código de teste da unidade. Se não houver código de teste de unidade, você terá problemas grandes e iminentes, além de aprender uma nova base de código.

  4. Escreva as coisas. Comece com documentos colaterais. Então, quando você pensa que sabe o que está acontecendo, adicione comentários docstring a funções, métodos e classes. Adicione estes cedo e muitas vezes.

  5. Use o Sphinx com 'autodoc' para coletar o que você está aprendendo.

A parte mais importante é isso. É difícil manter as coisas na sua cabeça. É mais fácil manter as coisas nos arquivos da documentação.

    
por 27.09.2011 / 15:52
fonte
12

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.

Espere ... alguém perde completamente o código com níveis de aninhamento tão profundos. Ou como Linus Torvalds colocou:

Se você precisar de mais de 3 níveis de recuo, você está ferrado de qualquer maneira e deve corrigir o seu programa.

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

Isso não soa como se sua empresa estivesse seguindo as práticas recomendadas comuns.

Se eu fosse você, tentaria entender a base de código por disciplina e força. Basta cavar, de novo e de novo e de novo. É provavelmente como qualquer coisa. Agora você se sente como se estivesse debaixo d'água e não consegue respirar, mas continue examinando a base de código e logo você nadará até a superfície.

Temo que sua pergunta não tenha os detalhes técnicos para oferecer um bom conselho sobre como entender a base de código, mas nunca é errado passar por isso com colegas experientes em algumas sessões. Deixe-os explicar-lhe a arquitetura geral e como os diferentes componentes interagem uns com os outros, juntamente com as decisões de implementação que eles tomaram.

É difícil dar conselhos gerais para a transição de linguagens funcionais para linguagens funcionais / OO. Claro, eu poderia mencionar algumas frases floridas como "Você precisa pensar sobre estados e comportamentos de objetos", mas isso não vai ajudar muito, eu acho que isso é algo que você tem que experimentar.

    
por 27.09.2011 / 13:33
fonte
2

Se (grande se a partir das práticas ruins que você descreve) houver testes de unidade, então você pode olhar para aqueles para ver como o código é testado. Isso pode oferecer uma boa visão do que o código faz.

Caso contrário, sugiro que você leia mais código python genérico para se acostumar com a maneira como está escrito.

    
por 27.09.2011 / 13:44
fonte
2

Você pode tentar traduzir alguns fragmentos do Python para o pseudo-Haskell ou o que quiser. Isso pode lhe dar uma ideia do que as construções imperativas mapeiam livremente em quais construções funcionais. À medida que você ganha mais experiência, as construções imperativas começarão a parecer mais nativas.

Eu passei de programação OCaml e Haskell para programação Java e Python, e minha experiência é que a programação imperativa não é tão grande como digitação dinâmica, que até hoje parece alienígena.

    
por 27.09.2011 / 20:17
fonte
1

Sugiro que você coloque pontos de interrupção e comece a usar o comando Avançar (como se estivesse depurando), isso ajudará a entender o fluxo (provavelmente nas ramificações, há caminhos com maior probabilidade de serem capturados, naqueles que você deveria concentrar-se para obter a ideia geral do código).

(Eu tive bons resultados com Eclipse junto com PyDev como plugin do Eclipse)

    
por 28.09.2011 / 00:19
fonte