Documentar ou não documentar? Eis a questão!

Boa tarde muito boa tarde que bom tá aqui falando de novo com você meu amigo Gabriel corros aliás boa tarde mais ou menos né cara já é quase fim do dia hoje dia de gravação dia 15 de Dezembro 17 horas então ainda é boa tarde para gente tudo bom meu amigo como é que você tá tudo ótimo melhor agora estando em vossa companhia olha só tá eu aqui o Gabriel Coach para falar sobre um tema tremendamente importante né polêmico Um tantinho polêmico não controverso né a gente vê um bocado de pessoas falando a favor e

falando contra documentação em arquitetura de software né o bocado de gente levantando vós contra um bocado de gente levantando vozes favor E aí meu amigo Gabriel corde fica a pergunta direta né para responder com uma palavra só você é favorável ou contrário a documentação em arquitetura de software vamos lá vale o nosso depende mas nós somaria eu acredito que eu sou favorável é o que a gente sempre vem conversando nas internas né documentação qualquer tipo de documentação seja de em relação à arquitetura ou seja em qualquer parte do processo de engenharia de software tem custo

a questão é como que nós conseguimos chegar num custo que seja adequado e que faça sentido no contexto da das empresas Ou de quem está aplicando em si o que eu acho arriscado é a gente desconsiderar seja por onde comentou por controversa ou até mesmo por achar que estamos sendo ágeis e não vamos documentar e isso eu acho perigoso a gente ir mais para o zero do que o lado contrário de ter mais documentação ou até mesmo mais documentação não quer dizer melhor documentação mas não ter documentação acho que é o perigo e isso é

muito perigoso para as empresas hoje a gente muito do que a gente vê no nosso dia a dia do que a gente vem acompanhando com os clientes o fruto de erosão arquitetural o fruto dos problemas vem de uma falha de documentação vamos vamos consolidar aqui vamos ver se eu entendi você tá trazendo para mim e essa é a posição inclusive que a gente defende junto aos clientes que Poxa Olha só processo de documentação não só para arquitetura de software mas para qualquer coisa dentro da engenharia né documentação tem custo tem um custo associado então eventualmente

você não pode ignorar esse custo na hora de pensar no processo como um todo né ou no ciclo como um todo de se manter software né você quer Minimizar esse custo de alguma forma por outro lado né evitar completamente esse custo não produzir documentação nenhuma parece não ser também uma boa alternativa porque você tá trazendo para gente né que nós temos aí o caso da erosão arterial erosão cultural inclusive é importante né quando você acaba perdendo né arquitetura acaba se perdendo ao longo do tempo por causa de uma série de eventualmente decisões infeliz enfim não

ter documentação também é agora existe um uma referência né Gabriel que a gente costuma estar com frequência de qual é esse ponto certo né e eu costumo dizer que a gente defende muito isso custa isso também que documentação faz sentido quando a documentação mais código custa mais barato do que só código parece ser parece ser algo difícil de medir Mas se a gente começa a fazer uma retrospectiva de processo começa a olhar um pouquinho mais lá dentro faz todo sentido Porque da mesma forma eventualmente assim o dia a dia vai vai comer estratégia eu digo

senti o dia a dia como em qualquer processo ou qualquer boa prática de engenharia ou de arquitetura então a gente pode iniciar com boas práticas um time pode iniciar com boas práticas Mas vai chegar o dia a dia vai chegar a pressão de entregas o time de negócio cobrando adlines e janelas de oportunidade passando e a gente acaba ignorando essa essa questão de documentação e acaba muitas ignorando essa medida de documentação mas código tem que ser mais barato que só código e a gente vai indo só mais para o lado do código E aí começa

a ficar difícil de justificar para o time de negócio porque que é tão difícil ou Porque que o nosso se ficou time o Lead time tá aumentando ao invés de diminuir o porquê que a gente tá demorando mais para entregar software Olha só se tá botando mais um elemento interessante para mim seguinte olha ele é sistemas o software com pouca documentação sofre com pouca documentação arquitetural aliás é importante que a gente deixa bem claro e isso separar os tipos de documentação né a gente não tá falando aqui especificamente documentação para usuário final nem explicação das

vítimas a gente tá falando sobre documentação arquitetural ou seja não presença da documentação eleitoral acaba impactando para o aumento você tá trazendo para a gente aqui o tempo para você o tempo que eu preciso colocar atender um negócio vai aumentando ao longo do tempo caso se tome a decisão ingênua né de se fazer software ignorando aí a necessidade de documentação porque poxa vou fazer um código mais rápido agora um ponto interessante né Gabriel aqui você fala a gente falou que sobre documentação arquitetural né que ajuda a salvar tempo então vamos lá Se você fosse classificar

