Author Archives: cmilfont

Quanto testar?

Uma métrica que sempre tenho dificuldade de aferir é o retorno sobre o investimento no aumento da quantidade de testes do sistema.

Quando falo em testes aqui eu falo no conjunto de todos os tipos de testes, como: unitários, aceitação, integração, carga e demais necessários. A cobertura de testes é um investimento para redução de bugs na fórmula de ROI. Bugs são como “Back Order” na indústria e comércio, além de lucro perdido pela não-venda da mercadoria, ainda fragiliza a marca.

Um ponto crucial: EU ACREDITO EM COBERTURA DE 100%, mas não existe cobertura de 100%, então como podemos conviver com esse paradoxo?

Cobertura de 100% é uma meta ambiciosa de um mundo feliz onde não nos preocupamos com custos e escassez, ou seja, uma utopia. Utopia na vida real não é vendável, precisamos [mesmo a contragosto] medir os dados reais e encontrarmos um padrão aceitável.

Sabemos por consequência que testes aumentam a qualidade do software, eu não tenho tanto problema quanto antes em vender testes de software, mesmo a empresa que não tem testes automáticos, sabem da importância de se testar o software [mesmo que manual].

Meu problema atual é como conseguir vender o aumento da cobertura, mas antes disso eu mesmo preciso entender até quanto testar é suficiente para se pagar.

Power Law

Conversando dia desses na Fortes com o Clavius Tales sobre o seu post de mesmo preocupação, ele me explicava porque encontrou uma função logarítmica e eu tive o mesmo sentimento em dois pontos: que o aumento de testes por mais insignificativo que seja já provoca uma redução drástica de bugs e que ao passar do tempo você tem a impressão de que os testes já não trazem mais retorno, como vocês podem ver no grafico abaixo. Vou chamar esse ponto de “Ponto de Acomodação”.

Funcionalidades x Testes x Defeitos

Fonte da imagem: Blog do Clavius Tales.

Comentei com o Tales que concordo que a função seja mesmo logarítmica, mas que tenho a impressão que a curva é um pouco mais acentuada e o “Ponto de Acomodação Ideal” que deveria ser o “Ponto G” no mundo real é algo entre ele e o “Ponto B” e que devemos ir mais além. No gráfico do Tales ele mostra dois pontos de acomodação, o real no Ponto B [que é um engano e as empresas devem buscar sair dessa área] e o “ideal” no ponto G, aqui tratado.

Então temos dois fatores novos, a curva mais acentuada e o ponto de acomodação, que é o ponto onde as pessoas sentem que não adianta mais testar porque o inicio de testes já reduzem significativamente o número de bugs. Esse ponto de acomodação pode ser explicado por Pareto que é algo que funciona aproximado em quase tudo na vida, dizendo que 20% de alguma coisa geralmente representa 80% do todo.

Tenho ainda um terceiro sentimento provocado pela minha experiẽncia com testes, quanto mais testes nós fazemos, mais cedo detectamos bugs e sempre há pelo menos uma inconsistência que não tinhamos “pensado” antes. Pode até ser que seja finito a quantidade de testes necessários no sistema, mas esse número é muito grande e nunca consegui alcançar na prática, sempre há bugs.

Considerando esses fatores somados, podemos usar os cálculos do Power Law ou cauda longa para melhorarmos o gráfico original do Tales de forma mais aproximado da redução de bugs com o aumento constante de testes no sistema.

Fonte da imagem: Wikipedia

Considero que a meta de cobertura de 100%, mesmo sendo irreal, é algo a ser buscado sempre, forçando o time a se policiar e aumentar o número de testes constantemente mesmo após a acentuada queda de bugs [que chamei de “Ponto de Acomodação”] e que 100% de cobertura não quer dizer livre de bugs porque a cauda sempre vai ser um número aproximado mas nunca toca o zero na prática. Esse caso se aproxima da regra de 98%.

Considero também que dependendo da necessidade de software em produção um número aceitável de bugs a partir do “Ponto de Acomodação” não trás tanto retorno de investimento a curto prazo.

Vou começar a coletar informações de dois projetos atuais para verificar se a tendência desse gráfico satisfaz a realidade. Por enquanto preciso de mais informações para chegar a conclusões melhores.

Typically chemist’s shop can sale to you with discreet treatments for various health problems. There are numerous of safe online pharmacies that will deliver medications to your address. There are divers medicines for each afflictions. Learn more about “viagra manufacturer coupon“. Maybe “viagra discount coupons” is a so complicated matter. Matters, like “coupons for viagra“, are coupled numerous types of health problems. If you need to take prescription medications, ask your dispenser to check your testosterone levels before. Sometimes the treatment options may include erectile dysfunction remedies or a suction device that helps get an hard-on. Keep in mind web-site which is ready to sell erectile dysfunction drugs like Viagra without a prescription is fraudulent. When you purchase from an unknown web-site, you run the risk of getting counterfeit remedies.

Frameworks Caseiros 2: A missão

Eu participei como desenvolvedor de 4 projetos em Java nos últimos 12 meses, 3 deles tinham algo em comum: tinham uma arquitetura de referência, mais de 4 anos, baseados no struts 1.x, framework caseiro desenvolvido em cima do struts, modicações caseiras em APIs conhecidas sem contribuição com o projeto original [fork antigo ainda por cima], código altamente acoplado e sem coesão, arquitetura baseada em BOLOVO e principalmente sem testes [o último até que estava com uma tentativa de testes de aceitação com o Selenium mas com grandes dificuldades por conta de todos os problemas].

