Tag: dev

Página 299

Elasticidade

Figura 20-11. Modificações da arquitetura para lidar com o risco da disponibilidade Elasticidade No segundo exercício de risk storming, o arquiteto escolheu focar a elasticidade, ou seja, picos na carga de usuários (conhecidos como escalabilidade variável). Embora haja apenas 250 enfermeiros (que fornece um regulador automático para a maioria dos serviços), a parte do autoatendimento do sistema pode acessar o mecanismo de diagnóstico assim como os enfermeiros, aumentando muito o número de requisições na interface de diagnóstico. Os participantes estavam preocupados com os surtos e com a época de gripe, quando a carga antecipada do sistema aumentaria muito.

Durante a sessão de risk storming, todos os participantes identificaram a interface do mecanismo de diagnóstico como de alto risco (9). Com apenas 500 requisições por segundo, os participantes calcularam que não havia meios de a interface conseguir acompanhar a taxa de transferência antecipada, em particular com a arquitetura atual usando REST como o protocolo de interface.

Um modo de mitigar esse risco é utilizar filas assíncronas (mensagens) entre o gateway da API e a interface do mecanismo de diagnóstico para fornecer um ponto de retorno se as chamadas no mecanismo de diagnóstico são armazenadas em backup. Embora seja uma boa prática, ela ainda não mitiga o risco, pois os enfermeiros (assim como os pacientes no autoatendimento) esperariam muito tempo para terem respostas do mecanismo e essas requisições provavelmente expirariam. Usar o que é conhecido como Ambulance Pattern (padrão ambulância) daria aos enfermeiros uma prioridade mais alta em relação ao autoatendimento. Por isso, seriam necessários dois canais de mensagem. Embora essa técnica ajude a mitigar o risco, ainda não lida com os tempos de espera. Os participantes decidiram que, além da técnica da fila para fornecer um ponto de retorno, colocar em cache certas perguntas de diagnóstico relacionadas a um surto removeria as chamadas de surto e gripe, não chegando na interface do mecanismo de diagnóstico.

As mudanças correspondentes na arquitetura são mostradas na Figura 20-12. Observe que, além dos dois canais de fila (um para os enfermeiros outro para os pacientes em autoatendimento), há um novo serviço chamado Servidor de Cache para Diagnóstico de Surtos

Página 300

Segurança

que lida com todas as requisições relacionadas a certa pergunta relacionada a surto ou gripe.

Com essa arquitetura feita, o fator limitador foi removido (chamadas para o mecanismo de diagnóstico), permitindo dezenas de milhares de requisições simultâneas. Sem um esforço de risk storming, esse risco poderia não ter sido identificado até acontecer um surto ou até a época de gripes.

Figura 20-12. Modificações na arquitetura para lidar com o risco da elasticidade Segurança Encorajado com os resultados dos dois primeiros esforços de risk storming, o arquiteto decide fazer uma sessão de risk storming final sobre outra característica importante da arquitetura que deve ter suporte no sistema para garantir seu sucesso: a segurança. Devido aos requisitos regulatórios HIPAA, o acesso aos prontuários via interface de troca de prontuários deve ser seguro, permitindo que apenas enfermeiros os acessem se necessário. O arquiteto acredita que isso não é um problema devido às verificações de segurança no gateway da API (autenticação e autorização), mas está curioso para saber se os participantes encontram outros elementos de risco da segurança.

Durante o risk storming, todos os participantes identificaram o gateway da API do Sistema de Diagnóstico como de alto risco da segurança (6). O raciocínio para essa classificação alta foi o alto impacto da equipe admin ou dos pacientes em autoatendimento acessando os prontuários (3) em combinação com a probabilidade média (2). A possibilidade de ocorrência do risco não foi classificada como alta por causa das verificações de segurança para cada chamada da API, mas ainda classificada como média porque todas as chamadas (autoatendimento, admin e enfermeiros) passam pelo mesmo gateway da API. O arquiteto, que classificou o risco apenas como baixo (2), ficou convencido, durante a atividade de consenso do risk storming, que o risco era, de fato, alto a precisava de mitigação.

Todos os participantes acordaram que ter gateways da API separados para cada tipo de usuário (admin, autoatendimento/diagnóstico e enfermeiros) evitaria que as chamadas da IU web para o admin ou o autoatendimento chagassem na interface de troca de prontuários. O arquiteto concordou, criando a arquitetura final, como mostrado na Figura 20-13.

Página 301

Figura 20-13. Modificações finais da arquitetura para lidar com o risco da segurança O cenário anterior mostra o poder do risk storming. Colaborando com outros arquitetos, desenvolvedores e principais stakeholders nas dimensões do risco que são essenciais para o sucesso do sistema, áreas de risco são identificadas que, caso contrário, teriam passado despercebidas. Compare as Figuras 20-9 e 20-13, e observe a grande diferença na arquitetura antes e depois do risk storming. Essas importantes mudanças lidam com questões de disponibilidade, elasticidade e segurança na arquitetura.

O risk storming não é um processo de ocorrência única. Pelo contrário, é contínuo durante a vida de qualquer sistema para capturar e mitigar as áreas de risco que ocorrem em produção. A frequência do risk storming depende de muitos fatores, inclusive da frequência da mudança, dos esforços de refatoração da arquitetura e do desenvolvimento incremental da arquitetura. É normal passar por um esforço de risk storming em certa dimensão depois de um recurso maior ser adicionado ou no final de cada iteração.

Página 302

21. Diagramando e Apresentando a Arquitetura

CAPÍTULO 21 Diagramando e Apresentando a Arquitetura Os arquitetos recém-formados normalmente comentam sobre o quão surpresos eles estão com a variadade do trabalho, que vai além do conhecimento técnico e da experiência, o que lhes permitiu exercerem a função de arquiteto em primeiro lugar. Em particular, comunicação efetiva se torna essencial para o sucesso de um arquiteto. Independentemente do quanto brilhantes sejam as ideias técnicas de um arquiteto, se ele não consegue convencer os gerentes a financiá-las e os desenvolvedores a criá-las, esse brilhantismo nunca se manifestará.

Diagramar e apresentar as arquiteturas são duas habilidades sociais essenciais para os arquitetos. Embora existam livros inteiros sobre cada tópico, veremos alguns pontos de destaque de cada.

Esses dois temas aparecem juntos porque têm algumas características parecidas: cada um forma uma representação visual importante de uma visão da arquitetura, apresentada com uma mídia diferente. Contudo, a consistência da representação é o conceito que liga ambos.

Ao descrever visualmente uma arquitetura, muitas vezes o criador deve mostrar diferentes visões da arquitetura. Por exemplo, é possível que o arquiteto mostre uma visão geral da topologia inteira da arquitetura, então detalhe partes individuais para entrar nas minúcias do design. Porém, se o arquiteto mostra uma parte sem indicar onde ela está na arquitetura geral, isso confunde os observadores. Consistência da apresentação é a prática de sempre mostrar a relação entre as partes de uma arquitetura em diagramas ou apresentações antes de mudar a exibição.

Por exemplo, se um arquiteto quisesse descrever os detalhes de como os plug-ins se relacionam na solução Silicon Sandwiches, a arquitetura mostraria a topologia inteira, então detalharia a estrutura de plug-ins, mostrando aos observadores a relação entre eles; um exemplo é mostrado na Figura 21-1.

