Entendendo o código de outras pessoas

Question

Ocasionalmente, tenho a infelicidade de ter que fazer alterações em arquivos muito antigos, mal não documentado e mal não código projetado.

Muitas vezes leva muito tempo para fazer uma mudança simples porque não há muita estrutura no código existente e eu realmente preciso ler muito código antes de ter uma ideia de onde as coisas estariam.

O que eu acho que ajudaria muito em casos como esse é uma ferramenta que permitiria visualizar uma visão geral do código e talvez até detalhar mais.Suspeito que tal ferramenta seria muito difícil de acertar, visto que se trata de tentar encontrar estrutura onde há pouca ou nenhuma.

Acho que isso não é realmente uma pergunta, mas sim uma reflexão.Eu deveria transformar isso em uma pergunta - O que os outros fazem para ajudar a compreender o código de outras pessoas, o bom e o mau?

Answer 1

Eu recomendo fortemente BOUML.É uma ferramenta gratuita de modelagem UML que:

• é extremamente rápido (a ferramenta UML mais rápida já criada, confira benchmarks),
• tem suporte sólido à importação de C++,
• tem excelente suporte à exportação de SVG, o que é importante, porque a visualização de gráficos grandes em formato vetorial, que pode ser escalonado rapidamente, por exemplo,Firefox, é muito conveniente (você pode alternar rapidamente entre a visualização "olho de pássaro" e a visualização de detalhes da classe),
• é completo, intensamente desenvolvido (veja história de desenvolvimento, é difícil acreditar que um progresso tão rápido seja possível).

Então:importe seu código para BOUML e visualize-o lá, ou exporte para SVG e visualize-o no Firefox.

Answer 2

Hmm, essa é difícil, tanta coisa para dizer em tão pouco tempo...

1) Se você puder executar o código, isso tornará a vida muito mais fácil, pontos de interrupção (especialmente condicionais) são seus amigos.

2) A abordagem dos puristas seria escrever alguns testes de unidade, para funcionalidades conhecidas, depois refatorar para melhorar o código e a compreensão e, em seguida, testar novamente.Se algo falhar, crie mais testes de unidade - repita até ficar entediado/antigo/movido para um novo projeto

3) O ReSharper é bom em mostrar onde as coisas estão sendo usadas, o que está chamando um método, por exemplo, é estático, mas um bom começo, e ajuda na refatoração.

4) Muitos eventos .net são codificados como públicos, e os eventos podem ser difíceis de depurar na melhor das hipóteses.Recodifique-os para serem privados e use uma propriedade com adicionar/remover.Você pode então usar o ponto de interrupção para ver o que está ouvindo em um evento.

A propósito - estou jogando no espaço .Net e adoraria uma ferramenta para ajudar a fazer esse tipo de coisa, como Joel, alguém aí conhece uma boa ferramenta de revisão dinâmica de código?

Answer 3

Fui solicitado a me apropriar de alguns códigos NASTY no passado - tanto para trabalho quanto para "diversão".

A maioria dos amadores para quem assumi o código simplesmente desenvolveu o código para fazer o que precisavam ao longo de várias iterações.Sempre foi uma bagunça gigante e incestuosa da biblioteca A ligando para B, ligando de volta para A, ligando para C, ligando para B, etc.Muitas vezes eles usavam threads e nenhuma seção crítica era vista.

Descobri que a melhor/única maneira de controlar o código era iniciar no ponto de entrada do sistema operacional [main ()] e construir meu próprio diagrama de pilha de chamadas mostrando a árvore de chamadas.Você realmente não precisa construir uma árvore completa no início.Basta percorrer as seções nas quais você está trabalhando em cada estágio e você terá um controle suficiente sobre as coisas para poder executá-las.

Para completar, use o maior pedaço de árvore morta que encontrar e uma caneta.Dispor tudo à sua frente para que você não precise pular para frente e para trás nas telas ou páginas torna a vida muito mais simples.

EDITAR:Fala-se muito sobre padrões de codificação...eles apenas farão com que o código ruim pareça consistente com o código bom (e geralmente será mais difícil de detectar).Os padrões de codificação nem sempre facilitam a manutenção do código.