para mim o que seria documentação eleitoral mas não a partir de uma definição Mas a partir de exemplos por aqui para a gente né é como que se classificaria o que é documentação Eleitoral de uma forma bem prática eu vejo duas linhas principais hoje pelo menos assim que que todas as empresas deveriam ter em algum nível tá uma primeira é Todo Mundo Em algum momento precisou fazer um board de alguém do time e neste momento tenho certeza que alguém foi lá no quadro branco ou foi em alguma ferramenta de desenho agora colaborativa em tempos de

todo mundo virtual e teve que redesenhar todo a arquitetura teve que desenhar os estilos eu tenho que fazer algum desenho de como um sistema é para alguém que tá entrando ou até mesmo que como o famoso exatamente o famoso esquemão e e mais e além disso acaba que nesses Zombies ou até mesmo assim ó que comunicação é repetição então tendo que fazer um treinamento contínuo alguma coisa acaba tendo que tocar em alguns assuntos que muitas vezes a gente vê que não estão não estão explícitos que é falar sobre o que que a empresa faz que

seria um objetivo de negócio O que que o time eventualmente não pode fazer restrições e o que que aquele sistema ou Quais as formas que a gente vê qualidade naquele sistema atributo de qualidade então isso eu vejo que inevitavelmente de uma de uma forma um pouco mais intenso menos intensa acaba sendo feito então documentação arquitetural uma uma forma de ver a gente tem algum documento a gente ter algumas práticas de arquitetura que vão deixar isso de forma explícita Então vamos lá eram dois tipos Tá mas só para ver se a gente está acompanhando e conseguindo

achar coisa bem clara para todo mundo também ver se nós também estamos alinhados cara está falando com muita saúde cultural Poxa eu preciso explicar como sistema funciona e geralmente você pode sumir que poxa o código é a fonte da Verdade Olha o código que você entende mas quando você tá falando com o sistema com muitos anos com muita gente quando não com centenas de milhares quem sabe até milhões de linhas cara tentar recorrer o código para poder entender do sistema faz é uma insanidade não faz sentido Então você cria uma simplificação é que é o

esquimão que a gente falou e que é desenhado no quadro de novo outra vez outra coisa que você trouxe para mim que é tremendamente interessante É tem coisas que você não consegue deixar explícitas mesmo no código que são eventuais motivações para como o código está escrito por exemplo a minha ênfase em atributos de qualidade e aí para atributos de qualidade posso estar falando de segurança postando desempenho eu posso falar sobre um bocado de coisa então qual foi Quais foram os pontos que motivaram aquele código a ser escrito daquela forma né isso raramente tá lá a

menos que seja por comentário aí a gente vai para outro problema comentar não é exatamente uma boa fonte de documentação não deveria ser vista como a única e cara você tem também como você disse restrições né Tipo ele atualmente você acaba fazendo dando forma para um sistema é arquitetura como decisões de design transformam o sistema eventualmente também você tem que tomar decisões que vão fazer com que o teu sistema se comporte de da mesma forma que você tem que obedecer uma restrição por exemplo lá não posso usar nuvem ou eu tenho que usar nuvem eu

tenho que usar essa nuvem enfim mas ou menos para aí certo então essa primeira parte esse esquemão aqui exatamente a gente tentar deixar mais claro explícito o propósito daquele sistema o propósito da arquitetura daquele sistema que a gente está fazendo não necessariamente com um grau muito elevado de de especificação de tentar detalhar mas pelo menos que a gente consiga em um alto nível conseguir dar um senso de propósito para utilizar a gente está desenvolvendo esse sistema ele é baseado em esse estilo arquitetural ele respeita algumas premissas aqui de qualidade respeito algumas restrições e ele atende

esses objetivos de negócio mas aí é interessante cara quando você fala sobre Essa visão de documentação né você fala que Poxa você vai ao quadro até para poder revisitar discussão e você acaba explicando porque você tem um bomboard novos sabedores enfim você acaba fazendo esse desenho com alguma frequência Isso me lembra também aquelas reuniões né Gabriel em que você escreve no quadro não apague né ou antes de sair alguém tira foto e manda por e-mail alguém Tira uma foto né E esse desenho acaba sendo feito várias vezes então você tá dizendo para mim que essa

documentação ela acaba sendo gerada no dia a dia né ou que não se faz eventualmente é achar uma forma diferente já armazenar ela né Tipo fica numa foto difícil de digitar nas mãos de alguém ou que ninguém lembra que tirou mais aquela foto e acaba sempre refazendo os desenhos as explicações novamente porque aquela foto tá no e-mail Ninguém Vai consultar o e-mail e acaba se perdendo com o tempo essa essa foto né Essa visão geral como você tá dizendo cara geralmente enche um quadro branco né então um espaço é não muito mais do que isso