Página 303

Figura 21-1. Usando a consistência da representação para indicar o contexto em um diagrama maior Um uso cuidadoso da consistência da representação assegura que os observadores entendam o escopo dos itens apresentados, eliminando uma fonte comum de confusão.

Diagramando

A topologia da arquitetura é sempre de interesse para arquitetos e desenvolvedores porque captura como a estrutura se encaixa e forma uma compreensão compartilhada valiosa na equipe. Assim, os arquitetos devem aprimorar suas habilidades de diagramação para uma precisão extrema.

Ferramentas

A geração atual de ferramentas de diagramação para arquitetos é extremamente avançada, e um arquiteto deve se especializar na ferramenta escolhida. Contudo, antes de optar por uma bela ferramenta, não ignore os artefatos de baixa fidelidade, em especial no início do processo de design. Criar artefatos de design muito efêmeros impede que os arquitetos se apeguem demais ao que eles criaram, um antipadrão denominado Apego Irracional pelo Artefato.

Página 304

Apego Irracional pelo Artefato … é a relação proporcional entre o apego irracional de uma pessoa a algum artefato e o tempo que levou para produzilo. Se um arquiteto cria um belo diagrama usando uma ferramenta como a Visio, que leva duas horas, ele tem um apego irracional por esse artefato, que é mais ou menos proporcional à quantidade de tempo investido, e isso também significa que ele será mais apegado a um diagrama de quatro horas do que a um que levou duas horas.

Um dos benefícios da abordagem de baixo ritual usada no desenvolvimento de software ágil gira em torno de criar artefatos JIT, com o mínimo de cerimônia possível (isso ajuda a explicar a dedicação de muitos profissionais ágeis às fichas e às notas adesivas). Usar ferramentas de baixa tecnologia permite que os membros da equipe descartem o que não está certo, liberando-os para experimentar e permitir que a verdadeira natureza do artefato surja por meio de revisão, colaboração e debate.

A variação favorita de um arquiteto sobre a foto do celular de um quadro branco (junto com o inevitável “Não Apague!”) usa um tablet anexado a um retroprojetor no lugar de um quadro branco. Isso tem muitas vantagens. Primeiro, o tablet tem uma tela ilimitada e pode aceitar quantos desenhos uma equipe talvez precise. Segundo, permite copiar/colar situações “hipotéticas” que encobrem a original quando feita em um quadro branco. Terceiro, as imagens capturadas em um tablet já estão digitalizadas e não têm o inevitável brilho associado às fotos de celular nos quadros brancos.

Por fim, um arquiteto precisa criar belos diagramas em uma ferramenta elegante, mas assegurar que a equipe tenha iterado no design o suficiente para investir tempo ao capturar algo.

Existem ferramentas avançadas para criar diagramas em toda plataforma. Embora não defendamos necessariamente uma ou outra (ficamos bem felizes usando a OmniGraffle para todos os diagramas neste livro), os arquitetos devem procurar, pelo menos, esta base de recursos:

Camadas Ferramentas de desenho muitas vezes têm o suporte de camadas, que os arquitetos devem aprender bem. Uma camada permite ao desenhista vincular um grupo de itens de modo lógico para permitir ocultar/mostrar camadas individuais. Usando camadas, um arquiteto pode criar um diagrama completo, mas ocultar grandes detalhes quando eles não são necessários. Usar camadas também permite que os arquitetos criem imagens de modo incremental para as apresentações posteriores (veja “Construções Incrementais”).

Moldes/templates Os moldes permitem que um arquiteto crie uma biblioteca de componentes visuais em comum, muitas vezes compostos por outras formas básicas. Por exemplo, neste livro, os leitores veem imagens padrão de coisas como microsserviços, que existem como um único item no molde dos autores. Criar um molde para padrões e artefatos comuns em uma organização gera consistência nos diagramas da arquitetura e permite que o arquiteto crie novos diagramas com rapidez.

Ímãs Muitas ferramentas de desenho dão assistência quando desenham linhas entre as formas. Os ímãs representam os lugares nessas formas onde as linhas se conectam automaticamente, fornecendo um alinhamento automático e outras sutilezas visuais.

Página 305

Algumas ferramentas permitem que o arquiteto adicione mais ímãs ou criem seus próprios para personalizar como as conexões ficam em seus diagramas.

Além desses recursos úteis específicos, a ferramenta deve, claro, ter suporte para linhas, cores e outros artefatos visuais, assim como a capacidade de exportar em vários formatos.

Padrões da Diagramação: UML, C4 e ArchiMate

Existem vários padrões formais para os diagramas técnicos no software.

UML UML (Unified Modeling Language) foi um padrão que uniu três filosofias de design concorrentes que coexistiam nos anos 1980. Ele devia ser o melhor de todos, mas, como muitas coisas planejadas pelo comitê, falhou em criar muito impacto fora das organizações que obrigavam seu uso.

Arquitetos e desenvolvedores ainda usam a classe UML e diagramas de sequência para comunicar a estrutura e o fluxo de trabalho, mas grande parte dos outros tipos de diagrama UML caiu em desuso.

C4 C4 é uma técnica de diagramação desenvolvida por Simon Brown para lidar com as deficiências no UML e modernizar sua abordagem. Os quatro Cs em C4 significam:

Contexto Representa o contexto inteiro do sistema, inclusive os papéis dos usuários e as dependências externas.

Contêiner Os limites físicos (e muitas vezes lógicos) da implementação e os contêineres na arquitetura. Essa visão forma um ponto de encontro eficaz para profissionais de operações e arquitetos.

Componente A visão do sistema que o componente tem; isso se alinha bem com a visão do sistema de um arquiteto.

Classe C4 usa o mesmo estilo de diagramas de classe do UML, que são eficientes; portanto, não é preciso substituí-los.

Se uma empresa busca padronizar com uma técnica de diagramação, o C4 é uma boa alternativa. Contudo, como todas as outras ferramentas de diagramação técnica, ela não consegue expressar todo tipo de design que uma arquitetura pode realizar. O C4 é mais adequado para arquiteturas monolíticas, em que as relações entre contêiner e componentes podem diferir, e é menos adequado para as arquiteturas distribuídas, como os microsserviços.

Página 306

ArchiMate ArchiMate (uma combinação de Arquitetura+Animação) é uma linguagem de modelagem da arquitetura corporativa de código aberto com suporte para descrição, análise e visualização da arquitetura dentro e entre os domínios comerciais. ArchiMate é um padrão técnico do The Open Group e oferece uma linguagem de modelagem mais leve para os ecossistemas corporativos. O objetivo do ArchiMate é ser “o menor possível”, não cobrindo todo cenário de caso extremo. Como tal, se tornou uma escolha popular entre muitos arquitetos.

Diretrizes do Diagrama

Independentemente de se um arquiteto usa sua própria linguagem de modelagem ou uma formal, ele deve desenvolver seu próprio estilo ao criar os diagramas e deve se sentir livre para pegar emprestadas as representações que ele considera particularmente eficientes. Veja algumas diretrizes gerais a usar ao criar diagramas técnicos.

