Como manter um projeto fácil de entender e intuir?

5

Estou trabalhando neste projeto, que em breve conterá muitos pacotes, projetos etc. (Java). Então, desde o início eu preciso acompanhar o pacote de alto nível e a estrutura de classes, monitorar qual classe está sendo chamada onde, para que eu não complique depois de 6 meses.

Qual é o caminho certo para fazer isso? Alguma ferramenta para isso?

    
por zengr 29.06.2011 / 21:53
fonte

6 respostas

2

As duas maiores coisas, fora do topo, são convenções de nomenclatura claras e documentação externa.

Limpar as convenções de nomenclatura: As pessoas devem ser capazes de descobrir, dentro de uma margem de erro razoável, o que é uma classe, um pacote ou um método apenas lendo seu nome. Isso não significa que você precisa de nomes como methodToLoadTheXMLFileAndParseOutPhoneNumbersAndPutThemInAnArrayAndReturnIt (), mas nomes como parseNumbersFromXML () são melhores que parseNums (). O mesmo vale para classes, pacotes e projetos. Dentro do limite do nível de abstração , os nomes devem ser auto-descritivos.

Documentação externa: O código comentado é bom. O código de Bem -comentado é excelente. Mas mesmo o código extremamente bem comentado é tão útil para entender o panorama geral, e quando esse é o objetivo, a documentação externa é o caminho a ser seguido. Podem ser documentos de processadores de texto, campos em ferramentas de gerenciamento de projetos ou qualquer outro formato, mas a chave é ter descrições simples e diretas dos componentes em vários níveis de abstração.

Tenho certeza de que há mais que outras pessoas podem adicionar, mas isso deve ajudar.

    
por 29.06.2011 / 22:06
fonte
2

Você pode usar Diagramas de Classes UML para ter uma representação visual das relações entre suas classes e pacotes.

Existem muitas ferramentas para construir esses diagramas. ArgoUML é uma ferramenta de software livre que permite construir este e outros diagramas UML, ele ainda tem uma ferramenta de engenharia reversa para gerar um diagrama de seu código-fonte.

Além disso, se você gerar Javadoc para o seu código-fonte, os hiperlinks entre a documentação para diferentes classes / pacotes serão gerados automaticamente.

    
por 29.06.2011 / 22:00
fonte
2

Escreva testes unitários para tudo. Isso incentivará você a ter um design em que cada módulo seja autônomo e tenha comportamentos bem definidos. Se você se acha pensando "como diabos eu devo testar isso?", Normalmente é um sinal de design ruim. (Esta não é uma regra universal. Algumas coisas são inerentemente difíceis de escrever testes, e não há muito que você possa fazer sobre isso.)

    
por 29.06.2011 / 22:17
fonte
0

Comece com um design !!!

Ferramentas CASE, como o Enterprise Architect (é o que usamos no trabalho e está OK) etc., permitem que você projete suas classes em UML, projete seus casos de uso, interações de classe como diagramas de seqüência. Dessa forma, você pode ver as etapas que o programa deve seguir para cada caso de uso.

Usar uma ferramenta CASE como essa permite até mesmo gerar automaticamente seu código a partir do design e, em seguida, reverter o código resultante + altera novamente para o design.

Em suma, o design e a documentação de um projeto devem vir em primeiro lugar. E se você fez um bom design, seu código deve ser fácil de seguir.

    
por 29.06.2011 / 22:05
fonte
0

Existe um truque para "fácil de entender e intuitivo".

É chamado de princípio KISS.

Mantenha-o simples e estúpido.

"Eu não faço mais complicado depois de 6 meses." é uma coisa muito importante para dizer.

Você pode tornar isso complicado. Ou você pode simplificar.

Você pode mantê-lo simples mantendo-o simples.

Antes de adicionar cada recurso ("cargas de pacotes, projetos, etc. (Java)"), pergunte-se se você está simplificando ou tornando mais complexo.

Se você está tornando mais complexo, então PARE. Pare de adicionar coisas.

Defina a complexidade que você está vendo. Corrigir a complexidade. Agora, antes de adicionar mais uma linha de código.

Depois de definir a complexidade indesejável e corrigi-la, as coisas são simples novamente.

Esta é uma batalha contínua. Nenhuma quantidade de planejamento impedirá a complexidade de se infiltrar eventualmente.

Cada recurso deve passar o "isso está aumentando a complexidade?" teste.

    
por 29.06.2011 / 23:22
fonte
0

Eu sugiro manter um bom nível de desgin dos domínios e pacotes e sua conexão uns com os outros.

Quanto a documentação e ferramentas de classe específicas, não acho que esses sejam necessariamente um requisito importante, especialmente se você estiver fazendo isso em uma pequena equipe ou sozinho. O aspecto mais importante é escrever um código bom, limpo e abstrato. Se você gastar metade do seu tempo se preocupando com a documentação externa, gastará metade do seu tempo sem pensar no código.

Ao dizer isso, acho que reavaliar conceitos de design de alto nível pode ajudá-lo a manter a cabeça na escrita do código. Por alto nível eu apenas quero dizer não escrever todas as classes, ou todos os métodos. Eu consideraria, em vez disso, como grupos de classes ou componentes interagem, quais camadas conceituais você possui e as interfaces entre essas camadas / componentes.

Então, em resumo, para acompanhar o código e ajudar a manter a abstração, eu seguiria estas etapas:

1) Revisão contínua e design de conceitos de alto nível usando uma abordagem UML ou mesmo apenas caixas e linhas.

2) Usando o TDD em cada pacote para ajudar cada pacote a manter um código de acoplamento flexível e extensível.

3) Alguma documentação de código necessária, mas não muito excessivamente fixada nisto, pois é mais importante tentar obter seu código auto-explicativo.

4) Refatoração constante do seu código se você notar "durante a escrita" que existe uma alta dependência de outros modificadores. Tente não deixar o código em um estado TODO se puder ajudá-lo apenas porque está sob pressão para fazê-lo. Isso muitas vezes pode levar ao início do código confuso.

    
por 29.06.2011 / 23:28
fonte