Se você acabou de ser apresentado a um novo projeto, qual é a primeira coisa que você procura para ter uma idéia de como ele funciona?
Você procura o design primeiro? Se houver um design, o que você procura nele? Diagramas de classe ou diagramas de implantação ou diagramas de sequência ou algo mais?
Ou você vai direto ao código? Se sim, como você entende como as diferentes camadas interagem?
Respostas:
Eu começo com o código. Documentos de projeto separados, se houver algum, têm a probabilidade de estar errados ou mal concebidos como não. Então, eu começo tentando rastrear algum fluxo simples através do código; se for um aplicativo da web, pode ser um pedido ou uma sequência de pedidos, por exemplo. Depois de fazer isso, tenho uma espécie de esqueleto para me apoiar mais. Então, eu posso voltar e ler projetos ou outra documentação, mas nesse momento, tenho algo concreto para relacioná-los e validá-los, para que eu possa detectar informações duff. Ou eu poderia continuar lendo código, casos de teste etc.
Eu começaria em um nível superior. Se houver alguma documentação voltada para o usuário - manual ou guia do usuário. Caso contrário, consulte as especificações de requisitos para ter uma idéia do que o software deve fazer. Gostaria de olhar para o design e tentar mapeá-lo nos arquivos de código. Espero que estes sejam estruturados em pastas de alguma maneira sensata. Eu selecionava parte do design e entrava nos arquivos para seguir o fluxo do código sem ficar muito atolado nos detalhes.
Começo configurando um sistema de desenvolvedores. Eu uso o procedimento documentado. Isso permite que o gato saia do saco sobre o quanto a documentação está sincronizada com a realidade.
Também me diz quais são as dependências. Isso importa.
Agora que tenho uma configuração de desenvolvedores, (e marco o documento de instalação com as correções à medida que for desenvolvendo), construo uma versão. Acabo fazendo perguntas durante toda essa fase.
Agora que foi construído, faço o exercício introdutório do manual do usuário. Isso me diz aproximadamente o que o sistema realmente faz.
Agora eu tenho uma pista parcial sobre o sistema, leio os documentos de projeto, que agora acredito na proporção de quão errados os documentos foram até agora.
Quando chego à documentação comportamental real, posso começar a examinar o código e ver o que realmente está lá. Eles nunca se alinham, mas agora eu sei o quanto acreditar.
Então eu olho para a saída do IDE para comentários "todo" e "fixme". Coisas como "consertar na versão 2.0" também são uma dica.
Portanto, trata-se de aprender a veracidade e, como as pessoas apontam, documentos de design separados raramente são atualizados ou corretos, mas informa o que as pessoas estavam pensando em um determinado momento. E, claro, essas pessoas provavelmente não estão por perto para interrogar.
Minha preferência é começar com o design para obter uma visão geral do projeto e tentar entender algumas de suas principais características e / ou estrutura antes de detalhar os detalhes.
Sempre o design. Com o código, vale a pena seguir as etapas de configuração do desenvolvedor (verificar a fonte, criar o projeto, fazer as alterações necessárias na configuração), mas não faz sentido tentar aprender a estrutura de um aplicativo a partir do código. Isso mostra apenas o que é a estrutura, não o porquê da estrutura ou o que os outros desenvolvedores acham que os destaques e os pontos negativos da arquitetura. Você aprende com os diagramas do quadro branco e conversa com os desenvolvedores.
Para um software complexo, eu o abordaria mais ou menos como se fosse um novo projeto de desenvolvimento. Comece com as grandes idéias - visão, contexto, escopo, partes interessadas. Leia a documentação do usuário e tenha uma idéia de como ela é usada. Obtenha algum treinamento para o usuário com o software, se possível (ou aplicável). Em seguida, comece a examinar os requisitos e a documentação do projeto para ter uma idéia de como funciona em alto nível. Converse com os designers se eles ainda estiverem por perto. Veja a arquitetura do sistema em diferentes perspectivas. A partir daí, comece a explorar a funcionalidade principal e a analisar alguns códigos, retornando aos requisitos e ao design, conforme necessário. Ao olhar para o código, execute o software para vê-lo em ação. Durante todo o tempo, compile alguma documentação resumida para referência futura - você possui o Cliffs Notes. Ramifique até ter uma boa idéia de como tudo funciona e se encaixa, mas concentre-se nas partes com as quais você trabalhará. Até agora você tem uma compreensão completa de todo o sistema, ou pelo menos das partes aplicáveis a você.
Obviamente, no mundo real, talvez você não tenha tempo para passar por tudo isso antes de começar a sujar as mãos, especialmente em projetos maiores. Mas é assim que eu faria se dependesse de mim.
Você deve trabalhar entre o código em si e qualquer documento de design.
Você pode começar com código ou design, e isso realmente não importa. Leia o código até estar bem e verdadeiramente confuso e confira os documentos de design. Ou, leia os documentos de design para obter uma imagem de alto nível e, em seguida, observe o código para ver como ele é. Repita quase indefinidamente, desde que você esteja trabalhando com o código.
Esteja ciente de que os documentos de design estão quase sempre desatualizados e incorretos de várias maneiras. No entanto, desde que você mantenha esses pontos em mente, os documentos desatualizados ainda o ajudarão a entender a mente do autor em algum momento do passado. Muitos dos problemas e preocupações de alto nível ainda serão válidos, e você provavelmente será capaz de entender mais rapidamente como o código chegou aonde está, se você ainda tiver uma imagem datada de onde o autor originalmente pensou que estava indo. ir.
À medida que você trabalha com o código e o design, crie seus próprios documentos que descrevem sua compreensão do código hoje. Talvez esses documentos sejam um esboço simples ou dois, talvez sejam artigos escritos em um wiki, talvez sejam outra coisa. Não os torne muito complicados: não há documentos com palavras para 30 páginas. Apenas anote suas idéias, o que esclarecerá bastante seu próprio pensamento.
Depende do tipo de aplicação. Se for um aplicativo centrado em dados, geralmente começo com o design do banco de dados. Se tiver uma interface do usuário, você pode executar (ou ter bons designs de tela) e também dar uma boa idéia do que o aplicativo faz muito rapidamente (estou falando apenas de algumas horas aqui). Depois disso, começo a pesquisar no código e fará mais sentido, porque eu sei o que o aplicativo está fazendo.
Começo com a documentação do projeto. Em particular, a especificação - que informa a intenção da coisa que está sendo analisada.
Se possível, analiso as notas e a documentação do projeto para obter uma amostra geral de como isso foi feito, do processo de pensamento, do estilo e da natureza das pessoas envolvidas.
Se possível, converso com as pessoas que trabalharam nele - o que faz? Quão? Por quê? Onde estão enterrados os corpos?
Há uma tendência entre os desenvolvedores de entrar no código: "Deixe-me mostrar esse código". Isso é bom para eles, mas tende a seqüestrar minhas necessidades - que é entender o alto nível que dá contexto às coisas de baixo nível.
Ele usa grandes quantidades de poder do cérebro para analisar pequenos pedaços de código, fora do contexto completo e entender qualquer coisa significativa. Portanto, se possível, fazer com que os desenvolvedores falem sobre o PRINCÍPIO, a estrutura, as unidades, os módulos, o que quer que tudo leve à apreciação da tarefa.
Só então vale a pena tentar entrar no código.
No grande esquema das coisas, olhar para o código é como olhar para uma página cheia de zeros e zeros. Há significado, mas leva muito tempo para descobrir. Obter uma amostra de onde procurar e quais partes são significativas ajuda a restringir o espaço de pesquisa.
Tudo o que disse - quando não há doco, não há pessoas e apenas código -, não há nada a não ser olhar para o código.
Nesse caso, eu normalmente não tento entender por uma leitura lenta e profunda, faço um passe rápido, leio rapidamente tudo. Às vezes, isso é apenas abrir arquivos e pressionar a tecla de página para baixo. Você pode obter uma incrível apreciação de uma imagem grande apenas fazendo isso. (E, em alguns casos, eu até despejo de arquivos executáveis e os vasculho, procurando assinaturas e padrões. Isso tem sido incrivelmente proveitoso nos últimos 20 anos.)
Eu começo com os testes. Se os testes de unidade e de integração forem bem escritos, eles descreverão os casos de uso. Se eles não estão bem escritos ou não foram escritos (infelizmente, esse é o caso), começo com os pontos de entrada no código e os igualo ao design.
Em seguida, escreverei testes para cada caso de uso, descoberto pela árvore que você encontrará após investigar os pontos de entrada, para investigar o código e usar os utilitários de cobertura de código para ver o que está faltando. Esses testes me dizem exatamente como o código funciona.
Eu sempre tento agregar valor a algo que olho; escrevendo testes, limpando código, refatorando funções grandes (mais de 20 linhas).
Acho que a criação de documentação sozinha não adiciona nenhum valor real ao código, pois nunca interage com o código.
bem, o que é "o design"? um README? um diagrama uml? você pode criar um documento de design na metade (e a maioria faz), não pode codificar na metade
qualquer projeto simplesmente será uma opinião , enquanto o código é o fato
só me refiro a documentos secundários quando não consigo entender o raciocínio do código
ler código é uma habilidade essencial para um desenvolvedor. é melhor que você aprenda agora, de qualquer maneira, não poderá ver muita documentação útil durante sua carreira
Depois, olho para o README, TODO e Changelog do desenvolvedor. Se não entendo por que o software foi escrito, como foi escrito e para onde está indo ... eu não o uso.
Crie primeiro, depois codifique, de cima para baixo, se desejar, para entender o contexto em todos os níveis em que tenho que trabalhar.
Mas se eu tiver que fazer uma alteração muito específica, como consertar um relatório ou um cálculo, basta ir e olhar o código.
Mais especificamente, minha abordagem "primeiro design" é esta:
Começo com o modelo de domínio, se houver um, se não houver, eu construo pelo menos um modelo básico (um bom ponto de partida é o modelo de dados). Ele define o "glosário" do aplicativo e a relação entre os objetos (classes).
Retrata "quais objetos são manipulados" pela aplicação.
Em seguida, procuro o modelo de caso de uso para descobrir "quais processos são executados" pelo aplicativo, embora eu prefira um mapa de processos, se este for um, que mostre seqüências de processos.
Depois disso, devo ter uma boa imagem do aplicativo e poder continuar desenvolvendo a alteração.
A propósito, a resposta acima está no contexto de aplicativos de negócios.
O código não mente. Certamente é uma boa idéia obter uma visão geral do projeto primeiro para entender o que ele faz. No entanto, se sua tarefa é obter um entendimento detalhado de como o projeto funciona, olhar o código, pelo menos para mim, é como olhar um quebra-cabeça peça por peça, exceto que a cada aula que você olha, você está adicionando outra peça do quebra-cabeça. Se o código estiver bem estruturado, você poderá ver um padrão se formando a partir dos nomes das classes sem nem mesmo investigar o que a classe faz. Em muitos casos, você pode obter dicas e sugestões do código que o ajudarão ainda mais.
Finalmente, você obtém a idéia irrequivocável do que o programa faz, um quebra-cabeça completo. A documentação pode estar incompleta ou imprecisa, mas o código nunca mente. Tudo isso você pode fazer sem descobrir o que cada método individual faz. Nem todo mundo pode aprender sobre um projeto dessa maneira, mas se você o faz com frequência, fica mais fácil para você, sem mencionar que você pode entender o essencial de um aplicativo de tamanho médio em algumas horas de estudo. Embora eu suponha que tudo se resume a preferência.
Depois de ver o código do módulo / ponto de aplicação mais crítico: vendo o código, posso verificar a qualidade do design.
Exemplo:
Você precisa trabalhar no gerenciamento de aplicativos de um aplicativo da web sobre relatórios financeiros.
Depois de ler o código sobre a mensagem, o aplicativo inicial e final (para provável bloqueio no banco de dados), o processo principal de criação de dados, o que deve ser relatado etc. etc (por exemplo, no armazenamento de gás, o processo principal é sobre o cálculo do estoque de gás na área de armazenamento dos clientes com suprimento e injeção; o processo secundário é o faturamento desses dados previamente calculados)
Nem código nem design. Gosto de conversar com as partes interessadas e os usuários finais e descobrir como isso funciona da perspectiva deles. Depois que posso criar uma imagem em minha mente, dou uma olhada rápida no design técnico e depois no código.
Eu irei com o design primeiro e depois o código simultaneamente. É muito importante porque todos os projetos são diferentes. Você precisa elaborar um plano e um alto nível de fluxo de trabalho do processo de A a Z antes de começar a trabalhar nos códigos simultaneamente. Todas as decisões tomadas devem ser documentadas para que outras equipes (ou você) que estejam / desenvolvendo os códigos conheçam a atualização mais recente e o que foi confirmado.
Se houver um bom documento de design de alto nível, eu o utilizarei. Tem que ser conciso e atualizado. Se estiver muito detalhado ou desatualizado, seguirei para o código.
Claro, isso depende do projeto, não é? Um projeto extremamente complexo ou multifacetado talvez seja melhor abordado por meio da documentação (se a documentação for sólida o suficiente).
Um único módulo simples ou aplicativo simples é, na minha opinião, quase sempre melhor abordado no nível do código.
Não há resposta certa para todas as situações!