Títulos Verifique se todos os elementos do diagrama têm títulos ou são bem conhecidos pelo público.

Use rotação e outros efeitos para fazer os títulos “colarem” na coisa associada, fazendo um uso eficiente do espaço.

Linhas As linhas devem ser grossas o bastante para serem vistas. Se as linhas indicam um fluxo de informação, então use setas para indicar o tráfego direcional ou bidirecional. Diferentes tipos de seta podem sugerir uma semântica variada, mas os arquitetos devem ser consistentes.

Em geral, um dos poucos padrões que existem nos diagramas da arquitetura é que as linhas sólidas tendem a indicar uma comunicação síncrona e as linhas pontilhadas indicam a assíncrona.

Formas Embora as linguagens de modelagem formais descritas tenham formas padrão, não existe nenhuma forma universal no mundo de desenvolvimento de software. Assim, cada arquiteto tende a criar seu próprio conjunto padrão de formas, por vezes divulgando-o em toda a organização para criar uma linguagem padrão.

Costumamos usar caixas tridimensionais para indicar artefatos de implementação e retângulos para indicar um contêiner, mas não temos nenhuma legenda em particular além disso.

Rótulos Os arquitetos devem rotular cada item em um diagrama, sobretudo se há alguma chance de ambiguidade por parte dos leitores.

Página 307

Cores Muitas vezes, os arquitetos não usam cores o bastante; muitas vezes, os livros são impressos em preto e branco, portanto arquitetos e desenvolvedores se acostumaram aos desenhos monocromáticos. Apesar de ainda preferirmos o monocromático, usamos a cor quando isso ajuda a diferenciar um artefato de outro. Por exemplo, ao discutir as estratégias de comunicação dos microsserviços em “Comunicação”, no Capítulo 17, usamos tonalidades para indicar que dois microsserviços diferentes participam da coordenação, não duas instâncias do mesmo serviço como reproduzido na Figura 21-2.

Figura 21-2. Reprodução do exemplo de comunicação dos microsserviços mostrando diferentes serviços com tonalidades Legendas Se as formas são ambíguas por algum motivo, inclua uma legenda no diagrama indicando claramente o que cada forma representa. Nada pior do que um diagrama que leva a erros de interpretação, que é pior do que nenhum diagrama.

Apresentação

Outra habilidade social requerida pelos arquitetos modernos é a capacidade de fazer apresentações eficientes usando ferramentas como PowerPoint e Keynote. São a língua franca das organizações modernas, e as pessoas na organização esperam um uso competente delas.

Infelizmente, diferentemente dos processadores de texto e das planilhas, ninguém parece passar muito tempo estudando como usar bem essas ferramentas.

Neal, um dos coautores deste livro, escreveu um livro vários anos atrás intitulado Pre (sem publicação no Brasil), sobre adotar a abordagem de padrões/antipadrões comum no mundo do software e aplicá-la nas apresentações técnicas.

Página 308

O livro Presentation Patterns faz uma importante observação sobre a diferença fundamental entre criar um documento versus uma apresentação para mostrar um caso para algo, no tempo.

Em uma apresentação, o apresentador controla com que rapidez uma ideia se desdobra, já o leitor de um documento controla isso. Assim, uma das habilidades mais importantes que um arquiteto pode aprender com sua ferramenta de apresentação escolhida é como manipular o tempo.

Manipulando o Tempo

As ferramentas de apresentação oferecem dois modos de manipular o tempo nos slides:

transições e animações. As transições movem slide por slide e as animações permitem ao designer criar movimento em um slide. Em geral, as ferramentas de apresentação permitem apenas uma transição por slide, mas muitas animações para cada elemento: entrar (aparecer), sair (desaparecer) e ações (como movimento, escala e outro comportamento dinâmico).

Embora as ferramentas ofereçam vários efeitos chamativos, como bigornas caindo, os arquitetos usam transição e animações para ocultar os limites entre os slides. Um antipadrão comum mostrado em Presentation Patterns se chama Cookie-Cutter e estabelece que as ideias não têm uma contagem de palavras predeterminada e, assim, os designers não devem preencher o conteúdo artificialmente para que pareçam completar um slide. Do mesmo modo, muitas ideias são maiores que um único slide. Usar combinações sutis de transições e animações, como dissolver, permite que os apresentadores ocultem os limites de um slide individual, unindo um conjunto deles para contar uma história. Para indicar o fim de um pensamento, os apresentadores devem usar uma transição diferente e distinta (como uma porta ou um cubo) para dar uma indicação visual de que está indo para um tópico diferente.

Construções Incrementais

O livro Presentation Patterns mostra Bullet-Riddled Corpse como um antipadrão comum das apresentações corporativas, em que todo slide é basicamente as notas do orador, projetadas para todos verem. A maioria dos leitores tem a experiência angustiante de assistir a um slide cheio de texto aparecendo durante uma apresentação, lendo tudo (porque ninguém resiste e lê assim que ele aparece), sentado por 10 minutos enquanto o apresentar lê devagar os pontos para o público. Não é de se admirar que tantas apresentações corporativas sejam maçantes!

Ao apresentar, o orador tem dois canais de informação: verbal e visual. Colocando muito texto nos slides, então dizendo basicamente as mesmas palavras, o apresentador sobrecarrega um canal de informação e priva o outro. A melhor solução é usar construções incrementais para os slides, aumentando as informações (gráficas, espera-se) conforme a necessidade, não tudo de uma vez.

Por exemplo, digamos que um arquiteto crie uma apresentação explicando os problemas de usar a ramificação (git branches) de features e queira falar sobre as consequências negativas de manter as ramificações ativas por muito tempo. Considere o slide gráfico mostrado na Figura 21-3.

Página 309

Figura 21-3. Versão ruim de um slide mostrando um antipadrão negativo Na Figura 21-3, se o apresentador mostra o slide inteiro de cara, o público pode ver que algo ruim acontece perto do final, mas ele deve esperar a exposição para chegar nesse ponto.

Em vez disso, o arquiteto deve usar a mesma imagem, mas ocultar partes dela ao mostrar o slide (usando uma caixa branca sem borda) e expor uma parte por vez (fazendo desaparecer na caixa que cobre), como mostrado na Figura 21-4.

Página 310

Figura 21-4. Uma versão de incremento melhor que mantém o suspense Na Figura 21-4, o apresentador ainda tem uma chance de manter o suspense vivo, tornando a fala inerentemente mais interessante.

Usar animações e transições junto com construções incrementais permite que o apresentador faça apresentações mais atraentes e divertidas.

Infodecks Versus Apresentações

Alguns arquitetos usam slides em ferramentas como PowerPoint e Keynote, mas nunca realmente as apresentam. Pelo contrário, eles são enviados por e-mail como um artigo de revista, e cada pessoa os lê segundo seu próprio ritmo. Infodecks são slides que não devem ser projetados, mas resumem as informações em gráficos, basicamente usando uma ferramenta de apresentação como um pacote de editoração eletrônica.

Página 311

