OS 3 MAIORES ERROS DOS DEVS QUE ACABAM COM A QUALIDADE DO SOFTWARE | JORNADA DESENVOLVER TESTES

fala Dev beleza seja bem-vindo à jornada desenvolver testes eu sou André Kazak e nesse evento eu vou te mostrar o caminho que qualquer deve pode seguir para subir de nível na carreira entregando código de qualidade bom André Mas que que é essa qualidade que você fala um software de qualidade é aquele que tem três características fundamentais ele resolve o problema do usuário é fácil de manter e não tem bugs e talvez agora você esteja aí pensando Pô falar é muito fácil né seria muito bom entregar código com essa qualidade toda só que na prática não

tem como fazer isso mal dá tempo de entregar o que precisa tudo na empresa é o gente tudo é para ontem e é exatamente por isso que eu tô aqui para te mostrar que é possível sim entregar um código de qualidade mesmo que você não tenha tempo porque o para tá sempre apertado mesmo que a sua empresa não priorize a qualidade e mesmo que você mexa num código que é complexo que é difícil de alterar e se você ainda não acredita Olha só como o Wellington conseguiu melhorar a qualidade do código dele que eu tenho

um método meu que tem 3.000 linhas cara ele é como se fosse a inteligência do aplicativo esse método que tem 3.000 linhas Apesar dele ter 3.000 linhas ele cara raramente ele dá problema ele foi tão e esmiuçado ali ali estressado no teste que cara ele ele ficou cercado então ele não dá problema quando eu fui reescrever pro pro Cloud Eu já fui separando tirando carga dele então ele já eu já fui tirando partes dele Ah isso aqui é tal coisa isso aqui é pedido isso aqui é não sei o qu eu fui tirando entendeu fui

tirando fui tirando Então já tô fazendo eu já tô escrevendo muita coisa já com coisas ali do desenvolver teste entendeu muita coisa que eu tô escrevendo já já é às vezes a gente faz sem perceber isso entendeu imagina como seu dia ia ser mais tranquilo Se o usuário parasse de reclamar na sua orelha imagina o tanto de coisa que você conseguiria fazer se não tivesse que parar toda hora para olhar um bug urgente imagina como o seu trabalho i a se destacar se você conseguisse colocar a casa em ordem como o seu gestor ia reconhecer

o seu trabalho quem sabe até lembrar de você na hora de escolher alguém ali para ajudar num projeto importante para receber um aumento ou até uma promoção tudo isso tá ao seu alcance mas você precisa aprender as coisas certas e você pode até achar que eu falo esse tipo de coisa porque eu sou Tiozão e eu tenho mais experiência que você como deve ou talvez porque eu tenho mais conhecimento técnico ou porque eu me especializei em qualidade de software mas não foi sempre assim não Aliás quando eu comecei na área lá em 2001 eu nem

pensava nesse tipo de coisa tudo que eu queria mesmo era só mostrar serviço entregar a maior quantidade de tarefas no menor tempo possível como todo deve e como todo deve que também trabalha desse jeito também sofria com bug e eu acho que todo der tem uma história triste de bug para contar né teve uma vez nesse começo de carreira lá em 2004 né é que já não era tão começo assim já que eu comecei em 2001 né já tinha um pouquinho de experiência aí mais de tr anos já era um Dev pleno Inclusive eu mexia

com um sistema que Calculava as parcelas que o cliente tinha que pagar e aí ele mandava os débitos diretamente pro banco o sistema em si ele já era bem complexo ali tinha umas regras de negócio e ainda executava um monte de processos diferentes e era um monólito né gigante só que tava construído ali de um jeito meio largado né E aí para piorar ainda por cima era em Visual Basic 6 que é é um ancestral do VB NET ainda né um negócio que já é tão velho que nessa época mesmo já era velho lá em

2001 já era uma coisa velha o o próprio vbnet hoje se você for ver Já é velho né a galera que aprende dnet agora Mal sabe que ele existe né porque todo mundo entra direto no C Sharp que faz sentido porque é bem melhor né mas quem é mais das antigas aí sabe do que eu tô falando vb6 era uma linguagem bem bem mais ou menos que tentava se orientado a objeto mas cara passava muito muito longe disso e o código desse sistema era terrível para dar manutenção e a gente se virava ali do jeito

que dava né às vezes tentava baixar os dados do banco de produção para testar ou às vezes nem testava direito né ia na cara e na coragem mesmo e já mandava pra produção depois ficava lá acompanhando log olhando para ver se estava tudo executando sem erros com o tempo eu fui pegando confiança né fui pegando a manha de mexer ali Porque por mais que o código seja difícil de alterar você vai se acostumando com o jeitão dele né já sabe onde estão as coisas que Pontos são mais críticos aqueles lugares lá que são os famosos

cara não mexe porque senão vai quebrar E aí com tempo você vai mapeando tudo isso aí na sua cabeça e fica mais tranquilo de mexer é natural até que um dia eu tive que fazer uma correção nessa rotina de cálculo aí que era tipo um faturamento né tinha que mandar coisa pro banco e tal Calculava que o cliente tinha que pagar e aí quando o negócio era fechado de fato a gente aí sim mandava cobrança pro banco e pior que alteração em si era um negócio simples Até era só alterar uma query mexer em uma

condição Zinha ali na consulta que tava gerando um bug e não pegava o registro que tinha que pegar no caso né Aí eu fui lá alterei tudo cara na maior confiança eu já sabia mexer no código Inclusive eu já tinha mexido naquela mesma antes então pô não tinha o que dar errado aí eu fui lá alterei fiz uns testes Meia Boca ali e mandei pra produção não tinha nem uma homologação naquela época ali né um teste de aceitação do usuário era gente gente mesmo que testava e mandava direto pro servidor de produção nos anos 2000

