DEV Community: Régis Melgaço de Andrade

Você sabe refatorar mesmo?

Régis Melgaço de Andrade — Tue, 21 May 2024 13:43:42 +0000

"Na minha empresa não temos tempo para refatorar."
"Refatorar é sempre um parto."

Se essas frases fazem parte da sua realidade, talvez esteja na hora certa de ler Refatoração: Aperfeiçoando o Design de Códigos Existentes

Para quem esse livro é interessante

Meus parabéns ao Martin Fowler e Kent Beck, apesar de eu gostar de criticar muita coisa e até ter tentado achar problema onde não tinha nesse livro, eu gostei bastante da obra. Ao meu ver, Refatoração: Aperfeiçoando o design de código existentes é uma ótima leitura para todas as pessoas interessadas em escrever software que seja maior que o resultado de um hobby, e acaba sendo bem educativo até para pessoas que não escrevem código e são responsáveis por produtos de software.

Esse grande elogio que faço se deve à excelente aula feita, não somente o que é refatoração ou regras vagas, mas sim a tudo o que é discutido no entorno da disciplina da refatoração. Aqui também é dita a importância da refatoração, quando devemos refatorar, como refatorar, como podemos incorporar a refatoração a correria, como podemos vender a refatoração a gerência, como refatorar com segurança e outras coisas que devo estar esquecendo.

É interessante dar ênfase que esse livro é especialmente importante para as pessoas que tem qualquer sentimento negativo a respeito de refatorações, como pessoas que já passaram por iniciativas traumáticas de refatoração, pessoas que tem medo de refatorar alguma base de código e até mesmo pessoas que trabalham em empresas onde não tem espaço para refatoração e outros tipos de cuidados com o software.

Para quem esse livro não é interessante

É claro que essa obra não é especial ao ponto de todos precisarem ler. Desconsiderando quem tem domínio do assunto sem ter lido esse livro, o que é um feito, o público que não aproveitaria seria as pessoas que querem fazer código que não terá uma escala média ou grande, buscando construir um software descartável.

Fazer somente código descartável não necessariamente é um problema, muitos problemas precisam de software de pequena escala. Mas eu acredito que não é algo a ser almejado profissionalmente, considerando que melhores condições de trabalho vem na construção de produtos que deixam um legado.

Qual a proposta do livro

Como é fácil de imaginar, aqui foi discorrido sobre a disciplina da refatoração: explicando do que se trata, demonstrando como o autor refatora, explicando a importância dessa prática, explicando quando refatorar e por fim é explicando como fazer isso de maneira segura e prática.

Começamos por um exemplo extenso sobre o que e como é a refatoração a qual o autor se refere no decorrer do trabalho. Prendendo o leitor de refém da curiosidade com diversas perguntas como “por que ele fez isso?” ou “como eu posso fazer isso no meu trabalho?”. Realmente algo esperto para que o leitor leia tudo que o autor escreveu.

Meu capítulo favorito foi o segundo, que se propõe a explicar a importância da prática, que me pareceu especialmente valioso. É muito comum termos várias noções sobre o que precisamos fazer nos projetos ao mesmo tempo que falhamos em conseguir defendê-las com qualidade, como era o caso para mim quando se tratava de refatoração. Foi muito prazeroso ver a explicação profunda sobre as vantagens de se ter a refatoração frequente do código, sendo ela palpável, simples e diretamente relacionada ao cliente e empresa. Vale salientar que é responsabilidade da engenharia esclarecer a necessidade da qualidade do projeto, como um engenheiro que é responsável por dizer que o prédio vai cair, devemos dizer que o projeto não poderá continuar evoluindo no mesmo ritmo se não valorizarmos a qualidade.

Também é discutido ao longo do livro sobre design de software das partes mais unitárias do software, trecho o qual eu acabei discordando um pouco do autor. Minha visão sobre design de software acaba por ver a usada por Martin como excessiva, dando uma sensação de açúcar sintático em certos momentos como quando discute bons tamanhos de função. Pessoalmente me alinho mais com outros autores como John Ousterhout em A Philosophy of Software Design, que tendem a ter uma abordagem que tenta não refatorar antes do problema surgir, para não corrigir problema que não existe ou prever algo que nunca acontecerá. Apesar disso, foi bem proveitoso para mim ter essa nova perspectiva, e provavelmente minha visão sobre design de software foi alterada.

Por fim é explicado como podemos refatorar de forma segura, o que envolve testes automatizados e uma metodologia para mudar o formato do software de maneira sistemática. Partes que fazem com que você não queira dar o livro para alguém quando terminar de ler o livro, porque ele passa a ser um material de consulta.

Conclusão

Ao mesmo tempo que tenho minhas críticas a obra, por eu funcionar melhor com outro estilo de design, eu fico feliz de ter lido e recomendo fortemente a qualquer pessoa que não sentir domínio sobre a disciplina. Recomendaria esse livro facilmente para um programador iniciante como segunda leitura, depois do A Philosophy of Software Design é claro. Agora me sinto bem mais animado para ler os demais livros do titío Martin, começando pelo Domain Driven Design.

Como NÃO fazer testes automatizados

Régis Melgaço de Andrade — Tue, 31 Jan 2023 16:59:39 +0000

Muitos de nós no começo de carreira se preocupam em aprender a como fazer tudo, e essa preocupação é muito justa porque sempre que queremos uma oportunidade recebemos uma lista de coisas que devemos saber fazer. Uma das ideias que aprendi das obras do Robert Cecil Martin, também conhecido como "Uncle Bob", é que quase tão importante quanto saber como se fazer algo é como não fazer.

Por isso aqui me proponho a passar algumas das ideias do que não deve ser feito junto a fundamentação.