né não parece ser tanta coisa assim né Gabriel e isso lembra também bastante aquilo que o nosso o nosso esqueci o nome do consultor cara mas enfim tem aquele livro muito bom que é risco né o autor do livro lá sugere que você deve ter um Rigor para arquitetura adequado mais ou menos é o tamanho do Risco envolvido com o projeto né e ele usa uma abordagem que é o haicai né que essa ideia com essa visão exatamente então tem vários templates de Haicai aí online github o que nós normalmente temos feito com os times

porque é uma prática um tanto no dia a dia é uma prática tanto quanto nova para os times de fazer esse tipo de documentação nós acabamos trazendo por exemplo a página inicial de um projeto de um repositório de um sistema Inicial pode ser o haicai que já traz essas informações de forma sucinta no haicai diz que é uma folha de A4 né mas no mundo digital é a gente tentar condensar isso de uma forma seja a gente consiga ler isso rapidamente então nós temos acabado fazendo isso no inicial dos projetos eventualmente a gente que acaba

trazendo alguns diagramas de alto nível principalmente conotação mais informar os anos C4 Model trazendo mais a visão de de System contact não necessariamente entrando em container ou componente mas uma visão mais alto nível para tentar deixar mais claros integrações que normalmente é uma dor de cabeça então abrindo aquele esse Haikai abrindo a página principal do projeto a gente já tem de cara a gente já sabe Para que por que que o sistema foi pensado objetivos de negócio se a gente tem alguma restrição a ser respeitada quais atributos de qualidade são importantes para aquele sistema Então

eu tenho que eu tenho que dar mais importância a segurança ou desempenho e isso pode parecer e é legal a gente falar disso porque para os times às vezes parece parece ser bobagem esse pequeno detalhe nada mas eu dou mais ênfase para segurança o desempenho mas isso claro que teto para a gente pensar em decisões do dia a dia tem um gigante porque provavelmente a gente está falando de trade offs aqui eu não vou conseguir ter um sistema com alto desempenho se eu priorizo segurança Esse é um ponto Esse é um ponto um ponto importante

tá não necessariamente desempenho mas se você pensar por exemplo indisponibilidade disponibilidade que eu vou ter mais componentes eu tenho mais superfície de ataque então tipo de um lado você aumenta a super tipo para ela aumentar disponibilidade e tem que comentar a quantidade de elementos computacionais vou colocar réplicas né e na medida que você realmente coloca réplicas aumenta a superfície ataque que dá aumenta a dor de cabeça para quem trabalha com segurança a gente brinca né achar o longo dessa experiência que cara você fazer arquitetura de software a prática da arquitetura software é a arte de

você resolver tua endófise né Sempre tá abrindo mão de alguma coisa aliás eu falei sobre isso outro dia você tem um time técnico que não tem condições de determinar claramente Qual é o prejuízo que tá acontecendo o que tá aceitando a partir de uma decisão é porque essa pessoa provavelmente não tá preparada para tomar aquela decisão né porque ele acaba trazendo para a gente um modelo né é uma proposta a princípio de documentação intestral mínima aonde você enumera lá objetivo de negócio Quais são as principais restrições Quais são os principais atributos de qualidade que para

quem não tá tão habituado também com trabalho de arquitetura são as informações que mais vão direcionar aí as decisões são tomadas E aí você tá trazendo para a gente alguma coisinha mais tipo cara eu preciso entender que que é esse sistema de uma opção mais Ampla né grandes componentes eventualmente né se você quiser ou como você destacou aqui no C4 ah os grandes containers né tipo banco de dados eventualmente Você tem alguma coisa e aí você fala de um outro ponto importante que são mais integrações essa é uma coisa legal cara sobre que a gente

acompanha direto quando a gente encontra empresas com dificuldade né é com muita frequência são feitas modificações muito profundas do sistemas às vezes para poder suportar uma nova demanda escala e cara as integrações param de funcionar simplesmente porque se esquece né exatamente e a gente tem buscado muito isso de tentar deixar mais mais explícito essas integrações e o impacto que tem e isso é um ponto também muito importante lembrar que o haicai ele não ele não deveria eu vou usar agora a dizer que ele não deveria ser um documento técnico ele não deveria ser um documento

para o time de engenharia Ele deveria ser um documento aonde que o time de engenharia assim consegue ler mas também o time de negócio porque ali nós estamos buscando também um grande alinhamento com a área de negócio porque ali a gente tem que deixar não todos os acordos mas pelo menos os principais acordos com o time de negócio deveriam estar ali a gente deveria estar nesse documento do Haicai ou em alguma alguma quebra algum desdobramento do Haicai de dizer por exemplo que se a gente tá falando de performance o que que é performance para o