era assim parece que é esquisito aí para você que de repente você tem muita burocracia para mandar as coisas paraa produção mas lá em 2000 o negócio era meio vida louca mesmo você mandava os Dev mandavam as coisas PR produção e vai tocando o barco aí só que aí a minha alteração ela tinha um erro na query só que o grande problema é que a query ela não ficou quebrada em produção não é que ele executava e dava uma Exception lá no banco era um erro de negócio o filtro que eu alterei ele começou a

gerar um produto cartesiano Em algumas situações que tinham na base se você não sabe exatamente o que que é isso que eu tô falando eu vou explicar resumidamente aqui imagina que você faz uma consulta no banco que tem vários joins envolve várias tabelas ali aí o seu filtro a sua cláusula w ela tem que trazer um registro só que ao invés de trazer um Trouxe dois trouxe cinco registros repetidos porque você errou o join aliha algum lugar aí lá no seu programa O que que você faz você cria um loop né queê os registos E

aí fazuma eles lá certo agora imagina no Mea aí eria eama e exec eress fazito doente ou seja eu fiz uma bobagem com proporções catastróficas teve cliente que ligou lá pra gente para reclamar porque ele recebeu 10 cobranças no mesmo dia inclusive um desses clientes aí Infelizmente era diretor da empresa mesmo e o pior você não sabe ainda né sempre pode ser pior Não isso não foi só uma vez não foi só uma vez que aconteceu eu gerei esse mesmo bug de mandar débito errado pro banco algumas vezes Claro que não na mesma quer né

porque aí eu aprendi que não podia mexer nela de qualquer jeito mas lembra que eu falei que o sistema era complexo que ele era difícil de alterar é que eu mexia num lugar aí quebrava outro aí eu consertava esse outro lugar quebrava um outro lugar novo e aí nessa aventura aí foram várias e várias cobranças erradas Eu só não perdi o meu emprego porque o meu chefe falava que era melhor ficar comigo lá para corrigir do que pegar outro Dev idiota para fazer mais bobagem do que o eu fazia mas assim de verdade por pior

que fosse por mais zoado que seja esse cenário aí no final do dia eu achava normal passar por esse tipo de perrengue com bug É claro que eu ficava chateado cara ninguém gosta de fazer bobagem em produção e até porque eu ficava na angústia ali de ser demitido né me incomodava ver que eu tava causando transtorno pra empresa transtorno não só pra empresa mas pra equipe pro meu chefe que tinha que ficar explicando lá segurando bucha cara ninguém gosta de fazer um mau trabalho todo mundo se sente mal mas nessa época para mim era normal

eu sempre via a Dev correndo atrás de bug fazendo correria o usuário reclamando toda hora porque o sistema não funciona direito é Dev reclamando que o código era mal feito essa aí é minha realidade e a galera que trabalhava comigo os deves que eu conhecia da faculdade das outras empresas que eu trabalhei também até falavam em escrever um código melhor tentar testar as alterações com mais cuidado né só que na prática de verdade ninguém fazia nada todo mundo só entregava código do jeito que dava para sobreviver e para manter o emprego não tinha o que

fazer tudo era urgente tudo era para ontem e testar testar era publicar no servidor e usar as telas do sistema sair clicando nos botões a coisa mais refinada que a gente fazia era debugar os projetos na máquina local apontando às vezes para um banco de teste ou quando muito apontando pra produção quando tinha acesso nem passava pela minha cabeça que dava para fazer as coisas de outro jeito Esse era o jeito normal foi o jeito que me ensinaram e também era o jeito que eu via por aí era o jeito que todo mundo Fazia mas

assim eu sempre gostei de estudar eu sempre pesquisava queria aprender coisas novas principalmente no começo da carreira no começo da carreira a gente tem aquele gás né Aquele ímpeto de aprender coisas novas de aprender coisas diferentes e aí numa dessas aí eu comprei esse livro aqui ó sobre XP o Extreme programing é um livro muito legal por sinal do Vinícius tellis e um dos pilares do Extreme programing é o tdd Então nesse livro aí como é sobre Extreme programing tem um capítulo que fala só sobre teste unitário aí cara quando eu comecei a ler o

livro eu fiquei maluco Como assim tem uma parada onde você escreve código para testar seu outro código e ainda roda tudo automatizado você cria uma vez e já era depois que o teste tá tudo pronto ali dá para corrigir bug criar funcionalidade nova sem medo de quebrar o que tá funcionando pô nada de B nada de mandar deve ter errado nada pro de cliente reclamando na minha orelha aquilo era a minha salvação quando eu vi aquilo brilhou demais o meu olho eu só precisava aprender a fazer uma coisa só uma coisa e aí a qualidade

do meu código a qualidade do software que eu mexia que era uma porcaria ia Decolar então eu comecei a estudar Que nemum maluco para aprender logo a fazer isso aí e aplicar no meu trabalho mesmo na época já mexia com com dnet né que no caso era vbnet E aí quando eu fui colocar em prática né estudei estudei e vi tudo que precisava ali quando eu fui pra prática mesmo quando eu abri o código da empresa ali que eu código aquele código que eu mexia todo dia né para poder começar a fazer meus testes não

