Como ler milhares de linhas de código sem nenhuma documentação? [fechadas]

Anteriormente, eu estava procurando por um bom controle TimeLine para um projeto WPF. Encontrei uma resposta aqui que me direciona para esse projeto CodePlex .

Agora, quero alterar o código para alimentar minhas necessidades de cultura. Mas existem algumas incompatibilidades!

Minha pergunta é:

Como você interage com milhares de linhas de código?

EDITAR:

Qualquer atalho será ótimo!

Você adiciona comentários ao código-fonte quando o entende o suficiente para poder fazer isso. Refatorar esses comentários vigorosamente à medida que você entende cada vez mais.

1. Percorrer o código
2. Renomeie conforme necessário
3. Refatorar conforme necessário
4. Repita até você entender completamente

... e o código agradecerá por isso. ;-)

Tome uma ação única, depure (de novo e de novo) o código para descobrir como essa ação é realizada. Anote o mesmo em linguagem simples para entender melhor!

Algo que Joel Spolsky escreveu há muito tempo quando em seu blog (não consegue encontrar o artigo agora) realmente ficou comigo em relação a isso:

Ele disse que o código não é uma linguagem humana natural, mas, como programadores, somos facilmente levados a pensar que é e que devemos ser capazes de lê-lo como tal. Conseqüentemente, muitos de nós analisamos o novo código e esperamos poder "lê-lo" e entendê-lo imediatamente, como se fosse um bloco de texto em inglês.

Então, acho que a chave é basicamente ser lenta, metódica e científica. E como outros já disseram - comente (e até refatorar) à medida que avança. Não caia na mentalidade de "Eu deveria apenas olhar e entender imediatamente".

Ah, e sim, eu ainda caio nessa armadilha às vezes. "Faça como eu digo, não como eu faço", e tudo isso. :)

A SE-Radio entrevistou Dave Thomas sobre esse mesmo assunto

Este episódio de podcast tem muitas dicas e técnicas para entrar na 'cultura' do projeto e entender como os habitantes originais viviam.

Eu tive que fazer isso recentemente com um projeto de mais de 100.000 LOC. Minha primeira ideia foi que é mais fácil ver padrões de gráficos de 100 ou até 1000 nós do que de 100.000 linhas de texto.