time de negócio ou Qual a expectativa do time de negócio quantos usuários simultâneos a gente tem expectativa de exportar nessa arquitetura e depois de pronto também deixar claro que a gente suporta isso ou o máximo de usuários simultâneos que a gente suporta é tanto porque a gente tem alimento de expectativa porque depois senão fica muito fácil dizer não mas não atendeu entregou não tá atendendo o que eu precisava fica fácil e aí a gente começa bem defende né o nós e eles aí a guerra entre nós e eles começam a ficar muito fácil de se

declarar é assim quando você fala e aí tentando trazer coisa para para uma luz né quando você fala que isso não é um documento necessariamente técnico você tá trazendo a indicação de que poxa é um documento produzido por pessoas técnicas Provavelmente sim né pelo arquitetura para quem tá conduzindo a atividade de arquitetura mais que deveria ser possível de consumir por pessoas não técnicas né E aí você fala sobre pontos importantíssimos aqui e eu acho que é importante destacar né muitas vezes as pessoas falam de forma muito superficial disponibilidade sobre segurança sobre desempenho sobre uma série

de atributos de qualidade mas falam de tudo isso de uma maneira muito muito superficial muito Rasa Ah meu sistema tem que estar disponível mas tem disponível quanto né ele tem que ter disponível para quantos usuários tem que estar disponível para não pega Vamos pegar esse exemplo Ah não ele tem que estar disponível quanto e se eu não tenho por exemplo uma relação ou não tem muito claro as minhas integrações a minha disponibilidade é calculada pela interação do meu sistema se elas são por exemplo simples Eu tenho um sistema que depende que eu dependo e esse

sistema tá fora do ar o meu sistema tá fora do ar Esse é um ponto importante ou seja o hábito né o simples fato de você produzir alguma documentação e colocar essa documentação alguma coisa que seja relevante tentando eliminar subjetividade né fazer mais do que encher porque esse ponto importante se você fazer um documento cara lembra que tem documentações que a gente tem encontrado por aí Vale menos do que os bits iguais que consomem né então tipo Digamos que aquela documentação que é ela é muito mais burocrática ela é muito mais para cobrir algum risco

do que realmente para comunicação a documentação ela serve para comunicar para os outros e comunicar as nossas versões do Futuro né porque eu não sei você né Gabriel mas eu por exemplo como sei hoje Então como que eu vou saber no futuro quais eram os acordos que eu estabeleci outro ponto importante né Gabriel que a gente aprende com a experiência existem muito jeito certo de se resolver um problema e tudo depende das demandas que você tem né Tipo você preparar um sistema eu brinco que tinha um colega meu no passado que falava escandalizado sobre o

valor que o Instagram né foi comprar pelo facebook ele falou escanearizado sobre um programa ele destacando que aplica filtros numas fotinhos né Não é questão de ser um programinha que aplicar as fatias a questão é olha a quantidade de usuários que esse programinha precisa de sim tem que suportar a esca destrói tudo né então só que assim você fazer no momento zero problema a partir de uma de uma demanda pequena é tipo você fazer uma super arquitetura Você tá jogando dinheiro fora né em compensação E aí a gente entra por exemplo né que eventualmente daqui

a pouco estão fazendo uma super arquitetura pensando no futuro e o princípio o principal que era validar uma hipótese de negócio foi deixada de lado e aí você o que mais se encontra hoje em dia né são e esse eu acho que é o grande ponto da disciplina de arquitetura né você encontra muita gente fazendo a implementação da melhor solução possível para um cenário completamente fictício que não é o cenário de negócio que você tem que resolver então que você traz pra gente só para a gente consolidar que essa primeira documentação cara eu preciso ter

uma visão Ampla do sistema então o que que vai ter no haicai uma relação das três principais funcionalidade que se espera que esse sistema tenha você vai ter lá uma relação dos principais objetivos negócios atingidos de uma maneira quantificada né para você poder entender um pouco melhor o que você tem que entender você também tem ali uma relação dos atributos de qualidade de uma maneira geral priorizada né tipo com uma sequência de priorização você tem as principais restrições e eventualmente você vai ter algum desenho né De preferência utilizando uma linguagem um pouco mais formal né

do que simplesmente fiquei rabiscos que a gente faz no quadro porque esse outro problema né Gabriel muitas vezes as pessoas evitam linguagens como C4 como ML é porque elas parecem ser burocráticas demais quando na verdade que elas trazem para a gente é um Rigor que permite porque o ele é mais de manhã entendo que aquele desenho que quer dizer né Exatamente porque não vamos lá vamos chegar pertinho botar a cabeça pertinho do ventilador fazer um desenho pegar um PowerPoint fazer um desenho de caixinhas referenciando outras caixinhas naquele momento que a gente tá fazendo desenho faz