A diferença entre essas duas mídias é a abrangência do conteúdo e o uso de transições e animações. Se alguém passa o slide como um artigo de revista, o autor dos slides não precisa adicionar elementos do tempo. A outra diferença principal entre infodecks e apresentações é a quantidade de material. Como os infodecks são individuais, eles contêm todas as informações que o criador deseja passar. Ao fazer uma apresentação, os slides devem ser (intencionalmente) a metade da apresentação, com a outra metade sendo a pessoa em pé falando!

Os Slides São Metade da História

Um erro comum que os apresentadores cometem é criar o conteúdo inteiro da apresentação nos slides. Contudo, se os slides são abrangentes, o apresentador deve poupar a todos o tempo de ficar sentados durante uma apresentação e lhes enviar por e-mail como um slide! Os apresentadores cometem o erro de adicionar material demais aos slides quando podem tornar os pontos importantes mais convincentes. Lembre-se: os apresentadores têm dois canais de informação, portanto usá-los estrategicamente pode adicionar mais energia à mensagem. Um ótimo exemplo é o uso estratégico da invisibilidade.

Invisibilidade

Invisibilidade é um padrão simples em que o apresentador insere um slide preto vazio na apresentação para focar de novo a atenção apenas no orador. Se alguém tem dois canais de informação (slides e orador) e desativa um deles (os slides), automaticamente adiciona mais ênfase ao orador. Assim, se um apresentador deseja fazer uma observação, insira um slide vazio; todos na sala focarão sua atenção no orador porque agora ele é a única coisa interessante na sala para olhar.

Aprender o básico de uma ferramenta de apresentação e algumas técnicas para fazer apresentações melhores é um ótimo acréscimo às habilidades dos arquitetos. Se um arquiteto tem uma ótima ideia, mas não consegue descobrir um meio de apresentá-la com eficiência, ele nunca terá a chance de realizar essa visão. Arquitetura requer colaboração; para ter colaboradores, os arquitetos devem convencer as pessoas a embarcar nessa visão. Os palanques corporativos modernos são as ferramentas de apresentação, portanto vale a pena aprender a usá-las bem.

Página 312

22. Tornando as Equipes Eficientes

CAPÍTULO 22 Tornando as Equipes Eficientes Além de criar uma arquitetura técnica e tomar decisões de arquitetura, um arquiteto de software também é responsável por orientar a equipe de desenvolvimento na implementação da arquitetura. Os arquitetos de software que fazem isso bem criam equipes de desenvolvimento eficientes que trabalham de perto para resolver problemas e criar soluções vencedoras. Embora pareça óbvio, muitas vezes vimos arquitetos ignoraram as equipes de desenvolvimento e trabalharem em ambientes de silo ao criar uma arquitetura. Então essa arquitetura é passada para uma equipe de desenvolvimento que tenta implementá-la corretamente. Ser capaz de tornar as equipes produtivas é um dos modos eficientes e bem-sucedidos que diferenciam os arquitetos de software. Neste capítulo, apresentamos algumas técnicas básicas que um arquiteto pode utilizar para tornar eficientes as equipes de desenvolvimento.

Limites da Equipe

Nossa experiência diz que um arquiteto de software pode influenciar muito o sucesso ou o fracasso de uma equipe de desenvolvimento. As equipes que se sentem deixadas de fora ou estranguladas pelos arquitetos de software (e também pela arquitetura) muitas vezes não têm os níveis certos de orientação e conhecimento sobre vários limites no sistema e, como consequência, não implementam a arquitetura corretamente.

Uma das funções de um arquiteto de software é criar e comunicar os limites, ou a duração, nos quais os desenvolvedores podem implementar a arquitetura. Os arquitetos podem criar muita ou pouca limitação ou as limitações certas. Esses limites são mostrados na Figura 22-1. O impacto de ter muito ou pouco limite afeta diretamente a capacidade das equipes de implementarem com sucesso a arquitetura.

Figura 22-1. Tipos de limite criados por um arquiteto de software

Página 313

Os arquitetos que criam muitas restrições formam um limite apertado em torno das equipes de desenvolvimento, impedindo o acesso a muitas ferramentas, bibliotecas e práticas necessárias para implementar o sistema com eficiência. Isso causa frustração na equipe, em geral fazendo com que os desenvolvedores saiam do projeto, indo para ambientes mais alegres e saudáveis.

O oposto também pode acontecer. Um arquiteto de software pode criar restrições muito liberais (ou nenhuma), deixando todas as decisões importantes da arquitetura para a equipe de desenvolvimento. Nesse cenário, que é tão ruim quanto os limites apertados, a equipe basicamente assume o papel do arquiteto de software, fazendo a comprovação dos conceitos e lutando com as decisões de design sem a devida orientação, resultando em improdutividade, confusão e frustração.

Um arquiteto de software eficiente tenta fornecer o nível certo de orientação e restrições para que a equipe tenha as ferramentas e as bibliotecas certas para implementar a arquitetura com eficiência. O resto deste capítulo é dedicado a como criar esses limites eficientes.

Personalidades do Arquiteto

Existem três tipos básicos de personalidades do arquiteto: arquiteto controlador (Figura 22-2), arquiteto folgado (Figura 22-3) e arquiteto eficiente (Figura 22-5). Cada personalidade corresponde a certo tipo de limite visto na seção anterior sobre as restrições da equipe: os arquitetos controladores produzem muitos limites, os arquitetos folgados produzem poucos limites e os arquitetos eficientes, os tipos certos de limite.

Controlador

Figura 22-2. Arquiteto controlador (iStockPhoto) O arquiteto controlador tenta controlar cada aspecto detalhado do processo de desenvolvimento de software. Cada decisão que um arquiteto controlador toma normalmente é granular e de baixo nível, resultando em limites demais na equipe de desenvolvimento.

Esses arquitetos produzem os muitos limites apertados examinados na seção anterior. Um controlador pode impedir a equipe de desenvolvimento de baixar qualquer biblioteca útil de código aberto ou de terceiros e insistir que as equipes escrevam tudo do zero usando a API da

Página 314

Arquiteto Folgado

Página 315

Figura 22-3. Arquiteto folgado (iStockPhoto) O arquiteto folgado é o tipo que não codificou por muito tempo (se alguma vez fez isso) e não leva em conta os detalhes da implementação ao criar uma arquitetura. Em geral, ele é desconectado das equipes de desenvolvimento, nunca está por perto ou simplesmente pula de projeto em projeto assim que os diagramas da arquitetura iniciais são concluídos.

Em alguns casos, o folgado simplesmente lida com a situação em termos de tecnologia ou domínio corporativo, portanto não consegue liderar nem orientar as equipes do ponto de vista do problema técnico ou corporativo. Por exemplo, o que os desenvolvedores fazem? Eles codificam, claro. Escrever o código do programa é realmente difícil de fingir; um desenvolvedor escreve o código do programa ou não. Contudo, o que um arquiteto faz? Ninguém sabe! A maioria desenha muitas linhas e caixas, mas o quão detalhado deve ser o arquiteto nos diagramas? Eis um segredinho da arquitetura: é muito fácil fingir ser um arquiteto!

Imagine um arquiteto folgado que lida com uma situação ou não tem tempo para projetar uma solução adequada para um sistema de trading de ações. Nesse caso, o diagrama da arquitetura pode lembrar o mostrado na Figura 22-4. Não há nada de errado nessa arquitetura, apenas que o nível é alto demais para ser usado por alguém.

