🚀 Capítulo 20: Projeto Final Parte 2: Execução (Tema: Game of Thrones)
NOTE
Este é o capítulo final do curso de Engenharia de Software! Parabéns por chegar até aqui. Agora vamos ver como o plano se comporta no meio do caos da batalha!
1. 🎯 Objetivo da Aula
Consolidar os conceitos aprendidos ao longo do curso (Refatoração, Testes, CI/CD, DevOps) simulando a Execução de um projeto e aprendendo a lidar com imprevistos e mudanças.
2. 🏢 O Cenário Prático (Seu Desafio)
No capítulo anterior, você fez o planejamento estratégico para o Sistema de Gestão de Castelos. Agora, a guerra começou de verdade! Os exércitos estão marchando e você precisa gerenciar o projeto no meio do caos.
Como em Game of Thrones, imprevistos acontecem a todo momento:
- Um aliado trai você (o melhor programador da equipe pede demissão).
- O inimigo usa uma arma nova (o cliente muda de ideia e exige uma nova função para amanhã).
- O inverno chega mais rápido do que o esperado (o diretor da empresa encurtou o prazo de entrega pela metade).
O bom engenheiro de software não é aquele cujo plano funciona perfeitamente (isso nunca acontece), mas aquele que sabe se adaptar às mudanças sem deixar o sistema cair! Seu desafio final é sobreviver à guerra!
🧠 Fundamentos: A Teoria Traduzida
Vamos ver como as ferramentas que aprendemos nos ajudam a vencer a guerra:
🛡️ 1. O que fazer quando o programador sai? (Capítulo 16 - Documentação)
Se a equipe usou o conceito de Docs as Code e manteve o README.md e os arquivos de código bem documentados, o novo programador que for contratado conseguirá ler o “Diário do Graal” e assumir o posto de batalha rapidamente!
🧪 2. O que fazer quando o prazo aperta? (Capítulo 10 - Débito Técnico)
A equipe pode decidir não fazer os testes automatizados ou não refatorar o código hoje para conseguir entregar a tela amanhã. Nós assumimos um Débito Técnico. Mas atenção: o mestre estrategista sabe que essa dívida deve ser paga na próxima semana, ou o sistema vai virar uma bagunça e travar!
🤖 3. O que fazer quando o cliente pede mudanças toda hora? (Capítulos 13 e 14 - CI/CD)
Se tivermos uma esteira de Integração e Entrega Contínua funcionando, podemos alterar o código, deixar que os robôs testem tudo em minutos e teletransportar a atualização para os castelos de forma segura. Sem a automação, a equipe entraria em pânico!
4. 📖 Exemplo Guiado: O Checklist do Engenheiro
Antes de dar o projeto por concluído e comemorar a vitória no Trono de Ferro, verifique:
- O código está limpo? (Clean Code)
- Os princípios básicos foram seguidos? (SOLID)
- A pirâmide de testes está equilibrada? (Testes)
- A equipe de desenvolvimento e de operações estão conversando? (DevOps)
5. 🛠️ Prática Obrigatória: Tomada de Decisão
Você é o Engenheiro Chefe. Como você resolveria os seguintes problemas de guerra?
- Cenário A: O cliente pediu para adicionar uma nova função urgente. Você não tem tempo de criar os testes automatizados para ela hoje. Você entrega a função sem testes mesmo assim ou avisa o cliente que vai demorar mais para garantir a qualidade? Justifique baseando-se no conceito de Débito Técnico.
- Cenário B: O sistema de um dos castelos caiu porque o programador digitou uma senha errada direto no código (Hardcoding). Qual prática de segurança ou de Clean Code evitaria esse desastre?
7. 📤 Instruções de Entrega (GitHub Desktop + Microsoft Teams)
- Faça o Commit: No GitHub Desktop, digite a mensagem (ex:
Finaliza Capítulo 20 EngSoftware) e clique em Commit to main. - Envie para a Nuvem (Push): Clique em Push origin.
8. 📂 Estrutura de Pastas
extra_engenharia_de_software/
├── capitulos/
│ └── capitulo_20_projeto_p2.md💡 Checkpoint de Lógica
Parabéns por concluir o curso! A Engenharia de Software é uma jornada contínua. As tecnologias mudam, mas os princípios de organização, clareza e qualidade que você aprendeu aqui valerão para toda a sua carreira!
10. 🔥 Desafio de Fixação
Escreva um pequeno texto de 3 linhas resumindo qual foi o conceito mais importante que você aprendeu neste curso e por quê.
🔑 Gabarito de Código/Fórmulas
Gabarito da Prática Obrigatória (Sugestões):
- Resposta: Ambas as respostas podem ser aceitas dependendo do contexto do negócio! Se a função for de vida ou morte para a empresa (ex: corrigir um bug que está dando prejuízo), vale a pena entregar sem testes e assumir o Débito Técnico, desde que a equipe se comprometa a criar os testes logo em seguida. Se for apenas um capricho do cliente, o melhor é educar o cliente e pedir mais prazo para garantir a qualidade.
- Resposta: O uso de Arquivos de Configuração externos (ou variáveis de ambiente) em vez de escrever dados sensíveis direto no código. E também o princípio de Nunca Confiar na Entrada e validar as credenciais.