rolou E o pior é que eu eu li os artigos eu li a documentação do n unit né que era o Framework mais usado na época de verdade eu nem sei se tinha outro a e assim eu eu via documentação via artigo via exemplo tudo fazia sentido não não era tão complicado era só sentar lá no código e fazer só que quando eu olhava pro meu código não encaixava não dava certo pô como é que eu vou testar esse método de 500 linhas que que eu coloco nesse assert que que eu tenho que fazer mock

que onde eu entro mock aqui eu tava totalmente perdido e Pior né eu não conseguia entender Por que era tão fácil quando eu vi os exemplos mas era tão difícil quando eu tentava no mundo real no meu código mesmo E para piorar também nunca dava tempo de fazer teste unitário né às vezes não dava tempo de testar Nem manualmente porque tudo tava sempre atrasado chefe cobrando cliente reclamando tinha que mandar logo o código para produção essa história você já conhece né Essa aí a vida normal de todo Dev né Eu acho que você já deve

ter passado por isso como qualquer outro deve no final das contas eu comecei igualzinho a você eu tinha os mesmos problemas que você passa aí as mesmas dúvidas que você tem mas aí chegou uma hora que cara eu desencanei ah sei lá não tá rolando acho que esse negócio de teste não é para mim não tá dando certo vou me concentrar em fazer outras coisas e aí quem sabe um dia se tudo der certo né eu volto para ver esse negócio aí de teste unitário que parece promissor mas assim de verdade não tá rolando E

aí nessa mesma época que eu desencanei do teste é calhou de acontecer um monte de coisas diferentes aí na minha carreira né eu acabei participando de muitos projetos Diferentes né alguns onde eu tive que programar frameworks né aqueles componentes de base mesmo sabe é componente padrão que muitas empresas criam aí para agilizar o desenvol o desenvolvimento interno eu cheguei a criar sistemas do zero né Nunca tinha criado tanto sistema do zero assim né que não tinha nenhuma linha de có sempre que eu chegava na empresa já tava tudo pronto tinha que dar manutenção é mas

acabei criando algumas coisas do zero mesmo né criei Pô toda a base da arquitetura ali e o desenho da solução coisas que eu nunca tinha feito antes né também trabalhei em Sistemas grandes cara com milhares de usuários com várias equipes trabalhando nele ao mesmo tempo ali dezenas de devis literalmente mexendo no mesmo código fazendo Deploy do mesmo código em produção e e esses projetos grandes eles também me levaram um pouco mais perto do usuário eu não tinha muito contato com o usuário né só pegava o trabalho e saía codificando porque eh nesses projetos grandes aí

todo mundo acabava trabalhando na mesma sala então a gente ficava muito perto acabava tendo muitas conversas sobre várias coisas ali do software né do uso do software né Isso foi realmente muito legal porque eh eu tive a oportunidade de conhecer pontos de vista diferentes do nosso de Dev que geralmente é código código código eu comecei a ver de perto como o usuário mexia no sistema as dificuldades que ele tinha no dia a dia até entender Às vezes porque que ele precisava de determinada alteração mesmo quando e o negócio chega meio esquisito Sabe aquele requisito que

você recebe que você fala pô que que o usuário tá pedindo isso eu comecei a ver isso no meu dia a dia e eu comecei a entender porque ele precisava outra coisa interessante também é que eu comecei a falar mais com o time que faz os testes de aceitação na empresa que lá é uma função que é bem parecida com Q E isso foi muito bom porque mudou a minha visão sobre os testes sobre como trabalhar com testes Diferentemente dos devs os qas eles têm método eles têm processo eles têm processos muito bem definidos para

fazer teste o Dev tem o hábito de testar rodando o sistema com debug sai clicando nos botões lá entra nas telas o qa não o q pensa diferente ele entende o requisito Ele quer saber como o usuário mexe no sistema O que que tem que acontecer em cada situação e eles planejam o teste eles não testam o que dá na Tera o que eles acham eles descrevem o que precisa ser testado e só depois que eles executam em termos de carreira Essa época aí para mim ela foi muito muito enriquecedora eu ainda era Dev pleno

ganhava um salário ali dentro da Média mas cara eu aprendi muito foi muito bom mesmo esse tipo de experiência porque eu evoluí muito como deve nessa época aí e aí depois de um tempo eu resolvi retomar meus estudos sobre teste unitário e olha só por algum motivo o negócio começou a fluir Lembra que eu falei que antes eu mal consegui escrever um teste que eu não sabia nem por onde começar abrir o editor ficava olhando para ele pô que que eu testo aqui para que que eu tenho que fazer esse teste só que agora quando

eu retomei depois de todas essas experiências parecia mais fácil Ficou tudo muito mais simples de entender e aí cara comecei a fazer teste unitário para tudo sempre que dava Tava fácil então fui no embalo e nesse embalo aí eu comecei a criar um jeito próprio de trabalhar que era um pouquinho diferente do que a galera lá da empresa fazia eu falava mais com os usuários porque afinal tinha o hábito de conversar com eles eu conversava sobre testes com os qas eu fazia uns testes unitários ali fazia uns refon ali tudo coisa que o nosso time

não fazia na época e aí depois de um tempo coincidentemente ou não a quantidade de bug das minhas entregas ela foi diminuindo tinha menos reclamação dos usuários nos projetos por onde eu passava o código ele ficava melhor até as equipes né os deves ali do time eles acabavam evoluindo também aprendendo mais e isso com o tempo né claro não passou despercebido meu salário aumentou eu virei Sênior depois eu fui promovido para um cargo que é acima do sor ainda né mas ainda na área de devv eu participei de outros grandes projetos grandes da empresa ali