Página 316

Figura 22-4. Arquitetura do sistema de trading criado por um arquiteto folgado Os arquitetos folgados criam poucos limites para as equipes de desenvolvimento, como visto na seção anterior. Nesse cenário, as equipes acabam assumindo o papel do arquiteto, basicamente fazendo o trabalho que ele deveria fazer. A velocidade e a produtividade da equipe têm problemas como resultado e as equipes ficam confusas sobre como o sistema deveria funcionar.

Como o arquiteto controlador, é muito fácil de tornar um arquiteto folgado. O maior indicador de que um arquiteto pode estar se enquadrando na personalidade do folgado é não ter tempo suficiente para passar com as equipes de desenvolvimento que implementam a arquitetura (ou escolher não passar um tempo com as equipes). Tais equipes precisam do suporte e da orientação do arquiteto, e precisam que ele esteja disponível para responder perguntas técnicas ou relacionadas ao negócio quando elas surgem. Outros indicadores de um arquiteto folgado são os seguintes:

Não entender totalmente o domínio corporativo, problema corporativo ou a tecnologia usada Não ter experiência prática suficiente no desenvolvimento de software Não considerar as implicações associadas à implementação da solução da arquitetura Em alguns casos, não é intenção de um arquiteto se tornar folgado, mas “acontece” ao se dividir muito entre projetos ou equipes de desenvolvimento, perdendo o contato com o domínio da tecnologia ou do negócio. Um arquiteto pode evitar essa personalidade se envolvendo mais na tecnologia sendo usada no projeto e entendendo o problema e o domínio do negócio.

Arquiteto Eficiente

Página 317

Figura 22-5. Arquiteto de software eficiente (iStockPhoto) Um arquiteto de software eficiente produz os limites e as restrições certos na equipe, assegurando que os membros trabalhem bem juntos e tenham o nível certo de orientação. O arquiteto eficiente também assegura que a equipe tenha as ferramentas e as tecnologias corretas e adequadas. E mais, eles removem qualquer obstáculo que possa estar no caminho das equipes de desenvolvimento para atingirem seus objetivos.

Embora pareça óbvio e fácil, não é. Existe certa arte em se tornar um líder eficiente na equipe de desenvolvimento. Ser um arquiteto de software eficiente requer trabalhar de perto e colaborar com a equipe, ganhando o respeito dela também. Veremos outros modos de se tornar tal arquiteto nos capítulos seguintes nesta parte do livro. Mas agora, apresentaremos algumas diretrizes para saber quanto controle um arquiteto de software eficiente deve exercer em uma equipe de desenvolvimento.

Quanto Controle?

Ser um arquiteto de software eficiente é saber quanto controle exercer em determinada equipe de desenvolvimento. Esse conceito é conhecido como Liderança Elástica e é largamente pregado pelo autor e consultor Roy Osherove. Desviaremos um pouco do trabalho que Osherove fez nessa área e focaremos os fatores específicos da arquitetura de software.

Saber o quanto um arquiteto de software eficiente deve ser controlador e folgado envolve cinco fatores principais. Esses fatores também determinam quantas equipes (ou projetos) um arquiteto de software pode gerenciar por vez:

Familiaridade na equipe O quanto os membros da equipe se conhecem bem? Eles trabalharam juntos antes em um projeto? Em geral, quanto melhor os membros se conhecem, menos controle é necessário porque eles começam se auto-organizando. Por outro lado, quanto mais

Página 318

novos os membros da equipe, mais controle é necessário para ajudar a facilitar a colaboração entre eles e reduzir as panelinhas na equipe.

Tamanho da equipe Qual o tamanho da equipe? (Consideramos mais de doze desenvolvedores na mesma equipe como sendo uma equipe grande, quatro ou menos como sendo pequena.) Quanto maior a equipe, mais controle é necessário. Quanto menor, menos controle. Isso é detalhado em “Sinais de Aviso da Equipe”.

Experiência geral Quantos membros da equipe são sênior? Quantos são júnior? É uma equipe mista de desenvolvedores júnior e sênior? O quanto eles conhecem a tecnologia e o domínio corporativo? Equipes com muitos desenvolvedores júnior requerem mais controle e mentoria, já as equipes com mais desenvolvedores sênior requerem menos controle. Nos últimos casos, o arquiteto passa do papel de mentor para ser um facilitador.

Complexidade do projeto O projeto é altamente complexo ou apenas um site simples? Os projetos altamente complexos requerem um arquiteto mais disponível para a equipe e para ajudar nos problemas que surgem, daí ser necessário mais controle na equipe. Os projetos relativamente simples são diretos e não requerem muito controle.

Duração do projeto O projeto é curto (dois meses), longo (dois anos) ou tem uma duração média (seis meses)? Quanto menor a duração, menos controle é necessário; por outro lado, quanto mais tempo leva o projeto, mais controle.

Embora a maioria dos fatores faça sentido em relação a mais ou menos controle, o fator de duração do projeto pode não parecer fazer sentido. Como indicado na lista anterior, quanto menor a duração do projeto, menos controle é necessário; quanto maior a duração, mais controle. Por intuição, isso pode parecer o oposto, mas não é o caso. Considere um projeto rápido de dois meses. Dois meses não é muito tempo para qualificar os requisitos, experimentar, desenvolver o código, testar todo cenário e liberar para produção. Nesse caso, o arquiteto deve agir mais como um folgado, pois a equipe de desenvolvimento já tem uma boa ideia da urgência. Um arquiteto controlador apenas atrapalharia e possivelmente atrasaria o projeto.

Por outro lado, considere um projeto com duração de dois anos. Nesse cenário, os desenvolvedores relaxam, não pensando na urgência, possivelmente planejando férias e longos almoços. Mais controle é necessário por parte do arquiteto para assegurar que o projeto avance no prazo e que as tarefas complexas sejam realizadas primeiro.

É normal, na maioria dos projetos, que esses fatores sejam utilizados para determinar o nível de controle no início; mas conforme o sistema se desenvolve, esse nível muda. Portanto, aconselhamos que esses fatores sejam analisados continuamente durante o ciclo de vida de um projeto para determinar quanto controle exercer na equipe de desenvolvimento.

Para mostrar como cada fator pode ser usado para determinar o nível de controle que um arquiteto deve ter sobre a equipe, imagine uma escala fixa de 20 pontos para cada fator. Os valores com menos pontuam mais para um arquiteto folgado (menos controle e envolvimento), já os valores com mais pontuam para um arquiteto controlador (mais controle e envolvimento).

Essa escala é mostrada na Figura 22-6.

Página 319

Figura 22-6. Escala para a quantidade de controle A aplicação dessa escala não é exata, claro, mas ajuda ao determinar o controle relativo para exercer em uma equipe. Por exemplo, considere o cenário do projeto mostrado na Tabela 22-1 e na Figura 22-7. Como visto na tabela, os fatores apontam para um controlador (+20) ou um folgado (-20). Esses fatores somam e têm uma pontuação -60 acumulada, indicando que o arquiteto deve atuar mais no papel de folgado e não atrapalhar a equipe.

