Bom pessoal, então baseado aqui nessas Fitness Functions, né? Vamos tentar entender um pouco mais claramente como que isso acaba se comportando. Vamos lá! Toda vez que a gente falar sobre Fitness Function, no final das contas a gente está falando em é uma forma de medir a efetividade, a performance e fatores relevantes de acordo com a arquitetura de um só é isso que você tem que pensar na hora que a gente fala em fitness fun a gente está falando em medir verificar o quanto isso é efetivo como que o software ele está performando e essa performance aqui não é performance necessariamente de velocidade é uma performance de como ele consegue entregar aquilo que ele foi feito para fazer legal quais são fatores que são importantes inclusive para esse software conseguir fazer diferença legal outro ponto importante aqui sobre fitness functions seguinte elas são definidas baseadas em diversos critórios incluindo nesse caso performance modularização mantenabilidade escalabilidade segurança legal então toda vez que você vai pensar uma fitness function você pensa quais são os critérios que fazem muito sentido aqui pra mim para eu conseguir medir né que o meu software está evoluindo? O que faz sentido? Se é um software que precisa de muita performance, poxa, vamos medir como é que está o nível de complexidade no meu código. Vamos ver como é que está a complexidade ciclomática ali no meu código. Ah, o meu código ele tem um monte de componente vão medir como é que está a relação entre os componentes desse software eo complexo aquilo tá ficando eu tenho um monte de classe uma classe a ponto para outra eu tô ficando com muita herança né eu tô trabalhando com diversas coisas no meu software eu consigo começar a medir o nível de complexidade né há pessoas que dependendo da forma como a empresa se organiza né elas tentam ao máximo evitar comentários no código então isso começar a medir a quantidade de comentários que eu tenho no meu software baseado nesse comentário eu começo a pensar toda vez tem um comentário eu tenho uma red flag aí então baseado na quantidade de comentários eu posso conseguir colocar um trecho hoje ali que eu tenho que tomar cuidado com o software se eu tiver um software que é só comentário mas entenda tá quando estou falando aqui de comentário comentário é uma coisa documentação é outro eu vou dar um exemplo a linguagem gol por exemplo né como que você documenta a linguagem através de comentários entendeu mas aquele comentário ele tem o objetivo de gerar a documentação agora a gente tem comentários por exemplo que ele vai falar o seguinte olha esse pedaço estou fazendo assim porque ele vai calcular a taxa de juros ele vai dividir e isso é baseado de acordo com aquela tabela que foi passada naquele dia aqui para mim. Esse tipo de comentário, eventualmente, pode ser um malefício para o software, quer dizer que o meu software não está expressando aquilo que ele deve fazer. Isso aí é uma polêmica, principalmente por conta do livro do Clean Code do Uncle Bob, que ele fala que não deve ter comentário, etc. Obviamente eu não trabalho de uma forma ferro e fogo, muito código meu, que em alguns pontos que eu acho complexo, eu coloco comentário inclusive, mas aí, novamente, será que eu estou colocando comentário porque é complexo, ou o meu código ficou complexo por isso que eu tenho que ter comentários então cada empresa tem uma maneira de forma geral de medir a complexidade que o software está ou em relação entre classes em relação à herança a quantidade de linhas dentro de um arquivo a quantidade de linhas do tamanho do meu software ou por exemplo tem muita gente que começa a medir o software o seguinte, toda vez que o domínio do meu software começa a mudar muito, significa que eu vou ter mais instabilidade no meu software. Então, e se a gente medir a quantidade de mudanças que a gente tem no core do software? Se a gente tem muita mudança aqui, dizer por exemplo que eu tenho algum problema né ou eu posso fazer medições em relação a parte de coesão toda vez que eu mexo no arquivo eu tenho que mexer em outro toda vez que eu mexo numa parte eu tenho que mexer em outra quer dizer que provavelmente está faltando coesão no meu software. Toda vez que você tem que mudar alguma coisa, você tem que sair mudando em outros pontos, quer dizer que pode ter um cheiro ruim. A gente tem um bad smell aí no seu software, então você pode querer medir isso. Então depende muito de cada tipo de software. Se é um software que precisa de muita performance, obviamente, alguns desses pontos você vai querer medir. Legal? Agora, se são softwares que ele precisa ou eles têm outras características, às vezes isso aí para você é irrelevante. Então, olha como que é importante você ter esse tipo de visão. E esse tipo de visão só vai ter se você conseguir medir daqui a pouquinho já vai falar pra você como que a gente medir eu vou dar um exemplo claro aqui pra vocês outro ponto importante é o a fitness function ela vai acompanhar o seu software a sua evolução se é pra acompanhar significa que você vai ter dados, e não somente dados, você vai ter dados conforme o tempo vai passar. Legal? É dados baseado no tempo. E conforme os tempos passam, você vai ter uma taxa. E daí, quanto maior essa taxa, melhor o seu software está, quanto menor menor essa taxa mais se degradando no seu software ele vai tá o grande ponto é que partes desses atributos que a gente acabou olhando no nosso software ele simplesmente tem pontos que têm mais peso né sei lá comentário pode ser algo crítico então não vou dar um peso tão grande caso eu tenha muita complexidade na parte sei lá se começa a pegar é fazer verificação de algoritmos e o nível de complexidade seus algoritmos você pode dar mais ao response time que pra mim é muito importante então este é um peso maior do que comentário. Ah, o débito técnico, ele é tão importante quanto o performance para mim, para eu conseguir controlar esses tipos de coisa. O tempo de recuperação quando o meu software cai do ar. Então, esses tipos de pontos são importantes porque são métricas que vão verificar a holisticamente como seu software ele tá beleza e o que acontece uma vez que você consegue verificar os aspectos mais críticos e os menos críticos colocados ali no seu software você vai conseguir ter essa métrica agora o ponto é o seguinte como assim são os pontos críticos o grande ponto é que muita gente, quando começa a trabalhar com essas fitness functions, eles querem medir tudo. E às vezes, sei lá, o cara vai querer medir todos os endpoints e ver o response time. Será que é preciso realmente fazer isso? Por isso que a gente tem que pensar no nível de criticidade. Poxa, eu tenho 50 endpoints na minha aplicação, mas 80% dos endpoints das chamadas estão batendo nesses 20% desses endpoints. Poxa, eu vou medir somente esses 20%. Esses caras aí são os mais importantes. Esses caras aí que podem gerar mais lentidão e mais impacto no meu software. Então, por isso que a gente precisa identificar os aspectos críticos do sistema tá é identificação de pontos críticos você não precisa ficar querendo medir o software inteiro senão daqui a pouco a gente começa a cair novamente naquele efeito torre de marfim ivory tower onde o arquiteto ele está tão descolado da realidade o software está com tanto débito técnico e ele está querendo ver aquele detalhe daquele endpoint que faz um ano que ninguém acessa entendeu então esses pontos aí são importantes agora a grande questão aqui dessas fitness functions é como que eu consigo medir Wesley você está falando muita teoria. Como que a gente consegue ir para a prática e pensar nesses aspectos? Então, a gente vai fazer isso no nosso próximo vídeo. Vamos nessa!