né outros projetos estratégicos eu recebi prêmios de reconhecimento por ele também e nada disso aí foi forçado eu não fiquei pedindo promoção e nem pedindo aumento e foi por isso até que eu fiquei muito feliz com esses resultados porque eu via outros débitos fazendo de tudo para conseguir promoção fazia propaganda do Trabalho queria sair na foto né dos projetos importantes e eu sabia que o que tava me ajudando Ali era a qualidade das minhas entregas era isso que tava fazendo diferença só que tinha uma coisa que de verdade me incomodava muito eu mexia no código

fazia teste deixava tudo bonitinho ali aí o time ia lá bagunçava tudo de novo quebrava a arquitetura não fazia tese de nada nem rodava os teste e deixava tudo o código de qualquer jeito lá de novo aí eu tive uma ideia genial né eu falei pô vou ensinar a galera a fazer o que eu faço e não porque eu queria ser bonzinho é que se todo mundo aprendesse a testar direito aprendesse a entregar com qualidade o código ia ficar melhor para todo mundo inclusive para mim eu tava tendo retrabalho pô se eu ensinar a galera

a fazer o que eu tô fazendo aqui vai melhorar e vai me economizar tempo não preciso ficar arrumando o que estão fazendo aqui foi aí que eu comecei a minha Saga eu comentava sobre as coisas que eu fazia lá no café da empresa no bar depois expedi gente falava em reuniões dava palestra eu queria dar aula pra galera do time dei várias aulas gratuitas ali né Só reunia a galera depois do expediente para ensinar as coisas só que eu explicava eu mostrava eu sentava do lado para fazer junto e a galera não conseguia fazer eles

falavam que pô tudo isso é muito bom cara é muito legal mas no final eles não faziam ah dá tempo né Por agora deixa quando tiver mais tranquilo e aí as discussões por causa de bug elas não paravam né todo dia eu ficava lá isso é bug isso é feature e não sei o quê eu via que o time Se matava para entregar dava o sangue ali mesmo se esforçava de verdade e o usuário continuava falando que tava tudo errado que não era o que ele precisava retornava bug e no final às vezes até tem

tentava mas acabava desistindo botava culpa no código que era ruim de mexer no usuário que não sabia pedir que era indeciso botava culpa na empresa também porque aqui não tem uma cultura de teste não adianta ficar fazendo esse negócio aqui o chefe também fica aqui pedindo tudo para ontem não dá para fazer nada direito cara essa eram as mesmas coisas que eu fazia e que eu reclamava antes as mesmas coisas igualzinho E aí eu comecei a me perguntar pô por que que não tá rolando eu tô me esforçando Tanto Tô dividindo tô explicando mas não

tá indo Será que tá faltando explicar alguma coisa ou será que as pessoas só falam que entregar com qualidade é bom mas no fundo no fundo elas não acreditam nisso de verdade ficava com essas dúvidas aí né só que aí um dia eu percebi um padrão tinha uma pergunta que eu fazia sempre que alguém vinha me falar alguma coisa ali tirar alguma dúvida e a resposta era sempre muito parecida mesmo com pessoas diferentes em códigos diferentes situações diferentes quando a pessoa me perguntava pô André como é que eu faço para testar isso aí eu perguntava

de volta tá mas o que que esse código tem que fazer Qual que é o problema que precisa ser resolvido e ninguém absolutamente ninguém sabia me responder essa aí era para ser uma resposta Super simples coisas do tipo Pô o problema é que o site não tem um lugar para oferecer um desconto pro cliente e aí a empresa quer fazer promoção e não consegue mas a resposta que vinha era sempre um negócio enrolado cheio de detalhe técnico pô tem que criar um campo de cupom na tabela Depois precisa criar uma consulta Aí tem que fazer

esse if para poder calcular certo e aí foi aí que eu me gay a gente aprende a programar de um jeito que não favorece a qualidade do código a gente não consegue responder a pergunta qual é o problema do usuário de uma forma simples e direta para mim essas respostas eram muito Claras mas aí eu entendi que não era Claro para todo mundo nesse tempo aí que eu trabalhei em projetos diferentes que eu falei com pessoas de áreas de diferentes eu acabei esbarrando em conhecimentos que um Dev geralmente não aprende a usar no seu dia

a dia porque ninguém ensina foi por isso que uma hora a qualidade do meu código mudou da água pro vinho até o teste unitário ficou mais fácil de fazer foi porque eu aprendi o que faltava e contando essa história desse jeito aí parece que foi super rápido né mas demorou bastante entre comprar esse livrinho de XP aqui e começar começar a entregar código com uma qualidade decente mesmo foram 13 anos 13 longos anos Cara isso é muito tempo fala a verdade e é por isso que eu tô aqui hoje promovendo a jornada desenvolver testes agora

que eu entendi o que que falta para entregar código de qualidade eu consigo ajudar outros devs a não passar 13 anos de perrengue que nem eu passei ah mas pô se você já tem um trabalho você já tem um salário legalzinho aí por que que você usa seu tempo livre para ensinar e é justamente por trabalhar na área que eu me esforço tanto para ensinar cara todo Dev já sofreu para dar manutenção e um código sem qualidade Provavelmente você sofre até hoje aí isso atrasa as entregas gera estresse gera correria atrás de bug a única

forma efetiva de melhorar isso é ensinar os deves porque não adianta ficar falando com empresa não adianta ficar falando com gestor com diretor tem que falar com quem tá lá no campo de batalha e eu posso falar isso com propriedade porque eu também tô no campo de batalha eu sofro com os mesmos problemas que você sofre e eu sei como faz diferença quando o time todo se preocupa com a qualidade do código a vida de todo mundo que tá envolvido ali na prod do software ela fica mais fácil o Dev o que o gestor usuário