Tabela 22-1. Cenário 1, exemplo da quantidade de controle Fator Valor Pontuação Personalidade Familiaridade na equipe Novos membros da equipe +20 Controlador Tamanho da equipe Pequeno (4 membros) -20 Arquiteto folgado Experiência geral Todos com experiência -20 Arquiteto folgado Complexidade do projeto Relativamente simples -20 Arquiteto folgado Duração do projeto 2 meses -20 Arquiteto folgado Pontuação acumulada -60 Arquiteto folgado Figura 22-7. Quantidade de controle para o cenário 1 No cenário 1, todos esses fatores são levados em conta para demonstrar que um arquiteto de software eficiente deve desempenhar o papel de facilitador no início e não se envolver demais nas interações diárias com a equipe. O arquiteto será necessário para responder perguntas e

Página 320

assegurar que a equipe fique nos trilhos, mas, em grande parte, não deve intervir e deve deixar a equipe experiente fazer o que faz de melhor, ou seja, desenvolver o software rápido.

Considere outro tipo de cenário descrito na Tabela 22-2 e mostrado na Figura 22-8, em que os membros da equipe se conhecem bem, mas a equipe é grande (doze membros) e consiste em grande parte em desenvolvedores júnior (sem experiência). O projeto é relativamente complexo, com uma duração de seis meses. Nesse caso, a pontuação acumulada é +20, indicando que o arquiteto eficiente deve se envolver nas atividades diárias na equipe e assumir o papel de mentor e coach, mas não a ponto de atrapalhar a equipe.

Tabela 22-2. Cenário 2, exemplo da quantidade de controle Fator Valor Pontuação Personalidade Familiaridade na equipe Se conhece bem -20 Arquiteto folgado Tamanho da equipe Grande (12 membros) +20 Controlador Experiência geral Em grande parte júnior +20 Controlador Complexidade do projeto Alta complexidade +20 Controlador Duração do projeto 6 meses -20 Arquiteto folgado Pontuação acumulada +20 Controlador Figura 22-8. Quantidade de controle do cenário 2 É difícil objetivar esses fatores, pois alguns (como experiência geral da equipe) podem ter mais peso que outros. Nesses casos, as métricas podem ser facilmente ponderadas ou modificadas para se ajustarem a determinado cenário ou condição. Não importa, a mensagem principal aqui é que a quantidade de controle e envolvimento que um arquiteto de software tem na equipe varia segundo esses cinco fatores principais e, levando isso em conta, um arquiteto consegue avaliar que tipo de controle exercer na equipe e a duração na qual as equipes de desenvolvimento podem trabalhar (muito limite e restrição ou pouco limite).

Sinais de Aviso da Equipe

Como indicado na seção anterior, o tamanho da equipe é um dos fatores que influenciam a quantidade de controle que um arquiteto deve exercer na equipe de desenvolvimento. Quanto maior a equipe, mais controle é necessário; quanto menor, menos controle. Três fatores entram em cena ao considerar o tamanho da equipe de desenvolvimento mais eficiente:

Página 321

Perda de processo Ignorância plural Difusão da responsabilidade Perda de processo, também conhecida como lei de Brooks, foi originalmente criada por Fred Brooks em seu livro O mítico homem-mês: Ensaios sobre engenharia de software (Alta Books).

A ideia básica da perda de processo é que quanto mais pessoas você adiciona a um projeto, mais tempo ele leva. Como mostrado na Figura 22-9, o potencial do grupo é definido pelos esforços coletivos de todos na equipe. Contudo, em qualquer equipe, a produtividade real sempre será menor que o potencial do grupo, com a diferença sendo a perda de processo da equipe.

Figura 22-9. O tamanho da equipe impacta a produtividade real (lei de Brooks) Um arquiteto de software eficiente observará a equipe de desenvolvimento e procurará a perda de processo. Essa perda é um bom fator ao determinar o tamanho certo da equipe para determinado projeto ou esforço. Uma indicação da perda de processo são os frequentes conflitos de merge ao enviar código para um repositório. Isso indica que os membros da equipe provavelmente estão batendo cabeça e trabalhando no mesmo código. Procurar áreas de paralelismo na equipe e fazer os membros trabalharem em serviços ou áreas separadas da aplicação é um modo de evitar a perda de processo. Sempre que um novo membro da equipe entrar em um projeto, se não houver áreas para criar fluxos de trabalho paralelos, um arquiteto eficiente perguntará por que um membro novo foi adicionado e demonstrará para o gerente do projeto o impacto negativo que mais uma pessoa terá na equipe.

Ignorância plural também ocorre quando a equipe fica muito grande. Essa ignorância é quando todos concordam (mas rejeitam em particular) uma norma porque acham que não estão vendo algo óbvio. Por exemplo, suponha que, em uma grande equipe, a maioria concorda que usar mensagens entre dois serviços remotos seja a melhor solução, enquanto uma pessoa acha que é uma ideia boba por causa de um firewall seguro entre os dois serviços. Em vez de falar, essa pessoa também concorda com o uso da mensagem porque tem medo de não ter visto algo óbvio ou possa ser vista como tola se falasse (mas, em particular, rejeita a ideia). Nesse caso, a pessoa que rejeita a norma estava certa, pois a mensagem não funcionaria devido a um firewall seguro entre dois serviços remotos. Se ela tivesse falado (e o tamanho da equipe fosse menor), a solução original teria sido questionada e outro protocolo (como REST) seria usado, o que seria uma solução melhor nessa situação.

Página 322

O conceito de ignorância plural ficou famoso com a história infantil dinamarquesa “A Roupa Nova do Rei”, de Hans Christian Andersen. Na história, o rei é convencido de que sua roupa nova é invisível para qualquer um indigno de realmente vê-la. Ele desfila pelo lugar totalmente nu, perguntando a todos os seus súditos se gostam de suas roupas novas. Todos eles, com medo de serem considerados estúpidos ou indignos, respondem que as roupas novas são as melhores.

Essa estupidez continua até uma criança finalmente gritar para o rei que ele não estava usando nada.

Um arquiteto de software eficiente deve observar continuamente as expressões faciais e a linguagem corporal durante uma reunião de colaboração ou discussão e agir como facilitador se perceber a ignorância plural. Nesse caso, o arquiteto pode interromper e perguntar à pessoa o que ela pensa sobre a solução proposta e ficar do lado dela, apoiando-a quando falar.

O terceiro fator que indica o tamanho certo da equipe se chama difusão da responsabilidade.

Ela se baseia no fato de que, conforme o tamanho da equipe aumenta, isso afeta a comunicação negativamente. Confusão sobre quem é responsável pelo quê na equipe e coisas sendo largadas são bons sinais de uma equipe grande demais.

Veja a imagem na Figura 22-10. O que você observa?

Figura 22-10. Difusão da responsabilidade A imagem mostra uma pessoa ao lado de um carro quebrado no acostamento de uma pequena estrada rural. Nesse cenário, quantas pessoas poderiam parar e perguntar ao motorista se está tudo bem? Como é uma estrada pequena em uma comunidade pequena, é possível que muitas pessoas passem. Porém, quantas vezes motoristas ficam parados no acostamento de uma grande rodovia em uma grande cidade, com milhares de carros simplesmente passando sem ninguém parar e perguntar se tudo está bem? Sempre. Esse é um bom exemplo de difusão da responsabilidade. Conforme as cidades ficam mais movimentadas e cheias, as pessoas pressupõem que o motorista já ligou ou que a ajuda está a caminho devido ao grande número de pessoas vendo o evento. Mas, na maioria dos casos, a ajuda não está a caminho, e o motorista fica parado com um celular descarregado ou por tê-lo esquecido, incapaz de ligar e pedir ajuda.

