Pular para o conteúdo principal

Questão de Arquitetura de Software — Padrões de projeto (Design Patterns) — FCC 2025

Arquitetura de SoftwarePadrões de projeto (Design Patterns)
Código
fc074344
Banca
FCC
Órgão
TRF - 4ª REGIÃO
Ano
2025
Nível
Superior
Cargo
Técnico Judiciário - Área Apoio Especializado - Especialidade: Desenvolvimento de Sistema da Informação
No desenvolvimento de aplicações para um tribunal, a equipe técnica adota padrões de projeto (GOF), boas práticas de codificação e princípios de design como SOLID, DRY e KISS. Em projetos que envolvem arquiteturas de microsserviços, arquiteturas orientadas a eventos e a construção de pipelines de dados, a aplicação desses conceitos é essencial para garantir a robustez das soluções. Nesse contexto, o desenvolvimento deve seguir estratégias que
  1. Aagrupem funcionalidades relacionadas em módulos únicos e extensos, buscando reduzir a dispersão de código e simplificar a navegação no projeto.
  2. Baceleremaentrega de funcionalidades incrementais, ainda que isso implique acúmulo progressivo de dívidas técnicas no código.
  3. Cadotem abordagens flexíveis de implementação, dispensando o uso explícito de princípios de design, desde que os testes automatizados estejam presentes.
  4. Dincorporem refatoração contínua, mantenham o código alinhado aos princípios de design e favoreçam a manutenção e a evolução dos sistemas.
  5. Epriorizem a consistência transacional entre microsserviços, ainda que isso limite o uso de comunicação assíncrona em arquiteturas orientadas a eventos.
Revelar gabarito e comentário

GabaritoD — incorporem refatoração contínua, mantenham o código alinhado aos princípios de design e favoreçam a manutenção e a evolução dos sistemas.

Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.

Boas práticas de desenvolvimento de software

Gabarito: letra D. A alternativa D resume corretamente as estratégias que o desenvolvimento deve seguir: incorporar refatoração contínua, manter o código alinhado a princípios de design (como SOLID, DRY e KISS) e favorecer a manutenção e evolução dos sistemas. As demais alternativas propõem práticas inadequadas, como ignorar princípios de design, acumular dívida técnica ou priorizar consistência transacional em detrimento da comunicação assíncrona.

Alternativa A — ❌ Incorreta

Agrupar funcionalidades em módulos únicos e extensos contradiz o princípio da responsabilidade única (SRP) e a recomendação de alta coesão e baixo acoplamento. Em arquiteturas de microsserviços, busca-se justamente o contrário: serviços pequenos e focados, que facilitam a manutenção e a escalabilidade.

Alternativa B — ❌ Incorreta

Acelerar entregas acumulando dívida técnica é uma péssima prática. Embora a entrega incremental seja desejável, ela deve ser acompanhada de refatoração contínua para evitar que a dívida técnica comprometa a qualidade e a evolução do sistema. O acúmulo progressivo de dívida técnica é, por si só, um anti-padrão.

Alternativa C — ❌ Incorreta

Testes automatizados são essenciais, mas não substituem o uso de princípios de design. Ignorar princípios como SOLID leva a código menos coeso, mais acoplado e mais difícil de manter e testar, mesmo com boa cobertura de testes. As boas práticas exigem a aplicação simultânea de testes e princípios de design.

Alternativa D — ✅ Correta ⟵ GABARITO

Esta alternativa descreve exatamente o que se espera de um desenvolvimento profissional: refatoração contínua para manter o código limpo, alinhamento aos princípios de design (como SOLID, DRY e KISS) e foco na manutenibilidade e evolução do sistema. Essas práticas são fundamentais em projetos de microsserviços e arquiteturas orientadas a eventos, onde a complexidade exige disciplina.

Alternativa E — ❌ Incorreta

Em arquiteturas orientadas a eventos e microsserviços, a consistência transacional forte entre serviços é geralmente evitada porque compromete a escalabilidade e a autonomia dos serviços. O padrão recomendado é o de consistência eventual, apoiado por comunicação assíncrona. Priorizar a consistência transacional forte limitaria o uso de mensageria assíncrona, indo contra os princípios desse estilo arquitetural.

Gabarito: letra D.

Link permanente: /questoes/fc074344