sentido a gente consegue explicar os porquês mas eu aposto que alguns dias a gente não sabe mas para aí o que que é eu tô chamando eu tô mandando mensagem eu tô e uma anotação um pouco mais formal um C4 já traz um Rigor que comenta para evitar esse tipo de ambiguidade no desenho ele tá explicitando algumas coisas então é fundamental se se a documentação eu penso o seguinte sabe se a documentação o principal da documentação é comunicar se a minha documentação não tá conseguindo comunicar e não é no momento pensando também no futuro nosso

eu do futuro se ela não consegue fazer isso então a documentação e a parte que ela já não tá muito bem ela não tá muito bem feita ela não é útil eu acho que ele era um problema né porque você tá fazendo ambiguidade se você faz uma documentação que permite ambiguidade e assim vamos lá né É sempre é sempre no mesmo Exemplo né tirei uma pedra na janela e ela quebrou Quem Quebrou a pedra na janela sabe tipo você lei que potencialmente se você tira uma pedra na janela e ela quebrou você assume que a

parte sensível é a janela e a janela quebrou mas nem sempre esse é o fato não pode ter certeza disso né então você pior do que você não ter documentação daqui a pouco até uma documentação que te leva acreditar a coisa errada exatamente E aí entra no [Música] documentando a arquitetura de software que eles falam né que tu ter uma documentação que daqui a pouco leva a o time de engenharia implementar de forma equivocada aquilo que foi planejado é pior do que não ter então então assim vamos lá a gente tá concluindo aqui o seguinte

bom primeira coisa que eu preciso eu preciso ter uma documentação todo mundo já faz só que eu preciso adquirir o hábito de formalizar um pouquinho estruturado armazenar de uma forma mais mais organizada a base da arquitetura que são os elementos que a gente viu aqui que escreve um haicai você deu um excelente alternativa também que a gente tá vendo sim ser utilizado em muitos projetos em empresas que existem empresas com maior ênfase em agilidade quer trazer essa documentação então para o arquivo de rosto né o md o readmhotmail da vida para você ter ali no

Market Down daqui a pouco uma descrição alta do que que vem a ser essa informação o ponto interessante também é que quando você faz isso você ganha automaticamente Às vezes o relacionamento dessa comunicação né E você começa a associar principalmente a medida que o projeto vai evoluindo quando alguma grande mudança acontece você sabe exatamente a partir de qual versão essa grande mudança aconteceu exato e começa ficar também um pouco mais explícito questão de Hold map arquitetural o como estamos hoje e para onde estamos indo Esse é um ponto interessante né porque a arquitetura não fala

somente sobre arquitetura no momento atual né você tem esses dois momentos você tem um momento hoje você tem um momento do futuro e principalmente né Você tem os pontos intermediários as transformações que você vai fazendo exatamente eventualmente eu tenho em alguns clientes trabalhado nesse documento haicai uma área então vamos chamar assim um desdobramento do Haicai para não poluir tanto o princípio do Haicai do fermento mas eu trago uma área de Rode map Para justamente deixar explícito Essa visão arquitetural da Olha nós estamos aqui nós gostaríamos de chegar em vias do que conhecemos até o momento

neste modelo ou Nesse estilo mas o nosso próximo passo é esse então fica um pouco mais fácil conversar com o time de negócio de justificar isso porque precisamos chegar nisso aliado claro e com toda certeza com objetivos de negócio atributos de qualidade então nós estamos aqui nós estamos atendendo ou a gente não está atendendo em Plenitude todas as tribos de qualidade precisamos mover a nossa arquitetura para tal ponto para fazer a tendências atributos e plenitude e isso leva um segundo ponto de documentação que é eu acabei só primeiro né exatamente e que demos leva a

esse segunda esse segundo Pilar digamos assim que é as decisões sobre arquitetura que que é justamente o porquê das coisas e eu desafio aí a todo mundo que tá assistindo nesse momento que é um código passado um código de um ano dois anos atrás Olha o código e tenta identificar o porquê que foi feito daquela forma não é o que não é o a decisão em si mas é o porque vamos lá a gente sempre dá o exemplo do Cash né mano por que que foi decidido colocar um componente De Cash Por que que foi

decidido usar um processo assíncro no quintal em tal parte do sistema em tal sistema esse porque ele se perde com o tempo e se eu não me engano acho que era o niver que ele fala que quando quando uma pessoa tá em frente a uma decisão que ele não entende ou que ele não entende o porquê ele só tem Duas escolhas ou aceita cegamente aquela decisão ou muda aquela decisão cegamente e ele é maravilhoso Nisso porque e vamos falar um pouquinho sobre o dia a dia das empresas falar sobre o mundo real de novo o

Google define ingerir software como desenvolvimento de software ao longo do tempo você sonha variável do tempo cara o que que acontece quando você tem variável do tempo Primeiro o elemar do Futuro Definitivamente não é o ele é mais de agora né então eu preciso me comunicar com ele mais do Futuro agora além de toda essa essa jogada e tentando tirar de lado aí a minha deficiência de memória né o fato não consigo lembrar como você cara você tem outro problema você tem você tem numa empresa você tem gente entrando e saindo dos times todo tempo

