"Just Enough Software Architecture", publicado em 2010
(georgefairbanks.com)- Just Enough Software Architecture, de George Fairbanks, parte da percepção de que é difícil projetar bons sistemas orientados a objetos e boas arquiteturas apenas com conhecimento de sintaxe de linguagens ou de UML
- O ponto central é a arquitetura baseada em risco: quando o risco é pequeno, evita-se o excesso de design; para riscos que ameaçam o sucesso, aplicam-se técnicas mais rigorosas
- A arquitetura é tratada não como domínio exclusivo de alguns especialistas, mas como uma competência que todos os desenvolvedores devem entender, explicando como restrições e pequenas mudanças afetam os atributos do sistema
- Em vez de processos de desenvolvimento ou operação organizacional, o foco está em técnicas de engenharia, usando modelagem e análise arquitetural para lidar com trade-offs de design em problemas de médio e grande porte
- A estrutura tem duas partes: arquitetura de software baseada em risco e modelagem de arquitetura; aborda abstrações como modelo de domínio, modelo de design, modelo de código, encapsulamento, componentes e conectores
Conhecimento de linguagens e UML não basta para projetar bem
- O autor parte da intenção de criar o livro de que ele precisava quando começou no desenvolvimento de software
- Na época, havia livros sobre linguagens de programação ou programação orientada a objetos, mas poucos livros tratavam de design
- Conhecer os recursos da linguagem C++ não basta para projetar um bom sistema orientado a objetos, e conhecer UML também não basta para projetar uma boa arquitetura de sistema
Arquitetura ajustada ao risco
- O núcleo do livro é risk-driven architecting
- Quando o risco é pequeno, um design detalhado não é necessário; quando há riscos que ameaçam o sucesso, um design frouxo não é suficiente
- Muitos defensores de Agile veem que algum design antecipado pode ser útil, e este livro trata de como fazer “arquitetura na medida suficiente”
- Ele evita processos do tipo “one size fits all” e orienta a ajustar o esforço de arquitetura e design de acordo com os riscos enfrentados
- A maioria das técnicas pode ter sua intensidade ajustada, de um nível quick-and-dirty até um nível muito rigoroso
Tornar a arquitetura uma linguagem de todos os desenvolvedores
- O livro tem como objetivo democratizar a arquitetura
- Uma organização pode ter arquitetos de software, e o próprio leitor também pode ser arquiteto
- Muitos arquitetos querem que todos os desenvolvedores entendam arquitetura
- Se os desenvolvedores não entendem o motivo das restrições e o impacto de pequenas mudanças nos atributos do sistema, os julgamentos de design podem ficar instáveis
- Arquitetura não é um assunto apenas para arquitetos, mas um tema relevante para todos os desenvolvedores de software
Conhecimento procedural e conhecimento declarativo
- O livro se concentra em desenvolver conhecimento declarativo
- Saber bater em uma bola de tênis e saber por que se consegue bater nela são coisas diferentes; isso corresponde à diferença entre conhecimento procedural e conhecimento declarativo
- Se você já é um especialista em projetar e construir sistemas, talvez já tenha usado várias das técnicas do livro
- O livro ajuda a reconhecer melhor o que você já vinha fazendo e dá nomes aos conceitos
- Esse conhecimento declarativo ajuda a melhorar a capacidade de orientar desenvolvedores iniciantes
Foco em engenharia, não em processo
- Quem projeta e constrói sistemas de software precisa lidar ao mesmo tempo com vários problemas, como cronogramas, compromissos de recursos e demandas de stakeholders
- Muitos livros de arquitetura de software já tratam de processos de desenvolvimento e estruturas organizacionais
- Este livro, por outro lado, concentra-se na parte técnica do desenvolvimento de software e na engenharia que faz o sistema funcionar
- Ele permite criar modelos e analisar a arquitetura para fazer trade-offs de design com base em princípios
- Explica técnicas usadas para raciocinar sobre problemas de médio e grande porte e também aponta onde aprender técnicas especializadas com mais detalhes
Design prático em vários níveis de abstração
- O livro trata a arquitetura como uma atividade prática de design
- Arquitetura de software é um tipo de design de software; decisões de design afetam a arquitetura, e a arquitetura também afeta o design
- Bons desenvolvedores investigam obstáculos em detalhe para entendê-los e depois relacionam a natureza desses obstáculos à arquitetura como um todo
- Refletindo esse comportamento de drill-down/pop-up, o livro aborda modelos em vários níveis de abstração, da arquitetura ao design de estruturas de dados
Estrutura e formatos disponíveis
- O livro é composto por duas partes
- Part I: Risk-Driven Software Architecture
- Part II: Architecture Modeling
- Alguns capítulos de amostra podem ser baixados em um único PDF
- O e-book é vendido no Google Play, inclui três formatos sem DRM — ePub, Mobi e PDF — e custa US$ 9,99
- A edição em capa dura está disponível na Amazon
- Google Books e Amazon Search Inside oferecem versões com busca no texto completo
Escopo abordado e escopo excluído
- O livro se concentra em arquitetura de software relacionada à construção de software
- Explica técnicas para fazer o software atender a requisitos de engenharia
- Como as próprias técnicas de engenharia em geral são independentes de processo, o livro também é, em sua maior parte, agnóstico a processos
- Ele não trata de recomendações sobre atividades de gestão como:
- responsabilidades políticas do arquiteto
- quando realizar tipos específicos de reunião
- como coletar requisitos dos stakeholders
Part I: Arquitetura de software baseada em risco
- Embora seja difícil definir arquitetura de software com precisão, algumas de suas características são claras
- Desenvolvedores de software, como engenheiros de outras áreas, usam abstrações e modelos para resolver problemas grandes e complexos
- A arquitetura de software funciona como o esqueleto do sistema e influencia atributos de qualidade; ela é ortogonal à funcionalidade e afeta os atributos do sistema por meio de restrições
- A arquitetura é especialmente importante nas seguintes situações:
- quando o espaço de solução é pequeno
- quando o risco de falha é alto
- quando se enfrentam requisitos difíceis de atributos de qualidade
- A abordagem de design pode ser escolhida entre architecture-indifferent design, architecture-focused design e architecture hoisting
- O procedimento central do modelo baseado em risco é simples
- identificar e priorizar riscos
- selecionar e aplicar um conjunto de técnicas
- avaliar a redução dos riscos
- O capítulo 4 mostra a aplicação do modelo baseado em risco usando como exemplo o sistema Home Media Player
- comunicação da equipe
- integração de componentes COTS
- garantia de consistência de metadados
- A Part I termina com recomendações sobre o uso de modelos e de arquitetura de software
- usar modelos para resolver problemas
- adicionar restrições com cuidado
- concentrar-se nos riscos
- distribuir a capacidade arquitetural por toda a equipe
Part II: Modelagem de arquitetura
- A Part II se concentra em ajudar a formar um modelo conceitual da arquitetura de software
- A estrutura básica de modelos tem três tipos
- modelo de domínio: corresponde a objetos do mundo real
- modelo de design: representa o design do software em construção
- modelo de código: corresponde ao código-fonte
- É possível criar modelos adicionais, chamados views, que mostram detalhes selecionados, e essas views podem ser agrupadas em viewtypes
- Criar fronteiras de encapsulamento é uma técnica importante da arquitetura de software
- usuários de componentes ou módulos podem ignorar o funcionamento interno e se concentrar em outros problemas difíceis
- autores de componentes ou módulos encapsulados ganham liberdade para alterar a implementação sem abalar os usuários
- essa liberdade só é possível quando o encapsulamento é eficaz, por isso o livro aborda técnicas para garanti-lo
- O livro integra técnicas de arquitetura de software de várias fontes
- técnicas que enfatizam atributos de qualidade
- técnicas que enfatizam funcionalidades
- métodos práticos para criar modelos eficazes
- métodos para depurar modelos
- A Part II traz recomendações para usar modelos de forma eficaz, além de tratar das armadilhas que podem surgir nessa tecnologia
- O objetivo final é ter um modelo conceitual rico de abstrações e relações, permitindo ver sistemas de software como um técnico vê uma partida
1 comentários
Opiniões no Hacker News
Há quem diga que, se o risco de gestão do projeto é “um desenvolvedor-chave ser atropelado por um ônibus” e o risco de engenharia de software é “o servidor talvez não escale até 1000 usuários”, é preciso distinguir os dois, mas, pela minha experiência, eles não costumam ficar tão separados assim
Qualidade e estrutura do código, testes e documentação, e o uso de ferramentas padrão e bem conhecidas ajudam em ambos os lados
Por isso, várias vezes levantei para colegas ou chefes a hipótese “e se você for atropelado por um ônibus?”, o que vira um mecanismo de pressão para criar software reproduzível e compreensível
Para evitar a conotação negativa de ferimentos ou morte, é melhor usar “e se você ganhar na loteria?”
O ponto central de “ser atropelado por um ônibus” é que, independentemente da personalidade, não há tempo nenhum para se preparar, e por isso surge a pressão para compartilhar as informações hoje
Infelizmente, ainda não encontrei uma expressão positiva com a mesma implicação
Os dois voltaram mais ou menos uma semana depois, então passei a precisar de outro exemplo padrão de desastre
Para transmitir a ideia, uso com mais frequência a expressão “a próxima pessoa”
Uma situação pior é o burnout: o número de pessoas continua o mesmo, mas mentalmente elas já foram embora
Já vi muitas empresas que não aguentam nem isso, sem que seja uma saída permanente
Ou também dá para usar uma formulação focada na motivação de eliminar pontos únicos de falha, como “aumentar o fator ônibus”
Se for fazer análise de causa-raiz, não dá para parar em “Larry foi atropelado por um ônibus / ganhou na loteria”, porque esse não é o problema de verdade
Arquitetura pela arquitetura é a pior coisa, porque aumenta desnecessariamente a complexidade
O objetivo final de uma boa arquitetura é reduzir custos
Se, por causa da arquitetura, desenvolver e manter o código leva mais tempo, essa arquitetura fracassou
É sempre uma questão de equilíbrio
Portanto, não existe uma arquitetura correta única; a escolha depende do contexto e às vezes precisa ser reavaliada
A flexibilidade é especialmente útil porque permite ajustar a arquitetura em alguma medida e manter a eficiência mesmo quando as circunstâncias mudam
Redução de custos pode ser uma delas
“O modelo orientado a riscos leva o desenvolvedor a aplicar o conjunto mínimo de técnicas de arquitetura para reduzir os riscos mais urgentes. É um processo de perguntar insistentemente: ‘Quais são meus riscos? Qual é a melhor técnica para reduzi-los? O risco foi mitigado e agora posso começar ou retomar a codificação?’. O modelo orientado a riscos pode ser resumido em três etapas: 1. Identificar e priorizar os riscos 2. Selecionar e aplicar um conjunto de técnicas 3. Avaliar a redução dos riscos”
Não quero desperdiçar tempo com técnicas de baixo impacto, nem ignorar riscos que ameaçam o projeto
Para criar um sistema bem-sucedido, é preciso escolher o caminho que usa o tempo da forma mais eficaz, o que significa aplicar técnicas de arquitetura e design para lidar com riscos apenas quando o risco for a motivação
Por exemplo, “arquitetura” inclui usar um estilo cliente-servidor em que o servidor não age primeiro, apenas responde às solicitações do cliente
Esse modelo pode ou não se encaixar bem no problema
https://www.georgefairbanks.com/assets/jesa/Just_Enough_Soft...
Arquitetos técnicos muito bem pagos acabam impondo padrões terríveis que engenheiros de software precisam resolver sob restrições irracionais, como prazos, enquanto eles mesmos não fazem grande coisa
Uma boa arquitetura permite que mais pessoas participem do produto
Se foi publicado em 2010, fico curioso para saber quanto dele sobreviveu desde então.
Gosto de “Design It” porque traz bons workshops e atividades para profissionais técnicos que precisam interagir com stakeholders ou clientes.
Como atuo em consultoria, ele é ainda mais relevante para mim, e também gosto do fato de não se apoiar demais em estilos específicos de arquitetura tecnológica, que mudam com frequência.
Estou falando com base em princípios reais, não em modismos.
O autor dedica bastante tempo a ensaios sobre mentalidade e trata as técnicas concretas de forma leve, mas fornece materiais para leitura adicional.
Ele faz a equipe trabalhar ideias de arquitetura por meio de atividades concretas e, no fim, ajuda a revelar o que realmente importa.
Meu livro tentou encarar essas grandes ideias de frente, mas ficou claro que, por o tema ser tão abstrato, isso é difícil do ponto de vista didático.
Quais ideias sobreviveram desde 2010? Alguns sistemas operacionais são microkernels, outros são monolíticos.
Alguns bancos de dados são relacionais, outros são orientados a documentos.
Algumas aplicações são cliente-servidor, outras são peer-to-peer.
Essas distinções provavelmente são duradouras e, se voltarmos daqui a 100 anos, ainda veremos sistemas com esses designs, mesmo que exemplos como Windows, Oracle e Salesforce tenham desaparecido.
E ainda estaremos falando sobre qualidades como facilidade de modificação ou latência.
O campo da arquitetura de software trata de identificar essas abstrações duradouras.
Há uma explicação concisa em [2].
“Resumo: arquitetura de software é um conjunto de abstrações que nos ajuda a raciocinar sobre software que planejamos construir ou que já construímos. Nosso campo há muito tempo conta com pequenas abstrações, mas levou décadas para acumular abstrações maiores, como atributos de qualidade, ocultação de informações, componentes e conectores, múltiplas visões e estilos arquiteturais. Ao projetar sistemas, encadeamos essas abstrações para preservar a cadeia de intencionalidade e fazer com que o sistema projetado faça o que desejamos. Há 20 anos, Martin Fowler publicou nesta revista o influente artigo ‘Who Needs an Architect?’. Agora é hora de os desenvolvedores olharem novamente para a arquitetura de software e a enxergarem como um conjunto de abstrações que nos permite raciocinar sobre software.”
[1] Michael Keeling, Design It: From Programmer to Software Architect, https://pragprog.com/titles/mkdsa/design-it/
[2] George Fairbanks, Software Architecture is a Set of Abstractions Jul 2023. https://www.computer.org/csdl/magazine/so/2023/04/10176187/1...
A Philosophy of Software Design, de John Ousterhout, foi útil.
Tem muitos conselhos sólidos e fáceis de entender, além de vários exemplos.
Não conheço este livro em si, mas conheço os textos do autor sobre Intellectual Control, e eles são muito perspicazes.
https://www.georgefairbanks.com/ieee-software-v37-n3-may-202...
https://johnwhiles.com/posts/programming-as-theory
Na empresa anterior, circulava o livro Software Architecture for Developers, de Simon Brown: https://leanpub.com/b/software-architecture
Ele ainda está só na minha lista de leitura, e eu já saí daquela empresa, mas recebi uma recomendação muito forte.
Essa empresa também documentava a arquitetura usando o modelo C4.
Fico curioso para saber se alguém aqui já leu.
Suas palestras sobre arquitetura [1] e workshops são especialmente eficazes, e a linguagem de modelagem arquitetural C4 [2] também está ganhando tração de verdade.
Também tenho vídeos no YouTube [3], mas eles não são tão eficazes.
[1] https://www.youtube.com/results?search_query=simon+brown+arc...
[2] https://c4model.com/
[3] https://www.youtube.com/playlist?list=PLRqKmfi2Jh3uoMnZdaWmC...
Acho que “dependente de risco” teria sido um nome muito melhor para esta metodologia.
Por que programadores gostam tanto da expressão “orientado por [X]”?
Este eixo aciona aquela engrenagem, e aquela engrenagem aciona a roda, e assim por diante.
É uma forma abreviada de dizer “qual é o mecanismo mais poderoso nesta complexa máquina de pensamento”.
Há alguns anos, fizemos um clube de leitura com este livro na empresa, e achei que ele era muito repetitivo.
Fico curioso para saber se este livro é um bom recurso para alguém que está começando um projeto open source não trivial.
Ou se há valor para um fundador solo; gostaria de recomendações de livros ou outros materiais úteis para um desenvolvedor solo.
Arquitetura de software é parecida com a arquitetura comum, mas, como o software ainda não teve uma figura como Isaac Newton, é como se engenharia civil ainda não existisse
Até agora, acho que a pessoa mais próxima disso foi Claude Shannon
Porque nem sequer temos unidades de medida
Ainda estamos, na engenharia de software, na fase de “torcer para não desmoronar”
Isso afeta profundamente a produtividade autorrelatada
Por exemplo, uma bicicleta pode parecer mais rápida do que dirigir a 30 milhas por hora, com os vidros fechados, por pequenas ruas suburbanas cheias de placas de pare
Mas, em geral, o motorista chega muito mais rápido a um lugar a 20 quadras de distância
Sem unidades de medida, todo mundo estaria discutindo que a bicicleta é mais rápida
É nesse estado que a engenharia de software está hoje
Construir software não é nem um pouco como construir uma ponte ou um arranha-céu; está muito mais próximo de projetá-los
Em grandes projetos de construção, primeiro se projeta e depois se constrói, e esse projeto é um trabalho enorme
É preciso pensar em tudo, rodar simulações, conversar com stakeholders, entender requisitos e restrições, considerar custo e peso dos materiais etc.
Em grandes obras, meses ou anos podem desaparecer apenas na criação do projeto em si, e o resultado é uma planta extremamente detalhada que abrange quase todos os aspectos da construção
Na verdade, isso é bastante parecido com criar software
Esses projetos de design têm alta incerteza e risco
Ainda assim, é melhor descobrir que está tudo errado antes de começar a gastar recursos caros como muita mão de obra, concreto e aço
Mas você já ouviu algum arquiteto dizer que, para mitigar isso, vai criar um projeto para o projeto? Isso não existe
No máximo, em algum momento pode ter havido um esboço ou um desenho em guardanapo
A SpaceX introduziu alguns elementos ágeis na engenharia, algo aprendido com o desenvolvimento de software
No software, a planta finalizada é executável
O processo de criar a planta é manual, mas o processo de gerar software a partir dessa planta normalmente é automatizado por compiladores e outras ferramentas, sendo muito barato; por isso os desenvolvedores fazem isso o tempo todo
Claro que, no passado, nem sempre foi assim
Naturalmente, o processo de criar uma planta executável envolve muitos riscos, e pode haver designs em guardanapos ou quadros brancos pelo caminho
Mas a ideia de primeiro fazer um design completo e depois uma implementação completa — isto é, o modelo em cascata — nunca funcionou direito em software
Com algumas exceções, normalmente não há uma planta para a planta
Se você ler o artigo original de Royce sobre o modelo em cascata, verá que a palavra “cascata” na verdade nem aparece, e ele sugere vagamente que iteração poderia ser uma boa ideia
Algo como fazer pelo menos uma vez
Ele entendia perfeitamente que o primeiro design provavelmente estaria errado
O Agile eliminou, por otimização, a etapa de baixo valor de criar um design para a planta, algo que fica evidente quando se fazem muitas iterações
Só que, fora de áreas específicas, em geral nós os ignoramos
Por exemplo, olhando por alto este resumo e o sumário, parece haver pouca ou nenhuma menção a métricas de desempenho
Para que serve uma arquitetura se ela não considera o que o computador realmente faz?
Também em termos de produtividade de desenvolvimento ou interface de usuário, por que não há um modelo matemático que descreva a pilha mental necessária para desenvolver, alterar, estender e, mais importante, usar software?
Recursos computacionais, humanos ou de máquina, têm impactos reais e mensuráveis na interação com software como desenvolvedores ou usuários; por que isso é considerado tão raramente?
Por exemplo, o Palácio de Westminster certamente tem elementos de engenharia civil, mas suas características decisivas — texturas ornamentadas, a torre do relógio simbólica e a disposição interna — são determinadas em grande parte por escolhas funcionais e estéticas
O mesmo vale para muitas partes do software