Answer 4

Eu faço isso regularmente.E desenvolvemos algumas ferramentas e truques.

• Tente obter uma visão geral (diagrama de objetos ou outro).
• Documente suas descobertas.
• Teste suas suposições (especialmente para código vago).

O problema disso é que na maioria das empresas você é apreciado pelo resultado.É por isso que alguns programadores escrevem códigos ruins rapidamente e passam para um projeto diferente.Então você fica com o lixo, e seu chefe compara seu progresso lento com o do cara rápido e sujo.(Felizmente meu empregador atual é diferente).

Answer 5

Geralmente uso diagramas de sequência UML de várias formas principais de uso do componente.Não conheço nenhuma ferramenta que possa gerá-los automaticamente, mas muitas ferramentas UML, como BoUML e EA Sparx, podem criar classes/operações a partir do código-fonte, o que economiza alguma digitação.

Answer 6

O texto definitivo sobre esta situação é Working Effectively with Legacy Code, de Michael Feathers.Como S.Lott diz para fazer alguns testes de unidade para estabelecer o comportamento do código lento.Depois de inseri-los, você pode começar a refatorar.Parece haver um capítulo de amostra disponível no site do Object Mentor.

Answer 7

Ver Teste de unidade de aplicativos legados de formulários da Web ASP.NET para obter conselhos sobre como controlar aplicativos legados por meio de testes de unidade.

Existem muitas perguntas e respostas semelhantes.Aqui está a pesquisa https://stackoverflow.com/search?q=unit+test+legacy

A questão é que entender o legado provavelmente será mais fácil se você estiver escrevendo testes de unidade para esse legado.

Answer 8

Não tive muita sorte com ferramentas para automatizar a revisão de código mal documentado/executado, porque um programa confuso/mal projetado geralmente se traduz em um modelo pouco útil.Não é empolgante nem imediatamente gratificante, mas obtive os melhores resultados escolhendo um local e acompanhando a execução do programa linha por linha, documentando e adicionando comentários à medida que avançava e refatorando quando aplicável.

Answer 9

um bom IDE (EMACS ou Eclipse) poderia ajudar em muitos casos.Também em uma plataforma UNIX, existem algumas ferramentas para referência cruzada (etags, ctags) ou verificação (lint) ou gcc com muitas opções de aviso ativadas.

Primeiro, antes de tentar compreender uma função/método, eu o refatoraria um pouco para se adequar às suas convenções de codificação (espaços, colchetes, recuo) e removeria a maioria dos comentários se eles parecessem errados.

Então eu refatoraria e comentaria as partes que você entendeu, e tentaria encontrar/grepar essas partes em toda a árvore de origem e refatorá-las lá também.

Com o tempo, você obtém um código melhor com o qual gosta de trabalhar.

Answer 10

Eu pessoalmente faço muitos desenhos de diagramas e descubro os ossos da estrutura.

A moda do dia (e possivelmente com razão) me fez escrever testes unitários para testar minhas afirmações e construir uma rede de segurança para mudanças que faço no sistema.

Quando chegar a um ponto em que me sinta confortável o suficiente para saber o que o sistema faz, tentarei consertar bugs da maneira mais sensata possível e espero que minhas redes de segurança estejam quase concluídas.

No entanto, sou só eu.;)

Answer 11

Na verdade, tenho usado os recursos de refatoração do ReSharper para me ajudar a controlar vários projetos que herdei recentemente.Então, para descobrir o código não documentado e muito mal estruturado de outro programador, eu começo refatorando-o.

Limpar o código, renomear métodos, classes e namespaces adequadamente, extrair métodos são todas mudanças estruturais que podem esclarecer o que um trecho de código deve fazer.Pode parecer contra-intuitivo refatorar código que você não "conhece", mas acredite, o ReSharper realmente permite que você faça isso.Tomemos, por exemplo, a questão do código morto do arenque vermelho.Você vê um método em uma classe ou talvez uma variável com nome estranho.Você pode começar tentando pesquisar usos ou, claro, fazer uma pesquisa de texto, mas o ReSharper detectará o código morto e o colorirá de cinza.Assim que você abre um arquivo, você vê em cinza e com sinalizadores de barra de rolagem o que no passado teria sido uma pista falsa confusa.

