Digamos que recebi as especificações de um projeto de um cliente e agora é hora de começar a desenvolvê-lo. Normalmente, eu apenas começo com o primeiro módulo (geralmente registro de usuário) e depois passo de um módulo para o outro. Eu só planejo na minha cabeça antes de começar um módulo como vai funcionar, mas não há planejamento antes disso.
No entanto, acho que seria melhor se eu examinasse as especificações e planejasse como o sistema funcionaria antes de codificá-lo, por exemplo, quais são os principais componentes, como eles vão interagir etc. Estou apenas não sei exatamente o que devo planejar.
Para ter uma idéia melhor do que estou pedindo, como devo-
a) Divida o projeto em componentes,
b) Planeje suas interações, por exemplo, devo fazer diagramas de classe, escrever testes de unidade etc.?
Alguma ideia?
fonte
Respostas:
Quando você tem o privilégio de iniciar um novo projeto, tem uma tela em branco - que é emocionante e assustadora ao mesmo tempo. Eu trabalho em iterações, e é assim que eu divido o trabalho:
Essencialmente, essa abordagem de definir progressivamente um projeto de nível muito alto a um design mais detalhado me serviu bem. Até as interações entre subsistemas são refinadas à medida que você tenta implementá-las. É uma coisa boa.
fonte
Certo. Boa ideia.
Boa. Faça mais disso.
Excelente.
Corrigir.
Como você pode não ter certeza quando já listou várias coisas? Se essas são as coisas que lhe interessam, por que não se concentrar apenas nessas coisas?
Leia o modelo de exibição 4 + 1: http://en.wikipedia.org/wiki/4%2B1_Architectural_View_Model
Leia sobre a estrutura do Zachman: http://en.wikipedia.org/wiki/Zachman_Framework
É isso que você precisa planejar.
Use padrões de design amplamente adotados para outros projetos semelhantes.
Em caso de dúvida, leia os projetos J2EE para obter idéias.
http://www.oracle.com/technetwork/java/javaee/blueprints/index.html
Sim. Boas ideias, tudo.
fonte
O mais importante a fazer: revisar as especificações, interagir com o cliente para obter especificações mais refinadas.
Os requisitos são indubitavelmente incompletos, vagos ou incorretos. O maior desperdício de tempo é fazer a coisa errada. Os clientes não são engenheiros de software profissionais e não se pode esperar que sejam bons no desenvolvimento de um bom conjunto de requisitos.
Portanto, você deve revisar as especificações, entrevistar o cliente e descobrir se é isso que ele / ela realmente precisa e deseja, pode pagar, etc.
Desenvolva casos de teste / uso e revise com o cliente. Se um requisito não for testável, jogue-o fora.
Desenvolva o design e verifique se todas as peças funcionam corretamente e que, em teoria, faria o que você precisa.
Desenvolva um protótipo de arquitetura que teste toda a tecnologia a ser usada em todas as camadas, mas ignore a funcionalidade. Você está testando a arquitetura, não a especificação funcional. Ter a arquitetura errada significa que você precisa reescrever tudo, portanto é importante obter a arquitetura correta. Certifique-se de que ele atenda aos seus requisitos de velocidade, eficiência, segurança etc.
fonte
Você definitivamente deseja ter algum design em prática antes de começar a codificar.
Depois disso, geralmente prefiro fazer uma fase inicial da arquitetura primeiro para definir como as camadas do aplicativo se encaixam. Isso incluiria coisas de backbone, como segurança e log.
Então eu construo um recurso de cima para baixo para que você implemente algo completamente.
Então vá de lá.
fonte
Tudo
Planeje tudo, é mais fácil trocá-lo no papel do que uma vez que parte dele já está codificado, você obtém uma excelente base de documentação e muitos outros benefícios.
fonte