você tem pessoas que chegam e pessoas que partem né E aí para essas novas pessoas desenvolvedoras o pessoal que começa a trabalhar no código como que eu sustento E como que eu apresento para essas pessoas as decisões é interessante porque você fala com relação às decisões a gente vê que o arquiteto tem algumas atribuições é primeiro ele tem garantia que as decisões sejam tomadas então um ponto né mas só reforçando ele tem que garantir que sejam tomadas não é tomar as decisões consolidada para mim pelo menos de que o papel principal do arquiteto é ser

um aquecedor é claro que existem cenários em que se espera do arquiteto profundidade técnica É certo que você precisa às vezes não só a profundidade mas amplitude para projetos mais amplos e tal mas de uma maneira geral o arquiteto tem como função primária fazer orquestração né das tomadas de decisão porque porque no mundo técnico que a gente vive né especialistas São pessoas que sabem cada vez mais sobre cada vez menos é cara você tem decisões muito importantes são tomadas na persistência dos dados de aplicações Quando você pensa e praticamente a tua nuvem que você usa

ou não determinada componente pronto tudo isso envolve tantas especialidades que são impossíveis se concentrar numa pessoa sozinha então precisa fazer exatamente essa questão para poder envolver os diversos especistas mas aquele Gabriel tem um ponto importante né você fala e faça uma importante você registrar as decisões porque teto ele garante que sejam tomadas ele garante que as instruções sejam justificadas né E esse é o grande ponto né muitas vezes e aí começa interessante cara porque antes quando a gente estava falando do Haicai a gente falava sobre a o fato de você começar a eliminar subjetividade porque

a própria documentação te obriga a colocar informação um pouco mais elaborada um pouco mais menos subjetiva né E quando você vai aí falando sobre as decisões você também puxa eventualmente a necessidade de você justificar cada decisão E aí você tira um ponto que é um prejuízo em muitas organizações de todos os esportes né que é as pessoas decidindo com base e eu querem preferência e não necessariamente de maneira alinhada com as necessidades do negócio com restrições ou atributos de qualidade exatamente E aí traz também o que tu comentou anteriormente de que se um time tá

prestes a tomar uma decisão e e aquela solução ou aquela proposta que tá sendo vai ser votado tomar decisão não tá muito claro os prós e contras talvez não estejamos preparados ainda para tomar decisão e e formalizar isso de certa forma a decisão o porquê da decisão motivação da decisão eu vejo que é trazer o porquê trazer um contexto para isso então Olha estamos enfrentando um problema de desempenho as requisições estão ficando cada vez mais lentas estamos degradando no sistema e recomendamos a decisão seria recomendamos adicionar um componente De Cash para aliviar a pressão no

banco de dados que está sendo gargalo do momento só isso já é melhor do que não ter nada mas trazer uma dimensão de prós e contras dessa decisão Então qual a vantagem de adicionar esse meu cache no rediz que que eu tô ganhando e qual que é o meu contra citação citação do grande o sábio Lemar toda escolha é uma renúncia novas contas Olha só esse é um ponto interessante bom meu amado Então a primeira coisa que tem que pensar Você tem que pensar uma estratégia eficiente de para validar esse Cash e principalmente invalidar né

segundo você tem que considerar falando sobre disponibilidade mentalmente Cash vai melhorar também que eu tô disponibilidade mas seguramente também vai ter um problema novo de segurança Porque você vai estar eventualmente com dados sensíveis armazenais enquete como é que você vai tratar Esse aumento de potencial potencial superfície ataque né você tem mais espaço para ser atacados tem que considerar vulnerabilidade fora isso também né meu amigo Gabriel você tem administração desse Cash porque você vai montar dependendo do tamanho do negócio botar um cluster de você não vai simplesmente ligar o e diz utilizando o teu o teu

docker da vida aí para poder instanciar alguma coisa daquele jeito e cara você começa a ter outros problemas e se você tá no ambiente que é gerenciado você tem o custo eventualmente desse Cash E aí você começa de novo a perceber que Poxa Cash é uma boa saída assim mas ela traz uma série de pontos de exatamente E aí volta no fluxo no papel do arquiteto que eventualmente eles assim de bom essa decisão ela sim atende os requisitos os objetivos de negócio ela respeita as nossas restrições atende os atributos de qualidade principalmente que a gente

está buscando resolver no momento mas talvez ela não seja a solução mais barata e com menor risco no momento aliás assim a quantidade de vezes que a gente encontra pessoas tentando usar armadiz por exemplo para poder diminuir o peso sobre o banco que está estressado não é sempre fala cara se o banco na maior parte das vezes quando o banco de dados é apontado como sendo o problema definitivamente o banco não é o problema tá você tem um monte de consultas ofensoras você tem um monte de índice planejado você tem um bocado de trabalho de