Página 323

Um arquiteto eficiente não só ajuda a orientar a equipe de desenvolvimento na implementação da arquitetura, como também assegura que ela seja saudável, feliz e trabalhe junto para atingir uma meta em comum. Procurar esses três sinais de aviso e, por consequência, auxiliar na correção deles ajuda a garantir uma equipe de desenvolvimento eficiente.

Utilizando Checklists

Pilotos de avião usam checklists em cada voo, mesmo que sejam mais experientes e veteranos.

Eles têm checklists para a decolagem, para o pouso e para milhares de outras situações, sendo casos extremos comuns ou não. Eles usam checklists porque uma configuração (como colocar os flaps a 10º) ou um procedimento (como obter autorização em uma área de controle do terminal) faltante da aeronave pode significar a diferença entre um voo seguro e um desastre.

O Dr. Atul Gawande escreveu um excelente livro chamado Checklist — Como fazer as coisas benfeitas (Sextante), no qual ele descreve o poder das checklists para procedimentos cirúrgicos.

Alarmado com a alta taxa de infecções por estafilococos nos hospitais, o Dr. Gawande criou checklists cirúrgicas para tentar reduzi-la. No livro, ele demonstra que as taxas dessa infecção nos hospitais que usam checklists caíram para quase zero, enquanto as taxas nos hospitais de controle que não as utilizam continuaram a crescer.

As checklists funcionam. Elas são um excelente veículo para assegurar que tudo seja coberto e cuidado. Se elas funcionam tão bem, por que o setor de desenvolvimento de software não as utiliza? Acreditamos muito, segundo nossa experiência pessoal, que as checklists fazem uma grande diferença na eficiência das equipes de desenvolvimento. Contudo, há problemas nessa afirmação. Primeiro a maioria dos desenvolvedores de software não pilota aviões nem faz cirurgias cardíacas abertas, ou seja, eles não precisam de checklists para tudo. O segredo para tornar as equipes eficientes é saber quando utilizar checklists ou não.

Considere a checklist na Figura 22-11 para criar uma nova tabela do banco de dados.

Figura 22-11. Exemplo de checklist ruim Isso não é uma checklist, mas um conjunto de etapas procedurais e, como tal, não deve estar em uma checklist. Por exemplo, a tabela do banco de dados não deve ser verificada se o formulário não foi enviado ainda! Qualquer processo que tenha um fluxo procedural de tarefas dependentes não deve estar em uma checklist. Processos simples e muito conhecidos que são executados com frequência sem erro também não precisam de uma checklist.

Os processos que são bons candidatos para as checklist são os que não têm nenhuma ordem procedural nem tarefas dependentes, assim como os que tendem a ter erros ou etapas muitas

Página 324

vezes esquecidas ou ignoradas. O segredo para criar checklists eficientes é não exagerar tornando tudo uma checklist. Os arquitetos acham que as checklists, de fato, tornam as equipes de desenvolvimento mais eficientes e, assim, começam a tornar tudo uma checklist, o que é conhecido como lei dos rendimentos decrescentes. Quanto mais checklists um arquiteto cria, menos chance de os desenvolvedores usá-las. Outro segredo do sucesso ao criar checklists é que elas sejam o mais curtas possível, ainda incluindo todas as etapas necessárias em um processo.

Em geral, os desenvolvedores não seguirão as checklists muito grandes. Procure os itens que podem ser realizados com automação e remova-os da checklist.

Não se preocupe em declarar o óbvio em uma checklist. É o óbvio que normalmente é ignorado ou esquecido.

Três checklists importantes que achamos mais eficientes são completude de código do desenvolvedor, testes unitários e funcionais e entregas do software. Cada checklist é examinada nas próximas seções.

Efeito Hawthorne Uma das questões associadas à introdução de checklists em uma equipe de desenvolvimento é fazer os desenvolvedores realmente usarem-nas. É muito comum que alguns fiquem sem tempo e simplesmente marquem todos os itens em certa checklist como concluídos sem realmente ter realizado as tarefas.

Um dos modos de lidar com isso é conversando com a equipe sobre a importância de usar as checklists e como elas podem fazer uma diferença na equipe. Peça que os membros da equipe leiam o livro Checklist — Como fazer as coisas benfeitas, de Atul Gawande, para entenderem bem o poder de uma checklist e verifique se cada membro entende o raciocínio por trás de cada checklist e por que está sendo usada. Fazer os desenvolvedores colaborarem no que deve ou não estar na checklist também ajuda.

Quando tudo mais falha, os arquitetos podem chamar o que é conhecido como Efeito Hawthorne. Esse efeito significa basicamente que se as pessoas sabem que estão sendo observadas ou monitoradas, o comportamento delas muda e normalmente farão a coisa certa. Exemplos incluem câmeras bem visíveis nos prédios que realmente não funcionam nem estão de fato gravando nada (é muito comum!) e um software de monitoramento de site (quantos desses relatórios são de fato vistos?).

O Efeito Hawthorne pode ser usado para reger o uso das checklists também. Um arquiteto pode informar à equipe que usar checklists é essencial para a eficiência dela e, como resultado, todas as checklists serão verificadas para garantir que a tarefa foi realmente feita, quando, na verdade, o arquiteto faz uma verificação pontual e ocasional das checklists quanto à correção. Utilizando esse efeito, é muito menos provável que os desenvolvedores pulem os itens ou os marquem como concluídos quando, na verdade, a tarefa não foi feita.

Checklist da Completude de código do desenvolvedor

Essa checklist é uma ferramenta eficiente de se usar, em particular quando um desenvolvedor de software declara que “finalizou” o código. Também é útil para definir o que é conhecido como “definição de feito”. Se tudo na checklist está concluído, então o desenvolvedor pode declarar que realmente finalizou o código.

Página 325

Coisas a incluir na checklist da completude de código do desenvolvedor:

Codificar e formatar padrões não incluídos nas ferramentas automáticas Itens esquecidos com frequência (como exceções absorvidas) Padrões específicos do projeto Instruções ou procedimentos especiais da equipe A Figura 22-12 mostra um exemplo de checklist da completude de código do desenvolvedor.

Figura 22-12. Exemplo de uma checklist da completude de código do desenvolvedor Note as tarefas óbvias “Executar limpeza e formatação do código” e “Verificar se não há exceções absorvidas” na checklist. Quantas vezes um desenvolvedor teve pressa no final do dia ou no final de uma iteração e esqueceu de executar a limpeza ou a formatação do código no IDE? Muitas. No livro Checklist — Como fazer as coisas benfeitas, Gawande descobriu esse mesmo fenômeno em relação aos procedimentos cirúrgicos; os óbvios muitas vezes eram sempre os esquecidos.

