Please enable JavaScript.
Coggle requires JavaScript to display documents.
Arquiteto de software (Responsabilidades / Requisitos pessoais (HUMILDADE…
Arquiteto de software
Responsabilidades / Requisitos pessoais
Projetar uma solução compatível com os requisitos atuais da corporação
Soluções flexíveis
Permitir mudanças futuras
Qaulidade técnica
Apoio técnico
Tomadas de decisões do time
Comunicação com o time
POuco adianta vc saber se vc não sabe explicar
Profundo conhecimento em programação
Muito tempo de profissão e muito estudo
Domínio de uma plataforma pelo menos
Conhecer padrões arquiteturais
Conhecimento em designe de código
Código de qualidade tem que ser testável
Necessário estudo: Respeito e não autoritarismo
Proativo
#
Prever problemas e propor soluções
Iniciativa
Diferente do perfil reativo
Toma as decisões antes dos problemas se tornarem muito grandes
HUMILDADE = Respeitar a diversidade de conhecimentos dentro do time.
#
Você não é a única pessoa capaz de resolver os problemas
A sua forma de resolver não é a única e não necessariamente a melhor
Devemos estar aberto a críticas
Na área de software existe um ego muito grande
Os interesses da empresa devem ser priorizados. As vezes é necessário abrir mão dos próprios interesses técnicos
O arquiteto deve ser um profundo pesquisador
INGLÊS
Ser didático
Saber delegar tarefas
Saber questionar
Não apontar erros
Saber conduzir discussões
Estar sempre aberto à novas tecnologias
Ter pensamento estratégico
Visionar várias maneiras de atingir um objetivo
Assumir erros
Eisnten errou quando negou a questão da mecânica quantica
Arquiteto de SW tbm programa
Arquiteturas
Arquiteto corporativo
Arquiteto de solução
Arquitetura de software
Foco deste estudo
Arquiteto de negócio
Definições de papéis de arquitetos:
https://iasaglobal.org/itabok-1/engagement-model/job-descriptions/
POO - Programação orientada a objetos
Padrões e abordagens de arquitetura
Estado
Comportamento
Herança
Abstração
Uma classe abstrata não pode ser instanciada. Serve somente para ser herdada
Polimorfismo
Encapsulamento
Herança x Composição
Herança faz parte dos princípios da OO, porém torna o código mais acoplado
Interface x Implementação
Acoplamento e coesão
Princípios POO
Herança faz parte dos princípios fundamentais mas pode ser um problema
Se existir uma falha na forma de herdar
Sempre que possível utilize a composição ao invés de herança
Isso não cria uma dependência direta
Ela viola um dos pilares (encapsulamento), pois expões nas classes filhas os seus métodos
Gera um forte acoplamento entre duas classes o que é contra os princípios da OO
Saber conversar com diferentes níveis hierárquicos