setup de banco que Poxa muitas vezes pensa e rápido né a utilização do banco já faz com que você diminua a pressão sobre o disco enfim aí tem um bocado de variáveis exatamente e ter esse registro dessas decisões e não é ruim falar registro da decisão porque não é o registro da decisão mas é elaborar a decisão no formato um pouco mais explícito traz a reflexão para o time e vejo como o papel do arquiteto também é estimular essa essa documentação a gente tá em vias falando de adrs né de registros de decisões de arquitetura

e não importa o formato é coisa Sempre falando a tecnologia pode registrar isso no marketing em qualquer lugar num papel de pão mas o importante que eu percebo e tenho percebido no passado que é estimular essa prática faz o time refletir começa a refletir sobre esses pontos principalmente os prós e contras e essa questão de custo e risco porque senão acaba virando aquela decisão baseado no modismo baseado na vontade do time que acha que Poxa nesse exemplo Cash resolve tudo eu tenho uma vontade enorme de trabalhar com rediese então ele é a solução para os

problemas agora e talvez não seja a solução para o negócio naquele momento e aí você fala sobre a Dr só para poder a Dr é a câmara de arquitection é exatamente uma proposição do próprio nigga de quem está falando antes porque ninguém quer dizer cara se você for documentar Cara você não é documentar mais nada documento essas decisões né decisões para você criar uma memória das decisões esse é mais decisões é cara a decisão oferece o contexto A decisão foi isso aqui eventualmente a gente sabia que os pontos de cuidado aí os prejuízos que nós

tivemos são esses aqui eventualmente as vantagens né os principais motivadores foram esses aqui até para que no futuro você possa reverter essa decisão com mais tranquilidade se não fica como ninguém te falou você encontra alguém que não encontra o sistema de determinada forma e sem uma explicação para aquilo poxa fica ali só duas opções ou mantém as coisas cegamente para não correr riscos ou alteras cegamente o que pode ser pior ainda porque toda a decisão foi tomada com base em alderício tomada pelo menos daquele momento ou naquele naquela Linha do Tempo fazer sentido muito bom

muito bom então vamos lá a gente fala sobre documentação sentido mínimo faz uma documentação super pesada não necessariamente E aí tem a questão depende cara mas não necessariamente dependendo do que olha eu gosto da provocação lá do destina que diz que você deveria conforme o teu nível de risco risco tolerado né quanto maior quanto maior o risco que você precisa evitar maior necessidade eventualmente você tem mais Rigor aí para documentar E aí você fala sobre a gente falou aqui sobre dois tipos de documentação básicas ou seja vamos manter a documentação a princípio a partir de

um haicai no seu formato mais simples Haikai uma documentação mínima que fala sobre as principais funcionalidades principais objetivos de negócio restrições atributos de qualidade Associados e eventualmente alguma coisa esquematizado para as integrações e também né um conjunto de adrs né que como você disse um documento Simples que disse para cada decisão Qual foi a decisão contexto é prós contras e eventualmente um outra informação tradicional tudo isso podemos ser mantido inclusive junto com o controle de versão até para que você possa ser também Em que momento aquela Decisão foi tomada né é muito bom muito bom

muito bom agora veja só coisa meu amigo não tem nada e esse é o ponto importante tá você toma as decisões você toma as decisões fazer software implica em tomar decisões você pode não tomar decisões do jeito certo você pode não tomar as instruções baseadas em uma estratégia sempre falo que estratégia um padrão coerente para tomar as decisões Talvez não tenha um padrão coerente né você esteja decidindo cada hora o sabor de quem tá escolhendo Mas enfim você toma decisões o tempo todo é no nível triturado de novo aqui pra gente trazer as lições de

arquiteturas são aquelas ações de design que vão ter maior impacto no futuro do projeto você não exagerar Mas enfim você escolhe esse conjunto decisões que caiba desse esse corpo de arquitetura e aí você tem isso nas adrs e essa visão geral em cima do Haicai muito bom muito bom faz muito sentido né mano e principalmente eu diria o seguinte para quem tá começando ou não tem as práticas ainda fazendo isso e insistir novamente comunicação é repetição não adianta fazer e esquecer e nunca mais ser retomado então tem que ser revista esses problemas esses documentos de

forma constante com o time Para justamente validar se Eles continuam tendo o conteúdo dele continua sendo válido para aquele momento do tempo onde que o time se encontra com frequência As pessoas dizem que o problema de documentação de documentação não compila e aí tem n hoje tecnologias que fazem com que você Tente lugar o espaço documentação junto do código fonte para gerado automatizada mas repara que tudo que a gente está falando aqui fala menos um pouco menos sobre o desenho do sistema sob o shape do sistema a gente tá chegando nesse nível de documentação a

