Simplemente refactorizando el código basado en WordPress

En 2011, estaba leyendo mucho sobre el trabajo con código heredado, la calidad del código y la refactorización.

Hay una cita de Martin Fowler (quien literalmente escribió el libro sobre la refactorización) atribuida al tío Bob que se me quedó grabada, y estoy seguro de que a muchos, muchos programadores, desde entonces:

siempre deje el código atrás en un mejor estado de lo que lo encontró

Lo que pasa con esta idea en particular es que creo que puede sonar un poco más idealista hasta que realmente comiences a tratar de practicarla en todo lo que haces.

Es decir, si lo toma al pie de la letra, parece que cada vez que necesita trabajar en una base de código, entonces debe dejar la base de código completa mejor que cuando la encontró. Pero cuanto más intento aplicar esta regla en mi trabajo diario, más práctico, más limpio y más fácil de mantener se vuelve el código específico de WordPress.

Entonces, cuando se trata de refactorizar el código basado en WordPress, ¿cómo se ve eso?

Esta no va a ser una publicación larga. En cambio, simplemente voy a compartir algunos puntos que sigo cuando se trata de trabajar en código que he escrito previamente, que encuentro de otros, o que es de una base de código en la que he trabajado con otros en el pasado.

Sin ningún orden en particular:

• No seas idealista; Sea práctico. La refactorización de una base de código completa no es algo práctico, especialmente si la base de código no está envuelta en pruebas unitarias. Mire el código en el que está trabajando y vea qué modificaciones menores puede hacer para mejorarlo.
• Utilice los últimos estándares. No necesita configurar un entorno de desarrollo completamente nuevo para el código anterior. En su lugar, solo asegúrese de tener buenos rastreadores de código en su lugar. Si ha pasado de los estándares de codificación de WordPress a PSR, mire las advertencias o avisos que arrojan los rastreadores e intente actualizar el código solo en ese archivo (o conjunto de archivos).
• Escribir funciones auxiliares. Si sus funciones son demasiado largas, busque formas de hacer que sea más fácil trabajar con ellas. Primero, actualice cualquier estructura de control como bucles o condicionales, luego escriba funciones auxiliares para que sean más fáciles de leer.
• Agregar pruebas (cuando sea posible). Si ya tiene un marco de pruebas unitarias, agregue pruebas para su nuevo código. Si no tienes el tiempo o no tienes el marco, no te preocupes. Por mucho que lo prediquen los programadores pragmáticos, no siempre hay tiempo para agregar pruebas. (Esto no quiere decir que no sean útiles o que no deban incluirse, sino que no siempre es práctico incorporarlos en un momento dado).

Algunas de las cosas que me he encontrado haciendo en proyectos recientes también incluyen cosas simples:

• actualizando nombres de variables y funciones para seguir PSR,
• cambiando tabulaciones a espacios,
• agregar funciones auxiliares para que las condiciones y los bucles sean más legibles,
• dividir las clases para que tengan un mayor grado de cohesión,
• mejorar los docblocks de cada función

Estos son solo algunos de los ejemplos y claramente no es una lista exhaustiva. Pero ese no es el punto. En su lugar, estoy buscando simplemente compartir cómo puede aplicar la refactorización del código basado en WordPress mientras realiza su trabajo diario de una manera manejable.

Todos los cambios o recomendaciones anteriores son cosas que generalmente se pueden hacer con la ayuda del IDE, algunos atajos y tal vez con media hora de tiempo adicional (y estoy siendo generoso con esa estimación).

Entonces, no, no tiene que volver a escribir un código base completo. Ni siquiera sé si ese es un objetivo práctico al que apuntar. ¿Pero puedes arreglar una pequeña parte del sistema general del que eres responsable?

¿Y por qué no al menos aspirar a eso?