Refactoring: Improving the Design of Existing Code

Datos do libro

• Título: Refactoring: Improving the Design of Existing Code
• Autores: Martin Fowler, Kent Beck
• Idioma: inglés
• Publicado: Addison-Wesley
• Web: Refactoring

Introducción

Recentemente este ano lín o libro sobre o que trata o artigo, Refactoring: Improving the Design of Existing Code. Se ben xa levo tempo practicando a refactorización do código, ao que cheguei da man de mentores ou outras lecturas, nunca lera o libro de Martin Fowler.

Pero nun clube de lectura da empresa xurdiu a oportunidade de o ler, ao saír escollido entre outros libros.
Refactorizar o código é unha das mellores formas de facer que este sexa mantible, así que nunca está de máis unha lectura á versión actualizada desta obra. Sempre hai cousas que se pasan por alto, cousas que convén reforzar ou mesmo por en común os nomes das técnicas a empregar dentro do equipo.

A través de varios exemplos Fowler expón non só os tipos de cambios a facer no código, se non tamén ás mecánicas para levalos a cabo. Dende distintos puntos de vista, dependendo da dificultade. En ocasións pode ser preciso, comezar dun xeito ou outro, antes de aplicar un refactor concreto.

Ao final, e como xa deixa claro dende a portada, o importante é escribir código que outros programadores poidan entender. Niso é no que pon o foco neste libro, mesmo por diante do rendemento do código. Primeiro que sexa entendible e se despois o rendemento é un problema, entón faránse os cambios adecuados. Xa que ca potencia dos equipos hoxe en día, non debería haber grandes diferenzas.

Sobre o autor

Martin Fowler: Autor, conferenciante, consultor e divulgador sobre desenvolvemento de software, traballa en ThoughtWorks como Chief Scientist.

Fowler leva o redor de corenta anos traballando no desenvolvemento de software, escribiu sete libros sobre desenvolvemento e é membro da Agile Alliance, ca que axudou a escribir o Manifesto para o desenvolvemento áxil de software no 2001, xunto con outros co-autores.

O autor é unha figura clave no desenvolvemento de software moderno, e con este libro amósanos de forma simplificada e práctica conceptos complexos.

O libro

Sobre o libro cabe comentar que os exemplos da segunda edición, que é a que lín, están escritos en Javascript. Pola contra a primeira estaba escrita en Java.

O libro está estructurado dunha forma moi sinxela de seguir, xa que para cada tipo de refactor amósanos un escenario e o resultado final. Para a continuación expor as mécanicas, que o propio Fowler soe utilizar para alcanzar o obxectivo.
A escolla de Javascript para os exemplos é adecuada, xa que é unha das linguaxes máis empregadas hoxe en día. Pero mesmo no caso de non coñecer a linguaxe, os exemplos son bastante simples e doados de seguir. Xa que non inclúen chamadas a librerías externas e a linguaxe é bastante semántica.

As mecánicas están explicadas con pasos moi curtos, xa que el mesmo dí que soe utilizar esta práctica de baby steps cando as segue. Así se ten que voltar atrás, non ten que desfacer moito e o código non deixa de funcionar en ningún momento. Xa que executa os tests asegurándose de que seguen a pasar despois de cada cambio. Isto por suposto significa que partimos dun código, acompañado por tests. Xa que é a única maneira de asegurarnos, de que non mudamos o comportamento do software cos pasos que damos.
Se nalgún momento vemos que algún test rompe polos cambios introducidos, volvemos ao commit anterior e partimos de aí. No caso de que tivésemos unha base de código sen tests, este sería o primer paso a dar. Cubrir o código con tests. A lo menos con tests de caixa negra, sabendo que para X entrada temos Y saída, aínda que non estemos certos do que ocorre dentro.

A parte desta estructura do código o primeiro que nos atopamos no libro, incluso antes da información da editorial, é unha relación entre smells e posibles refactors a aplicar para solucionalos.

Sobre se esta edición era necesaria tendo unha primeira sobre a mesma temática, compre dicir que inclúe novos refactors e algúns sufriron algún cambio, aínda que so fose a nivel de nome. Dúas décadas separan cada unha delas, pero o propio autor recoñece que a nivel de refactors non hai maiores diferenzas.

Os refactors que inclúe o libro van dende renomear unha función ou variable, ata refactorizar APIs ou lidiar con herdanza entre clases. Pasando por cousas como encapsular coleccións, organizar datos. Un especialmente chamativo pode ser o que el chama introducir caso especial.

Introducir caso especial

Neste escenario o que Fowler plantexa é a repetición sistemática en moitas partes do código, para comprobar certas cousas. Por exemplo un fragmento coma o seguinte:

if (aCustomer == "unknown") customerName = "occupant";

Isto pode repetirse en moitas partes para determinar certos aspectos, ou mesmo para devolver algún erro no caso de que non exista o usuario. A forma de resolvelo recórdame a outra lectura, neste caso de Elegan Objects de Yegor Bugayenko na que se avogaba por evitar o uso de nulls. A solución en ambos casos pasa por introducir unha clase para cubrir ese escenario. Esta é a solución proposta por Fowler:

class UnknownCustomer {
    getName() { return "occupant"; }
}

NOTA: para non deixalo colgando, a proposta de Bugayenko consiste en incluír unha clase que herde doutra, representando que non se atopou. Por exemplo NotFoundCustomer que herdaría de Customer e que lanzaría o erro ao tentar facer unha chamada a algún método. Evitando así as validacións, repartidas polo código.

Volvendo ao libro de Fowler, ó último que nos aporta é un índice para atopar rapidamente os distintos refactors ao longo do libro e referencias a unha extensa bibliografía para respaldar as palabras e o que nos amosa no libro.

Conclusión

Non se trata dun libro tan teórico coma outros que xa reseñei, senón máis práctico, polo que o artigo tamén queda máis curto. Non se trata de expor aquí cada refactor, pero si de recomendar a lectura do mesmo. Como dixen pode que xa apliquemos moitas das prácticas das que se falan, pero está ben por nomes en común co resto da xente e mellor se podemos aprender certas cousas que quizais descoñecíamos polo camiño.

Polo tanto considero que é un libro recomendable para ler, sobre todo para os programadores máis novos no sector, que todavía non teña o costume de aplicar estas prácticas no seu día a día. Xa que obterán unha excelente guía paso a paso para comezar a facelo.

Ao final unha das cousas que máis lastran a un proxecto é o código antigo, legacy code. Que é difícil de ler, que inclúe partes do código que xa non se executan nunca, que ten moito tempo ou que a persoa que o fixo xa non segue na empresa. Por iso é unha boa práctica, cada vez que teñamos que tocar un código, se vemos que hai partes que se poidan mellorar. Para que sexa máis lexible, para agrupar cousas que deben ir xuntas, etc. Isto nunca será unha perda de tempo, senón unha axuda a futuro para cando teñamos que voltar. Ademais sempre temos a opción de facer un refactor, para a tarefa en curso, e desfacelo no caso de que non nos convenza o resultado final.