gente tá querendo criar diagramas muito complexas nada disso a gente quer cara explicitar o que que motivou o desenvolvimento desses tempos que motiva Quais são os principais pontos de atenção e cara ao longo do tempo Quais são os principais de que foram tomadas para poder garantir que pelo arquitetura como é que se Vita erosão né Eu tomei as decisões eu justifiquei as decisões eu faço com que existições sejam conhecidas e potencialmente para elas conhecidas eu tenho a esperança de eventualmente manter essas decisões respeitadas agora um ponto interessante você tá trazendo para mim também aqui Gabriel

é de novo volta para o dia a dia né porque desenvolvedores muitas vezes tem essa ansiedade de jogar coisa para o código né só que de novo o código é um lugar aonde eventualmente é difícil se preservar uma memória de decisões uma memória dos principais critérios da Estratégia né porque o haicai acaba estratégia e essa é mais difícil de documentar muito bom muito bom gente olha só essa é uma primeira conversa minha com Gabriel aqui no canal desenha aonde a gente fala sobre vamos continuar falando inclusive né outras conversas sobre aspectos práticos do dia a

dia coisa que a gente leva para coisa que a gente vê resolvendo problema no dia a dia dos clientes e cara cliente de todos os tamanhos as dicas que o Gabriel traz para a gente aqui que a gente acabou de discutir são válidas para clientes desde empresas Muito pequenas com Times muito pequenos até empresas muito muito grandes onde você tem eventualmente um tenover mais alto mais baixo Mas enfim você tem uma rotatividade maior cara essas coisas continuam sendo válidas em todos esses contextos agora em outras conversas a gente vai falar né Gabriel sobre outros aspectos

relacionados a arquitetura a gente vai continuar falando um pouco mais sobre sobre temas sociais arquitetura sempre pautado do que de fato é aplicável como abordagem bem muito real bem mundo real mesmo eu gostei bastante meu amigo Gabriel palavras finais e considerações eu traria o seguinte que para quem está assistindo hoje ou amanhã ou no futuro pessoal deixe nos comentários aí sugestões exemplos que vocês tenham nos times de vocês de documentação arquitetural vamos enriquecer um pouco e a gente está aí de portas abertas aí para a gente trabalharmos em cima disso e quem sabe ajudar vocês

aí com pequenas dicas aí com as suas documentações no dia a dia esse é um ponto importante sempre fala que é outro dia tá falando sobre isso muita gente pensa né que chegamos os clientes a gente tem quantas vezes nós chegamos em crença e não entendíamos como um sistema podia ser desenvolvido para aquele time e mais aquele sistema suporta um negócio muitas vezes gigantesco que não tem nem haicai nem é Dr né do gênero Caramba como que os caras conseguem o fato é que de uma forma ou de outra consegue Isso prova que se tá

funcionando nem tudo que eles fazem tá absolutamente errado e também nem tudo que eu fico apontando tá absolutamente certo nós não temos a pretensão aqui de sermos donos da verdade né exatamente principalmente assim ó não concordam com as duas abordagens que a gente está sugerindo ou até na questão da pergunta macro né Ela é documentário ou não se não concordo que documentário não é não precisamos disso compartilhem Vai ser um prazer a gente debater sobre Ah vai ser um prazer mas como exercício vamos tentar fazer a mesma coisa com o que a gente proporciona 10

tá se você concorda com a gente diz por que que você concorda se você não concorda com a gente tudo bem Tá mas também justifica a tua decisão eventualmente as tuas justificativa você melhores do que as nossas e cara nada melhor para mim do que pegar uma boa ideia do que eventualmente insistir na minha se por acaso ela se demonstrar não correta mas vamos continuar discutindo o futuro para você que nos acompanham até aqui olha quero te agradecer bastante esse é um primeiro vídeo como eu disse dessa nova sessão dessa nova série de vídeos pessoas

produzir sobre arquitetura Hoje eu tô aqui falando com Gabriel vou voltar a falar com Gabriel daqui alguns dias mais vídeos você complicados Diz para mim se você gostou Se gostou cara aproveita e se inscreve aqui no canal curte o vídeo Compartilhe o vídeo e vamos é dá like momento do blogueirinha e vamos expandir esse espaço de discussão para a gente qualificar né nossa nossa malha né nosso conjunto de desenvolvedores de contas não dá mais né meu amigo nós somos as responsabilidades são grandes demais não dá mais para a gente ter seus arquitetos seus desenvolvedores arquiteto

de nome arquiteto de título chega de amadorismo remunerado enfim essa é uma discussão para outro dia para quem tava aqui com a gente até agora muito obrigado né mais uma vez ajuda a gente aí nos comentários e nos vemos numa próxima oportunidade bem breve