Note também as tarefas específicas do projeto nos itens 2, 3, 6 e 7. Embora sejam bons itens em uma checklist, um arquiteto sempre deve examiná-la para saber se algum item pode ser automatizado ou escrito como um plug-in para um verificador de validação de código. Por exemplo, embora “Incluir @ServiceEntrypoint na classe de serviço API” possa não ter uma verificação automática, certamente “Verificar se apenas métodos públicos chamam setFailure()”

pode (é uma verificação automática simples com qualquer ferramenta de rastreamento de código). Verificar áreas de automação ajuda a reduzir o tamanho e o ruído em uma checklist, tornando-a mais eficiente.

Checklist dos Testes Unitários e Funcionais

Talvez uma das mais eficientes seja a checklist dos testes unitários e funcionais. Ela contém alguns testes de caso extremos e mais incomuns que os desenvolvedores de software tendem a esquecer de testar. Sempre que alguém do QA encontra um problema no código com base em certo caso de teste, o caso deve ser adicionado a essa checklist.

Normalmente essa checklist em particular é uma das maiores devido a todos os testes que podem ser executados no código. A finalidade dela é garantir o código mais completo possível

Página 326

para que quando o desenvolvedor terminar com a checklist, o código esteja basicamente pronto para a produção.

Alguns itens encontrados em uma checklist de testes unitários e funcionais:

Caracteres especiais no texto e nos campos numéricos Intervalos mínimo e máximo de valores Casos de teste incomuns e extremos Campos que faltam Como a checklist da completude de código do desenvolvedor, qualquer item que possa ser escrito como teste automático deve ser removido da checklist. Por exemplo, suponha que haja um item na checklist para a aplicação de trading de ações para testar ações negativas (como BUY para –1.000 ações da Apple [AAPL]). Se essa verificação for automatizada em um teste unitário ou funcional no conjunto de testes, então o item deverá ser removido da checklist.

Por vezes, os desenvolvedores não sabem por onde começar ao escrever testes unitários ou quantos deles escrever. Essa checklist fornece um modo de assegurar que cenários de teste gerais ou específicos sejam incluídos no processo de desenvolvimento do software. Essa checklist também é eficiente ao fechar a lacuna entre desenvolvedores e verificadores em ambientes que têm essas atividades realizadas por equipes separadas. Quanto mais as equipes de desenvolvimento fazem um teste de conclusão, mais fácil é o trabalho das equipes de teste, permitindo que elas foquem em certos cenários corporativos não cobertos nas checklists.

Checklist de Release do Software

Lançar versão de software para produção talvez seja um dos aspectos mais sujeitos a erros do ciclo de vida de desenvolvimento do software e, assim, contribuem para uma ótima checklist.

Isso evita compilações e implementações com falhas, reduzindo muito a quantidade de risco associada ao liberar um software.

A checklist de release do software costuma ser a mais volátil das checklists no sentido de que muda continuamente para lidar com novos erros e circunstâncias sempre que uma implementação falha ou tem problemas.

Alguns itens normalmente incluídos na checklist de release do software:

Mudanças de configuração nos servidores ou nos servidores de configuração externos Bibliotecas de terceiros adicionadas ao projeto (JAR, DLL etc.) Atualizações do banco de dados e scripts de migração do banco de dados correspondentes Sempre que uma compilação ou uma implementação falha, o arquiteto deve analisar a causaraiz e adicionar uma entrada correspondente à checklist de release. Assim, o item será verificado na próxima compilação ou implementação, evitando que o problema ocorra de novo.

Dando Orientação

Página 327

Um arquiteto de software também pode tornar as equipes eficientes dando orientação no uso dos princípios de design de projeto. Isso também ajuda a dar limites (restrições), como descrito na primeira seção deste capítulo, nos quais os desenvolvedores podem trabalhar para implementar a arquitetura. Uma comunicação eficiente desses princípios é um dos segredos para criar uma equipe de sucesso.

Para ilustrar, considere dar orientação a uma equipe de desenvolvimento quanto ao uso do que costuma ser chamado de pilha em camadas — a coleção de bibliotecas de terceiros (como arquivos JAR e DLLs) que compõem a aplicação. Em geral as equipes de desenvolvimento têm muitas perguntas relacionadas à pilha em camadas, inclusive se podem tomar suas próprias decisões sobre várias bibliotecas e quais são boas ou não.

Usando esse exemplo, um arquiteto de software eficiente pode dar orientação à equipe de desenvolvimento primeiro fazendo o desenvolvedor responder às seguintes perguntas:

1. 1. Há sobreposições entre a biblioteca proposta e a funcionalidade existente no sistema?
2. 2. O que justifica a biblioteca proposta?

A primeira pergunta orienta os desenvolvedores a analisarem as bibliotecas existentes para saber se a funcionalidade fornecida pela nova biblioteca pode ser atendida com uma biblioteca ou uma funcionalidade existente. Nossa experiência diz que, às vezes, os desenvolvedores ignoram essa atividade, criando muita funcionalidade duplicada, sobretudo em grandes projetos com grandes equipes.

A segunda pergunta leva o desenvolvedor a questionar por que a nova biblioteca ou funcionalidade é de fato necessária. Aqui, um arquiteto eficiente pedirá uma justificativa técnica e uma corporativa para o motivo de a biblioteca extra ser necessária. Pode ser uma técnica poderosa para conscientizar a equipe de desenvolvimento quanto a necessidade de justificativas comerciais.

O Impacto das Justificativas Comerciais Um dos autores (Mark) era o arquiteto responsável em um projeto baseado em Java bem complexo com uma grande equipe de desenvolvimento. Um dos membros da equipe estava particularmente obcecado pela linguagem de programação Scala e queria muito usá-la no projeto. O desejo de usar o Scala acabou atrapalhando tanto que vários membros da equipe principal informaram a Mark que eles planejavam sair do projeto e ir para outro ambiente “menos tóxico”. Mark convenceu dois membros importantes a adiarem sua decisão um pouco e conversarem com o entusiasmado pelo Scala. Mark disse ao entusiasta que ele daria suporte ao uso do Scala no projeto, mas a pessoa teria que dar uma justificativa corporativo para o uso por causa dos custos de treinamento e esforço de reescrita envolvidos.

O entusiasma ficou em êxtase e disse que seria para já, saindo da reunião dizendo: “Obrigado, você é o melhor!”

No dia seguinte o cara do Scala entrou no escritório totalmente transformado. Ele logo se aproximou de Mark e pediu para falar com ele. Ambos foram para a sala de reunião e o entusiasta disse de imediato (e com humildade):

“Obrigado.” Ele explicou para Mark que poderia propor todos os motivos técnicos no mundo para usar o Scala, mas nenhuma vantagem técnica tinha valor corporativo em termos das características da arquitetura necessárias (atributos):

custo, orçamento e prazo. Na verdade, o entusiasta percebeu que o aumento em custo, orçamento e prazo não traria nenhum benefício.

Percebendo o quanto estava atrapalhando, o entusiasta rapidamente se transformou em um dos melhores e mais úteis membros na equipe, tudo porque lhe pediram para dar uma justificativa corporativa para algo que ele queria no projeto.

Essa consciência aumentada das justificativas não só o tornou um desenvolvedor de software melhor, como também contribuiu para uma equipe mais forte e saudável.

PS: os dois desenvolvedores ficaram no projeto até o fim.