Todo mundo inclusive eu também porque eu tô no meio dessa galera aí tô no meio da guerra e no final das contas também é uma forma de eu retribuir eu sou muito grato de verdade à área de TI tudo que eu tenho hoje de alguma forma só foi possível porque eu tô há mais de 20 anos na área e consumindo conteúdo de outras pessoas que um dia partilhar o seu conhecimento em blogs em vídeos em livros Então nada mais justo do que devolver um pouco desse conhecimento aí que eu peguei pra nossa da nossa comunidade

aí é e fazer essa roda girar um pouquinho mais então vamos lá ó an nota aí que essa parte da aula de hoje ela é muito importante e vai te guiar durante toda a jornada essas coisas que você aprendeu errado e as coisas que você não aprendeu elas geram os três maiores erros dos deves que acabam com a qualidade do software Primeiro Erro fazer tudo que o seu usuário Pede esse aí é o famoso cara freg sempre tem razão e olha aí por que que você comete esse erro que é o tipo de coisa que

tá tão enraizada na nossa cultura que acaba até virando ditado popular né ô André mas todo mundo sempre fala que a gente tem que programar aquilo que o usuário pede porque é ele que vai usar o software então ele sabe tudo que precisa e esse pensamento aí não tá 100% errado o problema é que ele parte do princípio que o seu usuário conhece muito bem o software que ele sabe exatamente o que ele quer e que principalmente ele sabe direitinho como te pedir para fazer e é engraçado quando a gente fala porque essa é exatamente

uma das maior as reclamações dos deves não é que o usuário não sabe pedir que ele não sabe o que quer que ele muda de opinião toda hora a gente reclama mas no final do dia faz tudo que ele perde imagina que você tá reformando a sua casa e você contrata um pedreiro para fazer o serviço aí você vê na internet que é a moda tem um ambiente integrado né Mais amplo e você pede pro pedreiro quebrar uma das paredes Pô você é o dono ou você é dona da casa você é a pessoa que

mora lá é a pessoa que usa o lugar todo dia a Ainda por cima é você que tá pagando reforma faz todo sentido que você faça o pedido e faz todo sentido que o pedreiro atend seu pedido também não é isso mas será que você tem o conhecimento suficiente para dizer se aquela parede pode ser quebrada ou não E se a casa desmoronar depois porque a parede que você pediu para quebrar sustentava todo o peso do teto Por exemplo Será que depois que isso acontecer você vai dizer não tá tudo bem eu que pedi a

culpa é minha mesmo eu que vou arar com esse prejuízo aí ou será que você vai culpar o pedreiro porque ele não te avisou ele não te alertou que isso podia dar problema falando do exemplo parece que é uma coisa idiota mas o usuário faz isso com você ele faz exatamente a mesma coisa às vezes ele até conhece o software de verdade ele sabe quais são as necessidades é ele que usa todo dia ele sabe quais são os problemas é ele que passa perrengue ali ele que precisa de solução só que muitas vezes ele não

tem conhecimento suficiente para dizer o que que pode o que não pode ser feito dentro do software e você pode ter certeza se não der certo ele vai dizer que a culpa é sua que foi você que não entendeu direito que precisava fazer E aí gerou bug é a mesma coisa que você faria com pedreiro na reforma da sua casa um outro ponto negativo aqui é que o o que o usuário pede né é que muitas vezes é que ele não sabe explicar direito o problema ele nem sabe direito Às vezes o que que precisa

fazer para resolver ele só pede porque ele teve uma ideia e o pior né que na tentativa de ajudar ele ainda tenta te mastigar demanda ao máximo ele começa até a descrever Tecnicamente o que que o sistema precisa fazer ó eu preciso de um campo aqui na tela que ele tem que ser gravado no banco para enviar lá para ap do parceiro e receber os dados do cliente depois o sistema tem que usar esse campo aqui e para fazer um cálculo retornar o valor total na tela olhando assim né esse tipo de requisito Até parece

um negócio bom pô é legal é muito bem detalhado ele falou até que precisa de Campo na tela campo no banco Campo na pi legal para caramba É só abrir o editor de código agora e sair digitando sair programando só que nessa descrição aí o usuário tá definindo uma solução técnica ele Definitivamente não tem conhecimento necessário para opinar sobre isso não é a função dele ele pode até falar algumas coisas Nesse sentido porque de repente ele tem algum conhecimento técnico né ele às vezes tem mais familiaridade com o software a Às vezes a gente chama

isso aí de power user né mas esse aí de qualquer forma independentemente do conhecimento que ele tem não é trabalho do usuário esse trabalho aí é seu esse trabalho é do Dev e eu sei que Pode parecer exagerado Pode parecer que a sua situação às vezes é muito diferente mas para para analisar como requisito chega em você não precisa pegar um negócio muito distante não pega o último requisito que chegou em você o último que você teve que mexer dá uma olhada aí se o seu usuário não tá falando que precisa de um campo na

tela que precisa gravar informação no banco que ele precisa de um relatório que chega por e-mail esse tipo de coisa ele pode até parecer um requisito de negócio mas isso faz parte da solução Será que ele precisa mesmo de um campo novo na tela ou será que esse campo aí podia ser só uma opção nova num combo por exemplo que já existe Será que ele realmente precisa de um e-mail com relatório ou será que essa empresa Ela já tem um lugar para fazer relatório tipo um Power por exemplo e tudo que você precisa fazer é