Em projetos antigos é comum encontrarmos esse tipo de situação, eu mesmo já criei meu framework caseiro em coisa por volta de 6 anos atrás, mas hoje em dia isso não só é algo abominável como um desrespeito pelos profissionais, ainda mais após tanta evolução nos últimos 10 anos.

Conversando com um amigo que trabalha em uma grande empresa de planos de saúde, ele me falou que o “arquiteto java” dessa empresa [conhecido por sua fama de criador de “Framearras”] convenceu a diretoria sobre um projeto recente que se baseia no desenvolvimento de um framework específico para a empresa [eles já possuem um framework caseiro que é um terror e bem conhecido por grande parte dos desenvolvedores locais].

É impressionante como não acaba essa tara de desenvolvimento de frameworks caseiros, qual a necessidade de uma empresa que tem TI como meio [e não como fim] de desenvolver um framework para desenvolvimento de software?

Olha que não é de hoje que eu falo sobre os perigos de frameworks caseiros, mas parece que os defensores desse tipo de abominação se reproduzem como coelhos.

Engraçado que no último projeto que participei eu recebi um treinamento de um dos criadores do framework caseiro que deveríamos usar na construção, alias na continuação de um sistema que está há 5 anos em desenvolvimento sem sinal de algo ir para a produção.

Os argumentos que ele usou foram os seguintes [anotei a frase para não esquecer]:

“Amigos, é importante um framework criado pela propria empresa para padronizarmos o desenvolvimento, diminuindo a curva de aprendizado e ganharmos na produtividade, utilizando padrões consagrados, obtendo reuso nos componentes de negócio e garantindo a manutenibilidade pela fácil criação de código, principalmente CRUD.”

Segredo do fracasso

Vou expor algumas considerações sobre essa frase dele:

Curva de aprendizado

Se algo é complexo de entender por quem conhece os padrões daquilo que se deseja desenvolver, é porque não serve mesmo. Não há como comparar um software opensource consagrado no mercado onde centenas de milhares de desenvolvedores já aperfeiçoaram com algo feito em casa.

Ganho na produtividade

A desculpa número um de todo framework caseiro é a famosa produtividade, sendo que voce sempre perde produtividade porque insere algo fora da normalidade no cotidiano do desenvolvedor. Além do que é insano voce ter uma produtividade no inicio – se fosse o caso, já que não é – comprometendo todo o ciclo de vida restante da aplicação por conta disso.

Porque é isso que acontece, todos esses frameworks caseiros são pensados e desenvolvidos para facilitarem a construção de CRUDs no inicio da aplicação e você tem que sacrificar todo o resto para satisfazer esse capricho que pode ser automatizado facilmente com tecnologias atuais.

Utilização de padrões

Ninguem pode saber que padrão utilizar antes de saber qual o problema, isso é impossível. Ou vai usar um martelo para furar uma parede ou uma furadeira para pregar um prego.

Reuso de componentes

Não existe reuso de objetos de negócios, nenhum processo é semelhante nem que seja na mesma organização ainda mais tentando reusar código por meio ide interface gráfica comum em projetos com dificuldade incial até de separação de pacotes.

Uma alternativa geralmente usada é se comunicar via API ou uma estrutura de serviço como WS, JMS, whatever e não aproveitando uma tela em um sistema distinto.

Aumento da manutenibilidade

Sistema como Frameworks caseiros sempre são dificeis de manutenção por que falta documentação, gente que conheça realmente [além dos próprios criadores], código sempre acoplado, falta de testes, maturidade, e principalmente propósito real [como não haver um existente no mesmo segmento].

Em todos os frameworks caseiros que trabalhei e não foram poucos, a manutenção é algo punitivo porque temos que satisfazer o framework e não o negócio.

Garantia da qualidade

Não há qualidade alguma em frameworks caseiros, pelo contrário, pelo conjunto de más práticas já expostas, o que acontece na realidade é que os sitemas desenvolvidos com esse tipo de ferramenta apresentam uma qualidade baixíssima.

Fork em frameworks do mercado

Problema em fazer um merge no futuro, voce não terá tempo e recurso suficiente para isso. Melhor solução seria submeter patch e codigo para o framework original e acompanhar o desenvolvimento deste. Deixa o desenvolvimento preso a versões antigas.

Associado a cascata.

Quase impossível você encontrar um framework caseiro em uma equipe ágeil, até porque isso fere vários dos valores e princípios.

Menos codificação

Na verdade duplica a codificação para satisfazer o framework.

Extensão de classes genericas

Acoplamento, referencia cíclica, etc… dá até preguiça de escrever.

CRUD Driven Design

Quebra o principio do XP que é fazer o mais importante e crucial primeiro, CRUD nunca é o mais importante. Se voce faz o CRUD primeiro, cria a regra de negócio e refaz todo o CRUD depois.

Geração de codigo sempre reescreve as informações, merge manual.

Frameworks caseiros são #ESFM. Vão complementando com as más práticas…

Typically chemist’s shop can sale to you with discreet treatments for various health problems. There are numerous of safe online pharmacies that will deliver medications to your address. There are divers medicines for each afflictions. Learn more about “viagra manufacturer coupon“. Maybe “viagra discount coupons” is a very much complicated matter. Matters, like “coupons for viagra“, are coupled numerous types of heartiness problems. If you need to take prescription medications, ask your pharmacist to check your testosterone levels before. Sometimes the treatment options may switch on erectile dysfunction remedies or a suction device that helps get an erection. Keep in mind web-site which is ready to sell erectile dysfunction drugs like Viagra without a prescription is fraudulent. When you purchase from an unknown web-site, you run the risk of getting counterfeit remedies.