Agradeço o Wesley pelo convite para poder passar um pouquinho do conhecimento para vocês de DynDoc. A ideia é a gente falar sobre definir projetos de software. Eu começo já, primeiro vou começar apresentando. O Wesley passou um pouco aí, mas vamos lá. Deixa eu passar um pouquinho. Eu sou o Cássio Botaro. Se vocês procurarem em qualquer lugar, vai ser sempre arroba Cassio Botaro. Eu sou engenheiro de software no PicPay. E como a Azley disse, eu tenho passagens, eu passei pelo Luisa Labs, que é o Magazine Luisa. Eu passei pela Amazon e atualmente eu estou no PicPay. E a ideia é fazer uma mescla, durante todos esses lugares que eu passei, eu tive experiências com design doc. No Magazine Luiza eu tinha um papel, eu trabalhava no time de arquitetura, e aí era o nosso papel revisar design doc. Então, eu ficava dias, assim, lendo documentos e coisas, eu lia muito design doc, dava opinião, e muito do que vocês vão ver é um pouco de mescla do que eu aprendi nesses três lugares. Na Amazon também, é uma empresa onde tem uma cultura de documento muito forte, e eu tive essa oportunidade de escrever alguns documentos lá dentro, no tempo que eu estive lá. E agora no PicPay também. Então eu vou fazer uma mescla disso tudo e apresentar para vocês sobre o 10Docs. Os slides já estão disponíveis, então quem quiser acessar para poder acompanhar, eles estão disponíveis em acesse.one.com.br que é maiúsculo, L maiúsculo, 9, E maiúsculo, X minúsculo. Então, depois eu vou mandar para o pessoal os likes. E vamos começar então para o que a gente vai ver hoje. Eu espero que, como documentação normalmente tende a ser um pouco, ah, mas eu vou escrever documentação, o movimento ágil fala que não deve escrever documentação, é preferível código e não documentação. De cara, eu quero já quebrar um pouco esse estigma. O que acontece, e aí eu vou parafrasear um pouco do Lémar Júnior, que ele fala que se você pega uma frase sem o contexto, ela apenas não é pretexto. E é mais ou menos essa a minha visão sobre documentação. O que acontece é que o movimento ágil ele vem de um momento onde as pessoas escreviam verdadeiros livros de documentação e perdiam o time de lançamento de software você tinha seis meses de levantamento de requisitos para depois realmente escrever o código então esse tipo de documentação não é saudável, essa coisa de você esperar o momento, esperar a documentação do antes. Existe até um termo em inglês que é o Big Up Front Line, que é aquele design antecipado, aquele design grande antecipado. Ou seja, você antecipar muitas das coisas no começo e aí o Dave Thomas, aquele mesmo do Programador Pragmático, ele tem uma frase que é a seguinte, Big Upfront Design is done. Que é tipo, esse design antecipado é idiota. Só que não ter design nenhum é ainda mais idiota. Ele falou essa frase em inglês, mas aí eu já tomei a liberdade de traduzi-la para você. E vocês vão ver que ao longo do que eu for passando aqui, a ideia é mostrar a importância que a gente tem como um elemento de comunicação. Documentação é um elemento de comunicação e é uma coisa que você sempre deve pensar nos outros. Pensar no sentido de como eu vou me comunicar com as pessoas, como eu vou deixar as minhas decisões técnicas para uma determinada pessoa que possa vir a olhar o meu sistema depois. A gente tem um certo costume, nós pessoas desenvolvedoras, de olhar para o código e falar, nossa, mas esse código está muito ruim. E quando não é a gente mesmo que escreveu, mas ele é outra pessoa, a gente costuma falar, nossa, mas por que essa pessoa escreveu um código tão esquisito? E aí um código que não tem um contexto, a pessoa que não tem um contexto de quando aquele código foi escrito, ela perde muito das tomadas de decisão. Às vezes foi uma coisa que não tinha prazo para aquilo, ou teve que ser assim em determinado momento. Então, é importante a gente ter isso em mente, que não ter um contexto complica muito para a gente entender. E aí eu vou tentar mostrar para vocês que documentação, o design doc, eu vou começar até pela definição, o que é o design doc, mas ele vem para ser esse, vamos pegar o conhecimento prévio que a gente já tem sobre uma determinada solução, escrever uma documentação sobre aquilo e fazer as compensações, aquilo que a gente fala de spray dots, nada mais são que as compensações que a gente tem do porquê tomar a decisão de fazer isso ou fazer aquilo. Então, passando pela agenda de hoje, a gente vai ter uma definição do que é o design doc e o porquê do design doc. Depois a gente vai falar sobre estrutura, como estruturar o design doc. Já fica um spoiler, não tem muita estrutura. Eu vou falar um pouco sobre as ferramentas que eu dei destaque para as ferramentas das quais eu tenho experiência, mas existem outras. Eu vou falar um pouco do ciclo de vida, como que funciona essa coisa, quando eu devo escrever o design doc e como que faz. Eu escrevo, peço alguém para revisar, em que momento eu escrevo, eu implemento junto. Eu sei que é uma dúvida bem constante sobre isso, então a gente vai falar sobre isso. E como a gente fala do que, quando escrever e em que momento escrever, a gente também deve colocar o quando não escrever. O que eu não deveria escrever no design.data? Depois a gente vai ver outros tipos de documentos, vocês vão ver que existem RFCs, ADRs, esse tipo de coisa. E por fim eu estou deixando uma série de referências com documentos que são posts em que eu me baseei. Eles mesclam um pouco do Design.Google, tem referências do próprio PicPay também, que tem um artigo sobre isso, com um pouco do que eu tive do Labs, do Google Labs, e tem também material sobre... Tem um dos materiais que eu acho bem interessante, que ele mostra várias empresas que usam modelos similares a Design Doc e como eles usam inclusive o modelo disponível online para a gente se basear. Então vamos pensar esse negócio. Eu quero começar pelo conceito e a motivação. Nada mais é do que por que a gente faz Design Doc? Eu de cara, eu já acabei me antecipando em algumas coisas, que é aquela questão da gente escrever o documento como uma forma de comunicação. Mas aí vamos pegar uma definição um pouco mais formal sobre isso. Isso aqui foi retirado de um destes posts que eu coloquei como referente. Que é o seguinte, documentos relativamente informais que o autor principal ou autores de um sistema de software ou aplicativo criam antes de embarcar no projeto de codificação. Então, eu falei que em algum momento a gente vai falar sobre o ciclo de vida do documento, mas aqui já tem um pouco do spoiler de que começou a pensar em alguma aplicação, sistema, funcionalidade, escrecrevemos a Mdoc. Antes de escrever o código, escrevemos a Mdoc. E aí eu dei destaque principalmente na parte do relativamente informal. Porque quando a gente começa a ver da Mdoc, normalmente a gente pega, por exemplo, essas empresas que eu passei, a gente já tem uma template, um modelo a ser seguido. E aí a gente segue muito naquela coisa da formalidade do documento. E não é esse o propósito. A ideia é ser algo relativamente informal. Ou seja, a template é só para te guiar. Mas se você não quiser usar nada daquilo e quiser colocar coisas que te façam sentido, essa template é só um guia. E não é uma, exatamente uma, não é que você deve colocar todos os campos e tudo mais, tá? Então a ideia do Zendoc é ser relativamente formal, a gente tem que o Zendoc documenta a estratégia de implementação de alto nível, e aqui está o destaque de alto nível, a gente não está falando de eu vou evitar ao máximo colocar código ou coisa assim, tá? A ideia é ter uma visão de alto nível da minha solução, da minha estratégia, do meu sistema. E as principais decisões de design com ênfase nas compensações. E como eu disse, compensação é só uma tradução para trade-off. É aquele famoso depende. Por que eu escolhi um banco relacional ou não relacional? Isso são compensações. Então, esse tipo, o design doc é, a ideia é você colocar isso num documento, por que eu tomei aquela determinada decisão? O que foi considerado naquele momento para eu colocar isso num documento? São documentos que são feitos pelo time, e aqui fica o destaque, o time não é algo para o tech lead ou a liderança ou o arquiteto que tem que escrever, não é isso. Qualquer pessoa do time pode escrever, se ele tem alguma ideia, se tem alguma coisa, ele tem uma solução para um determinado problema. O time pode escrever, e isso pode ser uma pessoa ou vários, e ele tem o objetivo de tornar claro e compartilhável. Claro no sentido de nítido, de expressar a ideia de uma forma boa, e compartilhável no sentido de que eu posso passar para outras pessoas, inclusive devo, para que outras pessoas... Eu tenho que, sempre que eu for escrever, eu tenho que pensar a melhor maneira de me comunicar com os outros, e não assumir muitas coisas antecipadamente, no sentido de ah, eu vou colocar isso aqui porque todo mundo tem esse contexto, e não necessariamente tem. A gente vai ver que isso é uma das coisas que a gente tem que tomar cuidado, mas a gente vai ver um pouco de como que é esse design doc na prática. Então, assim, se tomando que eu estou dando destaque para algumas coisas que são muito relacionadas à comunicação, a maneira com que eu me comunico internamente ao meu time e também como eu me comunico com a organização. E vocês vão ver que o design doc é algo que você faz às vezes para documentar uma decisão que pode ficar interna ao time ou às vezes para documentar para uma empresa inteira. E é documentado o racional. O racional é por que eu tomei aquela decisão? Quais foram as minhas alternativas? Por que eu não adotei A ou B e eu acabei escolhendo essa solução C? O objetivo que é, o que eu quero atingir com aquilo? Isso eu consigo gerar métrica disso, eu consigo observar se eu colocar essa solução em produção. Qual é o objetivo que eu tenho? Eu vou ter um número maior de acessos, eu vou ter uma página mais fluida, e a gente vai ver isso de forma prática. Eu peguei um exemplo bem legal e eu vou seguir uma certa estrutura quando a gente for ver a prática. E a ideia é arquitetura entre outros pontos também. É documentar, beleza, a minha arquitetura ficou assim, a minha decisão foi por causa disso, as minhas compensações foram extras. É uma maneira de comunicar