Por isso, passei 45 minutos e escrevi um pequeno programa Python (<100LOC) para analisar o que eu precisava dele e desenhar os relacionamentos dos objetos. Eu criei a fonte Graphviz , que é uma linguagem muito fácil de gerar. (Não há nada de especial em Python aqui: Ruby ou C # ou Common Lisp ou qualquer outra coisa que possa fazer isso da mesma forma.)

Em outros projetos, vi pessoas usarem o Graphviz para dependências de módulos, gráficos de chamada, histórico de versões, todo tipo de coisa. A melhor meta-ferramenta de visualização de programas de todos os tempos.

(Talvez seja porque eu peguei compiladores , mas acho estranho que, quando um programador se depara com um problema, a resposta parece sempre ser "escrever um programa!", Exceto quando o problema envolve o código fonte de um programa. )

Passe por ele no depurador enquanto ele é executado, é quase a única maneira de entender uma nova base de código grande.

Entenda que realmente não existem atalhos para o preenchimento total. (E se você tiver problemas com essa frase, sua educação foi MUITO negligenciada. É de "Stranger In a Strange Land", de Robert A. Heinlein.)

Leia, uma página de cada vez, uma rotina de cada vez. Adicione comentários. Faça desenhos das principais estruturas de dados. Reconhecer algoritmos. Recorra a conhecimentos anteriores.

Resista à tentação de pôr em marcha o depurador. A janela de exibição do depurador é muito pequena: você vê uma linha de cada vez, mas realmente não vê onde esteve ou para onde está indo.

O que quer que você escreva o máximo que puder, para que ninguém acabe na mesma posição que você.

você precisa usar pistas. obtenha uma pista do que você deve procurar e use extensivamente a funcionalidade de pesquisa do seu ambiente ou IDE que pode levá-lo à seção desejada do código em que você precisa fazer alterações.

ler 14 mil linhas de código java não faz nenhum sentido. A funcionalidade de pesquisa é o seu salva-vidas

Pessoas diferentes têm estilos de aprendizado diferentes, então YMMV. A primeira coisa que faço nessa situação é ler toda a base de código pelo menos uma vez. Isso me dá uma idéia geral de onde está tudo. Depois, escolho uma seção para examinar com mais detalhes. As estruturas de dados seriam um bom lugar para começar. Depois de ter uma idéia geral do que está acontecendo, faço o mesmo com outra parte do código que interage com o primeiro. Após iterações suficientes, tenho uma boa noção de como o código funciona.

A melhor maneira, como em toda a programação, não apenas em grandes pedaços de código não comentado, é dividi-lo em pedaços. Isso é algo que você deve fazer na sua cabeça e também visualmente no código. Isso pode significar adicionar grandes comentários em negrito ou várias quebras de linha. Isso ajuda ao rolar para ver as peças. Tente encontrar os pedaços lógicos de código.

É claro que, ao entender os bits, comente-os pelo que sabe naquele momento, possivelmente colocando notas sobre algo que não entende.

Eu também recomendaria não tentar entender a peça inteira desde o início. Em vez disso, tente entender as peças que você precisa conhecer agora e trabalhe no resto mais tarde.

Eu começaria usando o Leo Editor no modo @shadow com o uso ativo de nós clonados . Isso permite adicionar notas e comentários para cada seção do código em estudo sem alterar o código , e as anotações sempre estarão em contexto, ao lado do código do qual está falando. Aqui está um exemplo de fluxo de trabalho dos documentos:

Por exemplo, quando eu corrigo um erro no Leo, crio um nó comum para representar o erro. Este nó do bug é minha visão de todos os dados no código-fonte do Leo relacionados ao bug. À medida que descubro o código relacionado ao bug, clono os nós e os movo para o nó do bug. Também adicionarei nós comuns como filhos do nó do bug. Esses nós contêm o relatório de bug original, descrições de como corrigi o bug, dados de teste ou quaisquer outras notas que eu queira manter.

Depois de criar o nó do bug, concentro-me apenas nesse nó e em seus filhos. Eu posso examinar o nó do bug e seus filhos sem ter que pular o contorno. Tudo que eu preciso está em um só lugar. Quando eu resolvo o problema, posso fazer isso alterando os clones. Novamente, não tenho que pular o contorno. Não importa quão grande ou complexa seja toda a estrutura de tópicos: estou lidando apenas com o nó do bug e seus filhos. Esse foco extremamente estreito facilita muito a correção de bugs.

Desenhe diagramas da fonte: os relacionamentos de dados, os funcionais, os objetos. Determine a agregação, o fluxo de dados e o código. As imagens são muito melhores que os comentários para isso e podem ser mantidas separadas do código.

Antes de refatorar qualquer coisa, escreva testes. Muitos testes. Testes muito específicos para pequenos blocos de código que são pelo menos chamados, pois dependerão de como sua bagunça herdada for gravada.

A vantagem de escrever testes para começar é que você precisa ter algum tipo de entendimento do código antes de poder testá-lo; portanto, todo teste que você escrever terá um pouco de conhecimento adquirido. Você também pode comentar fortemente os testes com suas suposições ao lado das afirmações.

Ao fazer o teste primeiro, você não corre o risco de alterar algo no código que possui efeitos indiretos que você não conhece. Você também terá uma rede de segurança ao refatorar o código.

Uso ferramentas como doxygen, para gerar um diagrama geral de classes, que adiciona minha compreensão do que cada uma das classes faz.

Então pego alguns erros fáceis na fila de erros (antes que meu gerente me atribua: P), depois corro essa funcionalidade no depurador e tento gerar um modelo aproximado de fluxo de dados ou de código.

Por exemplo, funcionalidade de exportação em alguns softwares: por isso, tento entender como os dados de origem são lidos, de onde no código (interface base) posso avaliar se os dados são lidos corretamente usando meus diagramas de fluxo de classe e código, pelos quais as classes são responsáveis que tipo de exportação, etc. Acho que metade do entendimento está concluído, depois de ter os diagramas de classes e fluxogramas.

Aborde um defeito trivial, por exemplo, uma NullPointerException. Evite qualquer coisa relacionada à concorrência no início, qualquer coisa que por sua natureza envolva a compreensão de grande parte do código de uma só vez.

Depois de corrigir alguns bugs, você provavelmente terá uma boa ideia. Funciona para mim, de qualquer forma.

Basicamente, a ação para escrever um código limpo deve começar desde o design. Se estivermos codificando na linguagem OOP, forneça uma UML, compartilhe com os colegas e fique convencido de que o design não é ambíguo. De qualquer forma, os desenvolvedores devem estar convencidos de que o design resolve o problema e não ambíguos.

Quando se trata de codificação, precisamos garantir que o design seja convertido em código, ou seja, uma entidade para uma classe ou estrutura, uma operação para funcionar etc.

E eu passei por um artigo técnico http://queue.acm.org/detail.cfm?id=2063168 que fala sobre estilo de codificação ou como podemos usar espaço, recuo, variação de fonte, como a maioria dos IDEs que podemos usar para escrever MUITO Código mais limpo, onde nós humanos podemos entender tanto quanto as máquinas. Ele enfatiza mais a criação de código livre de comentários, para que nosso código apareça como parágrafos.