Mini-Projecto · Gerador de componentes interativos
Contexto
A "Interativa Lab", uma pequena produtora de conteúdos digitais para escolas, cria dezenas de componentes parecidos todos os meses: quizzes, galerias, vídeos comentados, enquetes. Cada novo componente demora horas a montar à mão, e os técnicos já copiaram e colaram a estrutura tantas vezes que aparecem pequenas diferenças entre ficheiros que deviam ser iguais.
Foste contratado/a para construir uma ferramenta de código generativo: um pequeno CLI que, a partir de um template e de um tipo de componente, gera automaticamente os ficheiros base (componente, teste e estilos), sempre consistentes, sempre com a mesma estrutura. Trabalhas individualmente ou a pares, entregando a ferramenta a funcionar mais um dossiê técnico (arquitetura, patterns usados, resultados dos testes).
Requisitos
Funcionais
- Um gerador (script ou CLI) que recebe um tipo de componente (
quiz,galeria,video, à escolha) e um nome, e produz os ficheiros correspondentes a partir de um template. - Uma classe base genérica (
ComponenteInterativo) com pelo menos dois componentes concretos que a estendem, demonstrando herança e polimorfismo. - Uso de pelo menos um design pattern explícito e identificado no dossiê (Factory, Strategy ou Observer).
- Uma função de validação de entradas que impede a geração de um componente com nome vazio, inválido ou com caracteres perigosos (ex.: tags HTML).
- Pelo menos três testes automáticos ao gerador (não ao resultado gerado manualmente), incluindo um teste que confirme que dados perigosos são escapados.
Não-funcionais
- Código comentado e organizado em ficheiros claros (gerador, templates, componentes, testes).
- O gerador deve correr sem erros em pelo menos dois cenários diferentes (dois tipos de componente).
- Nenhum segredo (chave, palavra-passe) hardcoded no código ou nos templates.
- Registo (log) simples de cada geração: o que foi criado e quando.
Fases
Fase 1 · Desenho (3h)
Escolher a linguagem (recomendado TypeScript ou JavaScript), desenhar a classe base ComponenteInterativo, escolher o design pattern e esboçar a estrutura de pastas do gerador.
Fase 2 · Classe base e componentes concretos (4h)
Implementar ComponenteInterativo e pelo menos dois componentes concretos (Quiz, Galeria) que a estendem, demonstrando herança e polimorfismo através de um método comum (render()).
Fase 3 · Templates e gerador (6h) Criar os templates (ficheiro de componente, de teste e de estilos) e o script gerador que os preenche a partir do tipo e do nome recebidos. Implementar o design pattern escolhido para decidir que componente criar.
Fase 4 · Validação e segurança (4h)
Implementar a função de validação de entradas: recusar nomes vazios, inválidos ou com conteúdo potencialmente perigoso (ex.: <script>). Garantir que qualquer dado inserido nos templates é escapado.
Fase 5 · Testes (4h) Escrever pelo menos três testes automáticos ao gerador: um caso normal, um caso de validação a falhar de propósito, e um caso de escaping de dados perigosos. Correr os testes e documentar os resultados.
Fase 6 · Dossiê e apresentação (4h) Escrever o dossiê técnico (arquitetura, pattern escolhido e porquê, resultados dos testes, limitações conhecidas) e apresentar o gerador em funcionamento à turma, gerando um componente ao vivo.
Critérios de avaliação
| Critério | Peso |
|---|---|
| Classe base, herança e polimorfismo corretos | 20% |
| Design pattern implementado e bem justificado | 15% |
| Gerador funcional (templates + scaffolding) | 20% |
| Validação de entradas e segurança | 20% |
| Testes automáticos ao gerador | 15% |
| Dossiê e apresentação | 10% |
Erros comuns
- Herdar classes sem existir uma relação lógica real "é um", só para reutilizar código.
- Usar um design pattern só para "parecer mais profissional", sem que resolva um problema concreto do projeto.
- Gerar ficheiros a partir de templates sem escapar os dados de entrada, abrindo uma falha de injeção.
- Testar só manualmente, sem testes automáticos ao gerador.
- Deixar o gerador aceitar qualquer nome, incluindo vazio ou com caracteres perigosos.
- Não documentar no dossiê porque se escolheu aquele design pattern em concreto.
Bónus (opcional)
- Acrescentar um terceiro tipo de componente (
videoouenquete) sem alterar o código do gerador, só acrescentando um template e um caso na Factory. - Publicar o gerador como um pacote
npminstalável localmente (npm link). - Integrar um linter (
ESLint) que corre automaticamente sobre os ficheiros gerados. - Adicionar um modo interativo ao CLI (perguntas ao utilizador em vez de argumentos na linha de comandos), à semelhança do
Plop.
Reflexão
No dossiê final, responde: que parte do teu gerador seria mais difícil de manter se não tivesses usado um design pattern? E: se um teste automático não existisse, que tipo de erro no gerador só se descobriria depois de já ter gerado dezenas de componentes errados?