Entender um sistema de software

Question

Recentemente, tornou-se parte de uma equipe de projeto incorporado complexo para o qual eu será o desenvolvimento de uma parte. Para a parte que é minha responsabilidade só existe código antigo e não muito documentação.

Estou muito interessado em fazer um bom começo, mas a timidez e medo de aparecer marcas estúpidas difícil de fazer perguntas. Como fazer perguntas?

Eu queria perguntar o que as técnicas que vocês usam para entender um projeto? Quero dizer que há de lotes de detalhes técnicos que se deve lembrar e manter em seu contexto, a fim de fazer um projeto. Seu ler o código e obter alguns fatos, mas como seguir em frente? Por exemplo, você ler o código e o documento (s) e obter alguns fatos A e B fato. Como chegar adequada conclusão X para o qual você pode ou não ter necessidade de levar em conta fatos C e D também?

Answer 1

A leitura do código é equilibrado por escrever a documentação.

Escrever a documentação que o seu substituto vai precisar. Imagine alguém que sabe menos do que você. Explicá-lo para essa pessoa.

Quando você não consegue explicar algo ao seu substituto, fazer perguntas.

Quando você tem uma descrição completa, você vai "saber" o sistema.

E você terá produzido a documentação completa.

Answer 2

Code-leitura pode ser particularmente difícil se não houver documentação suficiente e o código é mal documentado e mal escrito. Eu acho que a melhor maneira agora é encontrar o ponto de entrada do código, e compreender lentamente seus fluxos e os dados que ele usa. Gostaria de manter um olhar para fora para

1. Estrutura - há qualquer particionamento de entidades / sistema? Onde no código (e como) eles se comunicam uns com os outros?

2. Dados - que tipo de estruturas são utilizados para armazenar os dados globais? Como são os dados acessados ??e salvos?

3. Se você está fazendo C ou C ++, também é importante para descobrir como a memória é manuseado e para C ++ (e outros idiomas não relacionados de gestão OOP memória, eu acho), como são propriedade do objeto contido.

4. Uma vez que é um projeto integrado, existem construções de código não-padrão ou codificantes utilizados?

Answer 3

Você não mencionar que tipo de existirem testes. Se houver casos de teste, modificá-los e traçar como isso afetaria o resultado final.

Answer 4

Você pode querer olhar para diagramas que dão toda a imagem da estrutura lógica do sistema, como, por exemplo, olhando para os diagramas de classe em um sistema OOP seria de grande ajuda. Olhando para os diagramas de design de aplicativos grandes e complexos lhe dá uma compreensão clara de como são organizados os módulos internos do sistema e desta forma a sua torna a tarefa de descobrir o que a funcionalidade faz uma determinada peça de código faz muito mais fácil. Na ausência de diagramas, você está melhor aposta seria começar a partir do ponto de entrada do aplicativo, como main () e proceder a partir daí enquanto desenha (literalmente desenhar ou escrever no papel) suas próprias conclusões sobre o sistema ( desta forma, você pode ter sua própria documentação) e pedir a seus colegas se eles estão corretos.

Answer 5

A minha experiência é que é melhor começar com algum tipo de tarefa - uma correção de bug ou qualquer outra alteração pequena. Que irá fornecer o foco para o seu aprendizado. Acho que é difícil de ler através de um ligante ou filtrarem as páginas de código-fonte ou documentação sem ter uma maneira de aplicá-lo.

Se você tem uma caixa de areia onde você pode jogar com as mudanças que você fez sem bagunçar a base de código, que pode ser ainda mais útil.