2 Passos pra trás

À medida que o software é desenvolvido, ele é testado para garantir que tudo funcione corretamente e identificar bugs, vulnerabilidades ou outros problemas. O teste pode ser feito manualmente (e geralmente é), mas o teste manual é repetitivo e demorado. Assim, os desenvolvedores recorrem aos testes de automação.

O teste de automação é prático e econômico. Como o nome sugere, envolve a automação do processo de teste e o gerenciamento e aplicação de dados e resultados de teste para melhorar o software.

fonte: https://www.atlassian.com/continuous-delivery/software-testing/automated-testing

Para tornar o questionamento mais simples, é importante entender os fundamentos principais para se querer testes automatizados. Para essa discussão focarei em:

garantia de corretude do código
reduzir perda de tempo fazendo testes

E não é difícil ver porque essa metodologia ganhou tamanha popularidade da última década, é muito fácil ver que funciona.
Uma verdade é triste e inacreditável pra muita gente, os seus testes podem estar te atrapalhando.

Os testes automatizados podem atrapalhar?

Pelos mesmos motivos que escrever um algoritmo em C não significa que ele será rápido. Não é garantido que o uso dos testes automatizados fará o time ser mais rápido e que nossos testes só passarão quando nosso produto estiver perfeito.
Assim como escrever código performático em C é difícil, escrever bons testes não é tarefa simples. Mas o que poderia acontecer de ruim? E eu te conto alguns exemplos:

Suite de testes que não testa os casos importantes não traz as garantias que deveria se esperar desses testes, preste atenção para os testes para bater percentual de cobertura. Ex: Uma suite de testes funcionais para um função que somente verifica a soma de 0 e 0 não garante a corretude lógica da função.
Diversidade de testes já! Suite de testes sem os tipo de teste necessários não da visiblidade sobre os aspectos do produto que são relevantes. Ex: Uma das coisas que se espera de um projeto com um percentual alto de linhas cobertas por testes automatizados é que ele possa ser refatorado. Todavia, se um projeto que tenha fortes requisitos de performance e nenhum teste para isso perdemos essa confiança.
Testes que não testam nada é um poluente grande de PRs e bases de código inocentes. Do que serve testes unitários para funções rasas que só existem para manter a arquitetura no lugar? Pra mim parece até que a pessoa não confia nela ou nas ferramentas que usa.
Eu não leio arquivo de teste com mais de mil linhas, até palhaçada tem limites. A Suíte de testes longa grita problemas. As chances da revisão do código seja bem feita são reduzidas, ajustes na suíte de testes para acomodar os novos requisitos fica propensa a falhas. Se já é difícil termos paciência para fazer uma revisão de qualidade em um arquivo de 1000 linhas, é praticamente impossível em uma suíte de 10.000 linhas. Normalmente chegamos a esses casos por heurística para escolher quais testes fazer, como a ideia de se testar caso base, caso x, caso x+1 e exceção. As estratégias que comumente ajudam a melhorar uma base de testes poluída são: - Propósito bem definido para os testes, assim evitando que um certo aspecto seja desnecessariamente testado ou retestado. - Boas heurísticas para definição de teste, testar os casos base, caso x, caso x+1 e de exceções é suficiente quase sempre. - Redesign do componente em questão, se é necessário testar muitos casos, pode ser interessante refatorar, simplificar e quebrar as entidades para que tenham um conjunto de casos mais simples e definidos (código simples costuma ser o melhor código)

E assim ... dessas poucas formas podemos ter falsas garantias em uma dupla do mal com a mais código para ler, manter e se preocupar. Bora não ter mais coisas pra dar trabalho, seu psicólogo agradece.

Quando isso pode acontecer comigo?

Porque essas coisas terríveis acontecem com as pobres pessoas da TI? Na minha opinião de quem queria trabalhar menos, o mal uso costuma ser a teoria em desencontro com a realidade, somente com conhecimento de ambos nos termos reais condições de analisar o que está sendo feito ao invés de simplesmente fazer. São muitas as formas essa tristeza de desencontro podem ocorrer:

Entendimento pouco robusto sobre a teoria por detrás dos testes automatizados e seus diferentes tipos, não basta entender como usar as bibliotecas de teste.
Revisões de códigos pobres, as causas para isso podem ser muitas mas geralmente giram em torno da má compreensão do que está sendo feito e falhas de comunicação.
Foco cego em métricas de testes. Por exemplo, a cobertura de testes deveria ser um guia e não uma regra, os testes são importantes demais para não se ponderar sempre.
O código de testes precisa ser mantido com um grau de exigência ao menos parecido ao do código de produção. O código dos testes automatizados precisam ser lidos, corrigidos e executados.
Pular ou comentar um teste deve ser considerado como um aviso, pois estaremos sujeitos a ausência da garantia colocada por ele ou talvez não precisamos dele se a ausência dele não for sentida. - Entendimento ruim do produto. É difícil perceber se temos as garantias corretas, nos levando a testar: - as entidades errados - os características errados - ou ainda criar um teste que verifica somente passa quando o código tá errado (um teste reverso)

Convite

Science is a systematic endeavor that builds and organizes knowledge in the form of testable explanations and predictions about the universe.
A ciência é um esforço sistemático que constrói e organiza o conhecimento na forma de explicações e previsões testáveis sobre o universo.

fonte: https://en.wikipedia.org/wiki/Science

Algo deixa de ter algum valor científico e passa a virar uma crença quando não precisamos testar e tentar invalidar esse conhecimento. Experimente e tente falsiar tudo aquilo que precisa estar mais próximo de explicar a realidade como a ciência faz. E para os caóticos por natureza, tragam esse tópico para a empresa e assista :)