"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.