extrair essa informação e mandar ela para outra base de dados você tá vendo como esse tipo de coisa a gente aprende errado que ensinam pra gente de um jeito meio torto e outra o que que você acha que um dy Júnior que acabou de chegar na empresa vai fazer quando receber um requisito desse você acha que ele vai parar para analisar o que foi pedido para ver se faz sentido se pode ser feito dessa forma mesmo se precisa fazer de outro jeito ou será que ele simplesmente vai sentar ali e vai seguir tudo que tá

escrito sair programando mais rápido possível e de novo o usuário ele não faz por mal ele só quer ajudar ele faz essas coisas para acelerar o desenvolvimento o problema aí não é ele o problema é que você aceitou Sem questionar nada você fez tudo que ele pediu sem perguntar aí meu amigo minha amiga se der problema a responsabilidade disso sempre vai ser toda sua porque foi você que aceitou eu sei que é é difícil escutar isso eu sei que às vezes pode parecer revoltante para você mas é o que é se você faz aceita tudo

que ele fala sem questionar a responsabilidade é toda sua foi você que aceitou E também não é só uma questão do que que o seu usuário pede Mas também de como ele pede porque às vezes ele escreve de um jeito que não fica claro e aí gera um entendimento diferente para cada pessoa que lê outro dia mesmo eu tava ajudando lá um Dev do meu time E aí lá no requisito que ele me passou tava escrito assim ó ó ó se cair na regra x O cálculo deve ser bloqueado e o usuário não pode continuar

parece até olhando assim um bom texto de requisito mas aí conforme a gente foi conversando eu comecei a perguntar tá beleza é o que que significa bloquear o cálculo é para você desabilitar todos os campos da tela ou é para alterar o status do cálculo colocar num status tipo cálculo bloqueado e o que que significa esse não continuar que tá escrito aqui não continuar é que tem que exibir uma mensagem tem que desabilitar um botão para ele não poder fazer de novo e aí o Devid não soube responder ele ia aceitar o requisito numa boa

achando que tava tudo certo tudo entendido Quantas vezes você já não fez isso você escuta o pedido do usuário acha até que é é razoável E aí você já sai programando Quando surge uma questão dessas você imagina as coisas você supõe as coisas e aí você faz do jeito que você acha que é o certo você supõe e faz aquilo que você acha é a sua opinião e é aí que o circo tá armado porque o usuário escreveu pensando numa coisa você programou pensando em outra coisa E aí quando começa o teste ou até quando

vai pra produção começa a treta Pô isso aí é bug tá errado ah mas eu fiz o que você pediu então você que não entendeu nada do que eu falei pô mas é porque você também não sabe pedir que é aquele cenário de bang bang que você já viu várias vezes um aponta o dedo pro outro e no final ninguém fica satisfeito com nada E aí não adianta você só formalizar essas conversas mandar tudo por escrito criar um PDF mandar por e-mail depois que você fez e mandou pra produção Já era cara não tem mais

o que fazer aí é só você pegar um balde de pipoca e esperar a discussão começar Então vamos lá pro segundo erro focar demais Em lógica e em Recursos da linguagem Ei mas lá vem historinha programar não é escrever lógica usando os recursos da linguagem de programação e não não é isso programar é resolver problemas toda profissão existe para resolver um problema específico o médico resolve problemas de saúde o engenheiro civil resolve problemas de construção e nós que somos programadores a gente resolve problemas de automação para para pensar de uma forma geral tudo que a

gente faz serve para automatizar alguma tarefa que poderia ou que antigamente era feita manualmente ou talvez até mecanicamente Dependendo do que você faz só que o computador para essas tarefas aí cara ele faz muito mais rápido ele é muito mais eficiente e aí para fazer essas automações a gente cria software Ou seja a lóg o código o software em si ele é só um meio o software é o meio que nós programadores usamos para resolver problemas foi por isso que eu disse que você aprendeu a programar de um jeito errado que não favorece a qualidade

porque esse aí é o jeito que ensin nas faculdades é o jeito que os Dev mais velhos ensin os mais novos que programar É só escrever um montão de lógica que é só usar os comandos da sua linguagem de programação e assim é isso também faz parte da coisa só que não é só isso dá para entender a diferença vamos entender de onde que veem esse pensamento né Essa forma de pensar aí que te atrapalha Provavelmente você conhece ou já ouviu falar de dfd o diagrama de fluxo de dados ele é um desenho muito parecido

com esse daí ó que tem essas caixinhas e tem essas setinha ele serve para ilustrar um processo e provavelmente quando você aprendeu era um processo de negócio as setas elas indicam de onde a informação sai e para onde que ela vai e cada caixinha aqui é um outro processo que recebe uma informação faz alguma coisa ali e retorna alguma outra coisa ela também tem essas outras notações aqui tipo esse losango que indica uma decisão que na prática pra gente aí que é deve seria um if todo mundo sem exceção aprende a programar com base nesse

tipo de desenho aí e talvez você mesmo não tenha visto um dfd na faculdade ou no curso e você acha que não aprendeu com ele mas quem te ensinou a programar Com certeza aprendeu com ele e aí ele te ensinou da mesma forma que aprendeu Então você aprendeu indiretamente com base em dfds é um esquema que é muito bom para visualizar processo porque muito gráfico né Muito visual só que ele tem um problema olhando pro desenho O que que parece para você aí que tem mais destaque são as caixinhas certo porque elas têm nome Elas

