Prezados, boa tarde.

Estou preparando um novo setup de uma fábrica de SW e revendo os padrões de arquitetura a serem utilizados por ela (exemplo micro service). Gostaria de sugestões, recomendações e orientações de vocês sobre qual o melhor setup e uma sugestão de arquitetura a ser implantada.

Exibições: 287

Responder esta

Respostas a este tópico

Ricardo,

   recentemente, participei de projetos que parte ficavam na equipe interna (onde eu estava) e parte ficava em fábrica.

   Alguns pontos que considero importantes são:

  • Criar um BOM CANAL DE COMUNICAÇÂO. Nem sempre isso é possível, mas deve ser buscado com todas as suas forças. :-)
  • Criar um doc de arquitetura estilo Code Conventions.
  • Uma aplicação de exemplo, com várias questões comuns relacionadas à infra de vocês e com as possibilidades comentadas no código. Esta aplicação deve ter testes de unidade, de integração, de front-end, etc. Cuidando, é claro, pra cair no problema de "testing ice cream cone".
  • Definir pelo menos 2 tipos de aplicação: pequenas basicamente CRUDs, de um jeito, mais simples, rodando em Tomcat/Jetty e outra com EJB, Messageria, etc num WildFly da vida. Isso pra o mundo Java. Não sei seu caso aí, mas a lógica é a mesma. Isso evita aplicações bobas com recursos avançados (o famoso canhão pra matar mosquito).
  • Sobre arquitetura (camadas, frameworks, servidores, etc), no local que trabalhei nesse modelo tínhamos uma arquitetura de camadas bem cebola (facade, service, dao, etc). Isso pelo baixo nível técnico das fábricas (e aqui me refiro às grandes consultorias do mercado brasileiro). Hoje, em outro projeto, tentando seguir uma linha mais DDD, como separação do domínio de toda coisa relacionada à infra (front-end, persistência, etc) e a separação de pacotes por conceito de domínio.
    • Os pontos negativos da arquitetura cebola (muitas camadas que te fazem chorar) são claros:
      • código procedural demais e só este ponto já leva à vários outros, como design pobre do código. Claro que me refiro aqui à sistema em linguagens OO ou funcionais. Linguagens procedurais por natureza, um bom projeto de hierarquia de módulos já ajuda.
      • códigos desnecessários somente fazendo delegação pra camada abaixo
      • "modularidade" por camadas dificultando modularização de fato da aplicação.
    • Os pontos positivos são:
      • curva de aprendizagem mínima.
      • simples e direto. Cada coisa em seu lugar e fácil de achar. Sabendo que o nível das pessoas que as fábricas normalmente colocam pra tocar os projetos (pensando no custo), não tem muita discussão técnica sobre o que colocar e onde colocar as coisas.
      • "Fácil" de customizar ferramentas de checagem de código para validar.
      • Deploy separados, se preciso. Vender módulos isolados se for o caso. Criar mais o conceito de componente mesmo.
      • Se forem várias frentes (e equipes) no projeto, a modularização ajuda a controlar a qualidade e evitar que besteiras quebrem toda a aplicação.
  • Preparar métricas na Integração Contínua e Sonar (Monitoramento de débitos técnicos) e deixar isso bem claro no contrato. No contrato a que me refiro, se fosse para dar sustentação à aplicações, a empresa ganhava um X relativo à demanda, mas era levado em consideração essas métricas. Se baixasse cobertura de código, por exemplo, descontava Y. Isso ajudou muito a manter as aplicações manuteníveis.
  • Toda entrega passava também por uma checagem manual pelos arquitetos, que emitiam um laudo de arquitetura podendo reprovar a entrega.
  • Se o desenvolvimento for parte interna e parte externa, acho que na primeira fase/iteração/sprint alguém da equipe técnica da fábrica deveria acompanhar a equipe interna e ver o ritmo, as dificuldades, questões de infra.
  • Uma Wiki e Fórum compartilhados entre as equipes também ajuda bastante.

Obrigado por suas considerações!

RSS

Badge

Carregando...

© 2017   Criado por Adriano Tavares.   Ativado por

Badges  |  Relatar um incidente  |  Termos de serviço