Bom pessoal, seguinte, aqui eu quero trazer um exemplo para vocês de Fitness Functions baseado em três atributos que eu vou dar aqui para o nosso software. Obviamente, dependendo do tipo de criticidade do seu sistema, dependendo da característica do seu sistema, você vai utilizar, obviamente, mais categorizações e outros tipos de categorizações. O que eu vou trazer aqui são alguns pontos que, às vezes, a gente acaba esquecendo de medir. Legal? Então, como que eu começo a trabalhar com esse cara aqui? Então, eu tenho aqui minhas fitness functions e eu quero ir aqui para a minha primeira característica, que é performance. Então, quais são os pontos que, na minha minha opinião são importantes para a relação em performance vamos imaginar que o response time latência pra mim é extremamente importante em relação à performance perceba não estou colocando nem truputti aqui eu poderia colocar eu poderia colocar todos os pontos que eu acho importante então o que é na parte de performance como eu estou definindo é a média do response time dos endpoints críticos baseado numa carga específica então baseado numa carga que eu tô dando eu quero saber qual que é a média dos endpoints mais críticos que eu vou trabalhar perceba que eu não estou olhando apenas um endpoint você pode até fazer um drill down em relação a tudo isso mas o grande ponto que eu estou trazendo aqui é qual é a média do response time que eu estou trabalhando. Então, baseado nisso, o que eu vou fazer? Eu vou atribuir um score, né? E em quanto o response time pode ser comparável a uma meta estabelecida. Então, nesse caso aqui, se você olhar, eu criei um exemplo para vocês darem uma olhada. Essa quantidade de pontos, esse tipo de coisa, é totalmente arbitrário. Você vai definir isso. Isso aqui é um exemplo que eu estou dando baseado em um sistema que tem uma certa necessidade. Cada sistema tem uma necessidade. Então, por por exemplo excelente eu vou medir aqui com um ponto é todo o sistema que pra mim está excelente tem um ponto e significa que o respons time dele está menor ou igual a 200 mil segundos então chamando minhas apis a média é menor ou igual a 200 mil segundos está excelente agora se tiver bom eu vou dizer que é 0.8, e isso significa que é uma chamada que vai demorar entre 201 a 300 milissegundos. que dá 0.4 pontos. E aqui, ineficiente, ine... ine... Ah, não, é inaceitável, não está certo. É 0 pontos, ou seja, toda vez que eu bater aqui para mim a média de criticidade dos meus endpoints aqui, se forem acima de 500 milissegundos, é inaceitável aqui para mim, então eu vou dar zero pontos. Legal? Então aqui é um exemplo de performance. Perceba esses pontos da forma como eu estou trabalhando, eu estou delegando de forma arbitrária aqui. Vamos falar sobre confiabilidade. O que é confiabilidade? É a que a confiabilidade habilidade um sistema se recuperar de falhas né ou seja o qual eu posso confiar naquele sistema e como que eu consigo verificar isso né como que eu vejo se o meu sistema confiável a cada pessoa pode ter uma métrica diferente eu tô trazendo duas aqui para vocês que é o mbf e mttr o que significa as métricas elas podem ser um mtbf que é o min time between férias ou seja é o tempo entre uma falha e outra o que significa essa na minha opinião uma das principais métricas, pessoal. Se toda vez que você tem falha, quanto tempo está durando entre uma falha e outra? Eu tive um problema hoje, daqui 30 dias eu tive um outro problema. Então significa que o meu MTBF foi de 30 dias, ok? E a gente tem um outro ponto importante aqui que é o MTTR, que é o Meantime to Recover. Ou seja, quanto tempo eu demorei para me recuperar de uma falha. Então, assim, se você perceber, são duas métricas extremamente importantes, mas elas visam coisas diferentes. Por exemplo, eu tive um problema e assim que eu resolvi esse incidente, eu demorei 10 minutos para botar o sistema no ar. Então, isso significa que o MTTR é 10 minutos. Perfeito. Ok? 10 minutos aqui para mim. Porém, 10 minutos é muito ou é pouco? Depende do tipo de sistema que você tem. Por outro lado, o MTBF vai ver, poxa, não adianta você se recuperar em um minuto e você ter um problema de falhas a cada um dia, entendeu o que eu estou querendo dizer? Então, às vezes, você tem um problema de falha, que você demora uma hora para se recuperar, mas você teve isso a cada dois anos, que eu acho bem difícil, né? Então, olha só que interessante. Então, são dois aspectos importantes para eu verificar a confiabilidade do meu software. Então, um exemplo aqui. Um excelente, um ponto. Então, se o MTBF for maior ou igual a 30 dias e o MTTR for menor que 2 horas, eu estou falando que está excelente. Se tiver o MTBF maior que 20 dias e o MTTR menor que 4 horas, eu estou falando que é 0.8. Aqui a mesma coisa. Se for maior ou igual a 10 dias e menor ou igual a 6 horas, ruim, inaceitável. Se eu tiver um erro entre falhas menor que 10 dias ou MTTR maior que 6 horas. Então olha só que interessante que a gente acaba tendo aqui, galera. Eu vou até colocar um ou aqui, daí vai depender muito. Mas eu acredito que vocês entenderam a ideia, tá? A grande sacada aqui é você conseguir criar métricas, pontuar essas métricas e daí para a gente conseguir trabalhar. Mantendo habilidade, como que eu consigo dizer que o meu software está bom para eu conseguir manter? Como que eu consigo pegar métricas em relação a isso? Então, pode ser uma pancada, até mesmo o nível de complexidade, o nível de acoplamento, o nível de coesão que você tem. Então, basicamente, a mantenabilidade, ela descreve os custos ao longo do tempo, a longo prazo, baseado em uma baixa qualidade de design ou decisões de implementação. Então, toda vez que o meu software é ruim de manter, significa que provavelmente eu tomei decisões que não foram tão boas ou essas decisões eu tive que tomar correndo e isso acabou também uma baixo design que vai gerar uma degradação no software conforme o tempo vai passando. Quais métricas que eu posso utilizar? TDR, Technical Depth Ratio. software conforme o tempo vai passando quais métricas que eu posso utilizar né tdr technical de rei tcheco então ele vai medir a taxa de problemas conhecidos no código code smells bugs ou vulnerabilidades em relação a todo o software quanto menor essa taxa melhor sabe aquele software que você sabe que aquela parte que tem que refator ar ou você sabe que tem um bugzinho ali mas como ninguém usa aquela parte eu tô deixando passar porque tem coisa mais é importante ali ou aquela vulnerabilidade mas ninguém se tocou e você está botando a sujeira embaixo do tapete então isso aí é uma taxa que você vai medir que são basicamente a dívidas técnicas. E lembre, galera, você não fala débito técnico. Você fala dívida técnica. Débito é debitar algo. Dívida é o que você deve. Debt, em inglês, significa dívida. Não significa necessariamente débito. Beleza? Não significa necessariamente débito, beleza? Ou aqui um outro aspecto que você tem aqui é esforço de remediação, tá? Remediation effort. O que isso significa? É estimativa do esforço para um desenvolvedor resolver problemas conhecidos. Normalmente ele é baseado em pessoas por hora ou por dia. O que isso significa? normalmente ele é baseado em pessoas por hora ou por dia o que significa eu tenho aquele monte de débito técnico olha só débito técnico ou dívida técnica eu tenho um monte dessas dívidas técnicas e eu sei que para resolver aquele problema vai demorar 40 horas de um desenvolvedor legal então quando você sabe tem uma estimativa de quantas horas você vai ter para resolver, você consegue colocar isso na conta. Wesley, como que eu consigo ver isso? Depende muito, tá? Mas, por exemplo, existem softwares que fazem análise estática de código, que baseado nisso, ele consegue gerar e verificar codes, mails, complexidades no código, e ele consegue gerar ali para você uma estimativa de quanto tempo demora, tá? Eu vou dar um exemplo, o Sonar Cube, ele faz isso, por exemplo, legal? Então, mais um exemplo aqui de tabelinha, né? Exemplo, excelente, um ponto, né? Se o TDR for menor que 5% e a remediação for menor ou igual a 10 pessoas por dia. 10 pessoas não, 10 horas por pessoa por dia. Bom, 0,8%. Se eu tiver 8% e a remediação for de 10 pessoas a dia, é isso mesmo. 10 horas por dia, né? Ou 10 dias por pessoa. Então depende muito da unidade de medida que você vai utilizar. Ruim, 0.4. TDR, 12%, né? Inaceitável, né? Maior que 12%. Então, esses atributos você que vai definir. No próximo vídeo vídeo para não ficar muito grande eu vou mostrar pra você como que você faz uma consolidação é bem simples para você consolidar isso mas você tem que ter alguns critérios aí então a gente vai falar disso nosso próximo vídeo