são grandes tem até um destaque visual muitas vezes tem cores diferentes Agora presta atenção nas setas geralmente não tem texto aqui não tem identificação tem nada só tem a a seta mesmo e quando tem às vezes é uma informação muito simples né às vezes parece que só tá escrito lá para constar mesmo ou seja olhando para esse desenho eu sei que aqui ó eu vou cadastrar um produto aqui eu vou verificar um estoque mas eu não sei exatamente o que que esse processo de cadastrar pedido vai gerar que que vai sair daqui de dentro ele

só vai incluir o pedido no banco ou será que ele retorno pedido cadastrado com código de cadastro novo eu não tô dizendo que a notação em si é errada porque não tem nada a ver ela tem o seu propósito que é documentar processo só que como a gente usa ela para aprender a programar indiretamente ela ensina uma coisa que é ruim pra qualidade do nosso código ela ensina muito a pensar no como que são as caixinhas do dfd como consultar um cliente como conectar ao banco como calcular esse valor como escrever o if dessa regra

como é a sintaxe desse comando fala a verdade no seu trabalho quando o usuário te explica o requisito quando ele tá ali falando para você o que que precisa que que vem na sua mente você pensa por exemplo em Como testar você pensa por que ele tá pedindo essa funcionalidade você pensa também como que a empresa ganha dinheiro ou como ela perde dinheiro com isso que ele tá te falando ou quando ele fala você já tá pensando Quais são os métodos que precisam ser alterados Você vai precisar criar um campo novo no banco de dados

se vai ser if se vai ser loop eu tenho certeza que é a segunda opção não é isso e a gente não faz esse tipo de coisa de propósito é quase que um reflexo automático do cérebro você foi treinado desse jeito se alguém fala de alterar o software o nosso cérebro ele já começa a produzir imagem do código é um negócio muito louco você começa já a lembrar do código os lugares que você acha que tem que alterar tudo isso é automático desde o começo da nossa carreira nós somos treinados para pensar no como e

é por isso que geralmente os deves associam qualidade a código elegante código Limpo código moderno código padronizado é porque na programação o como se traduz em código então tudo que a gente imagina como sendo um trabalho de qualidade tem a ver com produzir um código melhor escrever código de um jeito melhor e o problema é que focar em melhorar o como né focar em melhorar o código em em si ele não necessariamente resolve os problemas do usuário vou te dar um exemplo imagina que o usuário tem uma planilha Excel super bolada daquelas que até parece

um software para fazer a precificação de um produto por região do país só que a planilha ela tá ficando muito grande né E aí tem muitos dados tem muitas fórmulas e tá começando a dar muito problema aí ele pede para você criar um programa criar um software de verdade né que faça esse mesmo cálculo você como deve olha para aquela planilha maluca e pensa cara que é absurdo como que alguém faz um treco desse né como que alguém faz um negócio dessa importância e desse tamanho dentro de um Excel é óbvio que vai dar problema

é claro que vai dar Vamos fazer um software Porque pô isso aqui vai ser muito melhor aí você vai lá aplica as tecnologias mais avançadas usa a versão mais nova da sua linguagem de programação que é mais perform que é mais elegante Escolhe um banco de dados super rápido faz tudo com microsserviços tudo assíncrono e aí quando você entrega o valor dos produtos sai todo errado e não bate com a planilha ou seja Você investiu um tempo enorme para fazer tudo perfeito com as melhores tecnologias da atualidade o melhor código possível e o seu usuário

continua no Excel E aí você fica lá no desespero para arrumar os bugs do seu software super moderno mas que não serve para nada e é claro que isso aí é só um exemplo tá eu tirei da minha cabeça qualquer semelhança com a vida real aí é só coincidência beleza deu para entender que focar no como no código não te ajuda o tanto quanto você imagina e eu vou reforçar eu não tô dizendo aqui que a parte tecnológica da programação que ela não é importante não é isso Beleza programadores precisam saber programar você precisa dominar

a linguagem precisa conhecer tecnologias precisa saber implementar os melhores recursos para cada situação o lance é que não é só sobre tecnologia não é só sobre código tem outras coisas que você precisa aprender para entregar um software de qualidade um código que resolve o problema do usuário que é fácil de manter e que não tenha bugs e o que resolve o problema do usuário é o resultado esperado é aquilo que o seu código processa e entrega só que aí eu já tô dando spoiler da aula dois aqui vou cortar esse assunto por aqui porque você

vai ver isso na próxima aula por enquanto foca aqui na lista de erros e o terceiro erro escrever código lingui código linguição são aquelas classes e métodos gigantescos e tem gente que chama essas classes de God objects ou God classes porque eles fazem tudo e aparecem em todo lugar do seu projeto você abre o arquivo da classe e ele tem lá 5.000 linhas vai mexer no método 500 linhas Esse é o tipo de coisa que você sabe que não é bom que todo curso todo Livro fala para não fazer Mas você continua fazendo e assim

tá tudo bem acontece com todo mundo e tem um motivo também para isso acontecer como o seu cérebro tá sempre focado no como você cria o hábito de escrever a sua lógica de uma forma linear fazendo um download realmente das suas ideias aqui do cérebro direto pro editor de código ou seja tudo que precisa ser feito regra de negócio interação com banco de dados chamada de api vai tudo pro mesmo L você pega aquele desenho lá do dfd e transforma em código numa tacada só e aí vira aquele linguição de código você sai digitando tem

as ideias digita tudo no mesmo método e quando você vai ver você criou um método lá de 500 de 1000 linhas e não adianta falar que você não faz que essas coisas aí já existe na empresa que você não tem nada a ver com isso e que você não é pago para ficar arrumando também tudo de ruim que tem lá se você nunca fez um código linguição pode ter certeza que você já contribuiu para que um código desse aí aparecesse no software que você mexe hoje até porque geralmente esse tipo de coisa não Brota do

