5.3. Práticas de projeto
Itere, divida para conquistar, faça protótipos e pare quando os detalhes forem óbvios.
Resumo
- Itere: a primeira solução raramente é a melhor. Tente várias, em alto e baixo nível.
- Dividir e conquistar: quebre o problema em partes; refine cada parte separadamente.
- Top-down (do geral ao detalhe) e bottom-up (das peças ao todo) não competem: use os dois.
- Protótipo experimental: código mínimo e descartável para responder uma pergunta de projeto específica.
- Quanto projetar? Até os detalhes de implementação ficarem óbvios. Registre: wiki, diagrama, foto, comentário.
Perguntas-chave
responda de cabeça, depois abraQual a regra para um protótipo experimental?
Ter uma pergunta clara, escrever o mínimo de código para respondê-la e jogar o código fora depois.
Quando parar de projetar antes de codar?
Quando a equipe sente que os detalhes restantes são óbvios; quanto mais experiência e menos risco, menos projeto formal.
Como documentar projeto de forma leve?
Comentários no código, wiki, e-mails resumidos, fotos do quadro branco, cartões CRC, diagramas UML quando úteis.
Exercícios de fixação
0/5 respondidas1.
A equipe quer saber se um banco de dados aguenta 10 mil gravações por segundo. Pelo capítulo, o melhor é:
2.
Qual o maior risco de um protótipo experimental?
3.
Sobre top-down e bottom-up, o livro conclui que:
4.
Um time experiente fará uma tela CRUD que já fez dezenas de vezes. Quanto projeto formal antes de codar?
5.
Por que o livro recomenda iterar no projeto?