Existem dezenas de outros truques e provavelmente uma série de outras ferramentas que podem fazer coisas semelhantes, mas sou um viciado em ReSharper.

Saúde.

Answer 12

Conheça o software intimamente do ponto de vista do usuário.Muito pode ser aprendido sobre a estrutura subjacente estudando e interagindo com a(s) interface(s) do usuário.

Answer 13

• Impressões
• Quadros brancos
• Muito papel de carta
• Muitos Starbucks

Ser capaz de rabiscar o coitado é o método mais útil para mim.Normalmente eu apareço com muitos "huh, isso é engraçado..." enquanto tento fazer diagramas básicos de estrutura de código que acabam sendo mais úteis do que os próprios diagramas no final.Ferramentas automatizadas são provavelmente mais úteis do que imagino, mas o valor de encontrar essas partes engraçadas excede o valor de diagramas gerados rapidamente para mim.

Para diagramas, procuro principalmente para onde os dados estão indo.Por onde entra, onde vai parar e o que passa no caminho.Geralmente, o que acontece com os dados parece dar uma boa impressão do layout geral e alguns detalhes aos quais voltar se eu estiver reescrevendo.

Answer 14

Quando estou trabalhando em código legado, não tento entender todo o sistema.Isso resultaria em sobrecarga de complexidade e subsequente explosão cerebral.

Em vez disso, pego uma única característica do sistema e tento entender completamente como ele funciona, de ponta a ponta.Geralmente depuro no código, começando no ponto no código da UI onde posso encontrar a funcionalidade específica (já que geralmente é a única coisa que poderei encontrar no início).Em seguida, executarei alguma ação na GUI e detalharei o código até o banco de dados e depois farei o backup.Isso geralmente resulta em uma compreensão completa de pelo menos um recurso do sistema e, às vezes, também fornece insights sobre outras partes do sistema.

Depois de entender quais funções estão sendo chamadas e quais procedimentos armazenados, tabelas e visualizações estão envolvidos, faço uma pesquisa no código para descobrir quais outras partes do aplicativo dependem dessas mesmas funções/procs.É assim que descubro se uma mudança que vou fazer irá quebrar alguma coisa no sistema.

Às vezes também pode ser útil tentar fazer diagramas do banco de dados e/ou da estrutura do código, mas às vezes é tão ruim ou tão complexo que é melhor ignorar o sistema como um todo e focar apenas na parte que você precisa. mudar.

Answer 15

Meu grande problema é que eu (atualmente) tenho sistemas muito grandes para entender em um espaço de tempo bastante curto (tenho pena dos desenvolvedores contratados neste ponto) e não tenho muita experiência fazendo isso (já tive a sorte de ser aquele que projeta do zero.)

Um método que utilizo é tentar entender o significado da nomenclatura de variáveis, métodos, classes, etc.Isto é útil porque (espero que cada vez mais) incorpora uma visão de alto nível de uma linha de pensamento a partir de um nível atômico.

Digo isso porque normalmente os desenvolvedores nomearão seus elementos (com o que eles acreditam ser) de forma significativa e fornecendo informações sobre a função pretendida.É certo que isso é falho, se o desenvolvedor tiver uma compreensão deficiente de seu programa, da terminologia ou (geralmente o caso, imho) estiver tentando parecer inteligente.Quantos desenvolvedores viram palavras-chave ou nomes de classes e só então procuraram o termo no dicionário, pela primeira vez?

Answer 16

É tudo uma questão de padrões e regras de codificação que sua empresa usa.

se todos codificam em estilos diferentes, então é difícil manter o código de outro programador e etc, se você decidir qual padrão usará, terá algumas regras, tudo ficará bem :) Nota:que você não precisa criar muitas regras, porque as pessoas devem ter a possibilidade de codificar no estilo que quiserem, caso contrário você pode ficar muito surpreso.