chão não é numa atacada só muitas vezes ele não começa com 1000 linhas o método gigante ele começa com 50 100 linhas só que aí precisa fazer uma alteração na regra né E aí tem que chamar Api para pegar seus dados lá depois tem que fazer um update num banco lá no registro aí você inclui uma query também para verificar se existe Depois você coloca outra query para fazer um update pô aí você descobre que precisa incluir uma outra regra E aí já existe uma lógica bem parecida ali só que tá em outra classe e

aí que que você faz você copia regra de um lugar e cola no lugar que você precisa E aí em questão de semanas o método que tinha 100 linhas agora tem 500 linhas e muitas vezes essa bagunça toda aí ela ainda se disfarça de método privado a classe ela só tem um método público que tem lá suas 300 linhas e tem 20 métodos privados com 100 linhas parece né aparentemente ali que não é tão ruim mas quando precisa alterar você vê que era só propaganda enganosa e tá tudo bem se você escreve o código assim

na maioria das vezes ele vai funcionar em produção O problema é o que você faz depois de escrever esse código Ou melhor o problema é o que você não faz depois de criar ou alterar o código linguição você inicia debug testa uma ou duas situações ali só para ver se entra nos ifs né E para nos Break points para dar uma olhada nas variáveis e aí se não deu nenhum erro Já era cara tarefa finalizada manda paraos testar ou então já manda logo pra produção né porque o prazo tá apertado ali tudo é muito urgente

e se der algum problema cara a gente corre para arrumar Ou seja você vomitou um monte de código ali dentro do software nem sabe se ele atende usuário faz um teste mais ou menos e entrega do jeito que tá com métodos de 1 linhas mesmo aí depois você fala que não dá para melhorar porque você não tem tempo porque você não tem conhecimento técnico suficiente porque te ensinaram que criar um código fácil de manter é coisa de Dev Senor que é coisa de arquiteto de software e aí você vê na internet que nem tem como

fazer teste unitário um método gigante desses pô Como que eu vou testar um método de 1 linhas não tem como é muito difícil só dá para fazer teste manual mesmo usando debug E aí no dia que você for Sênior no dia que você for arquiteto no dia que você tiver muito conhecimento técnico ou até no dia que o seu projeto tiver mais tranquilo aí você vai lá refaturar aí você vai lá tentar testar o seu código direito e aí quando esse fatídico dia chegar finalmente você vai entregar software de qualidade você vai conseguir mostrar que

você faz um bom trabalho um trabalho melhor do que os outros e aí você vai ter o seu trabalho devidamente reconhecido só que esse dia ele não chega nunca sabe por quê não é porque você é incompetente ou que você não sabe trabalhar direito é que na próxima alteração você tá sem tempo de novo porque cara a vida é corrida a gente tá sempre atrasado tudo é sempre muito urgente eí na próxima alteração você ainda não virou sor na próxima alteração você ainda não estudou o suficiente falta conhecimento técnico aí não dá para fazer um

código melhor vai tem que entregar código linguição mesmo de novo e no código linguição não dá para fazer teste como que vai testar método de mil linhas não tem como então deixa pra próxima quando a situação for melhor quando o projeto estiver mais tranquilo de novo você percebeu como isso é um ciclo você percebeu que isso aí é uma roda do rato que você não entra porque você quer é que a vida a carreira o dia a dia tudo acaba te empurrando para lá e aí você não consegue sair disso é difícil é difícil porque

essa roda ela gira rápido demais é prazo é urgência é bug de produção e cara tem boleto para pagar se você não continuar girando roda vão te mandar embora mas você percebe que esse ciclo ele é retroalimentado por um monte de coisas que você aprendeu errado ou então coisas que não te ensinaram não é impossível de sair não é um negócio que só depende da empresa que tá tudo fora do seu alcance Você precisa aprender as coisas certas para descobrir onde fica a saída beleza André Mas então como que eu vou aprender essas coisas como

que eu quebro esse ciclo que que eu tenho que fazer para sair dessa porcaria dessa roda do rato e é isso que você vai ver na próxima aula da jornada desenvolver testes então ó só para recapitular o que que você aprendeu hoje os três maiores erros dos devis que acabam com a qualidade do software Primeiro Erro fazer tudo que o seu usuário pede por mais que você ache que o usuário conhece muito bem o software e que ele sabe tudo que precisa ser feito na maioria das vezes ele não sabe e é isso que gera

aquelas discussões sobre o que que é bug o que que não é bug e faz você entregar um software que não resolve problema do usuário nenhum segundo erro focar demais Em lógica em Recursos da linguagem não adianta fazer o software mais moderno do mundo se o seu usuário prefere usar planilha Excel e faz tudo que ele precisa do jeito certo e o terceiro erro escrever código linguição você entrega código ruim e nunca Melhora você entra no lup infinito porque falta tempo falta conhecimento falta experiência e no final das contas é só código de mil linhas

e para encerrar eu quero te lembrar que na próxima aula da jornada desenvolver testes você vai descobrir quais são as quatro coisas que todo deve precisa saber para entregar código de qualidade e essas coisas vão te ajudar a evitar esses três erros que aprendeu hoje então ó fica de olho lá no seu e-mail no grupo do WhatsApp que eu vou te avisar assim que a aula do estiver no ar e se você tiver qualquer dúvida ou se você quiser conversar sobre essa aula deixa um comentário aí no vídeo que eu pessoalmente vou ler e vou

responder tudo que eu puder beleza um grande abraço e até a segunda aula