Mejorando el naming de nuestro código

$result, $resultado, $request, $fecha, … es cierto, poner nombres a las variables y/o los métodos es una de las cosas más difíciles cuando estamos programando. Llegar a poner un buen nombre, establecer cada cosa en su sitio y crear las abstracciones correctas a la primera es un poco complicado. Y mucho más si estamos refactorizando. No te preocupes, el naming es un proceso, no se consigue a la primera.

16292355113_47a1de1b90_z

Este post recopila una serie de trucos, consejos y de cagadas que cometo a la hora de poner nombre o de cambiar los nombres a partes del código.

Las etapas del naming

Buscando en Internet sobre naming y como mejorarlo, me encontré con esta joya Good naming is a process, not a single step una serie de posts sobre como mejorar el naming del código y en especial del legacy code. En esta serie de post Arlo Belshee (el autor) indica que normalmente el camino a recorrer para encontrar un buen nombre es este:

  • Missing
  • Nonsense
  • Honest
  • Honest and Complete
  • Does the Right Thing
  • Intent
  • Domain abstraction

Cambiar el nombre de un trozo de programa es un proceso lento, miro una parte del código, intento entender que está sucediendo, tengo una idea de como renombrar/extraer una parte de la funcionalidad y lo hago. Repito este proceso hasta que los nombres sean consistentes y he llegado a un punto en el que esto estoy contento.

Esto parece fácil, pero cuando estoy delante de legacy code se hace cuesta arriba, por eso intento cambiar los nombre poco a poco, aunque sea un foreach, ya que creo que trabajando el naming se mejora la comprensión del código y con ello se paga parte de la deuda técnica.

Este enfoque puede parecer extraño al principio. Después de todo soy programador, sé leer código complejo y mi trabajo es actualizar/mejorar ese código. Pero también es cierto que donde más tiempo invertimos los programadores es en leer código, incluso más que en escribir código, más que en diseñar, más que en reuniones… Por ello creo que una buena manera de pagar la deuda técnica y mejorar nuestro código es escribiendo buenos nombres y renombrando cada poco. Ya que nos haremos más eficientes porque leer el código nos será más sencillo.

Pasos a seguir

  • Mirar: no trato de entenderlo todo al 100%, ya que eso me tomaría mucho tiempo e incluso puede que se me fría el cerebro.
  • Idea: no es la mejor, pero al menos es algo, inspecciono la idea.
  • Escribir: Escribo ese nombre, veo como queda, utilizo thesaurus.com para los sinónimos
  • Chequear: Compruebo como queda y si es consistente con las decisiones que he tomado antes o las que creo que tomaré. Inspecciono el impacto ¿Es fácil de buscar, sabré dentro de 2 semanas que es esto, el equipo está de acuerdo?
  • Commit: Hacer un commit, con un mensaje bueno sobre el renaming. Intentar no poner “refactor”

¿Y si no encuentro un buen nombre? Pues no pasa nada, intento no frustrarme y seguir hacia delante. Si aun así necesito poner un nombre a algo llamo a esa variable/método Manolo, Joselito, Amalia, nombres que choquen, para así cuando tenga más conocimiento del problema ir a ellos y poder cambiarlos de manera sencilla.

Un pequeño ejemplo

Imagina que nos encontramos con un método como este en un controlador, o mejor en una vista.

$this->preload();

¿Qué hace este método? Podría leer un XML de un servicio, podría cargar datos de una base de datos, o no se cualquier cosa porque leer ese nombre nos hace tener que ir a la función para ver lo que hace.

Tenemos que caminar hacia la honestidad, poner que es lo que hace aunque no tengamos muy claro del todo todo lo que hace

$this->doSomethingWithDBAndDisplayResult();

Esta honestidad también se puede aplicar a las clases porque tener una clase que sea DataManager, ¿manejar los datos de qué?

Poco a veremos que es lo que hace el método y podremos darle el nombre completo y honesto:

$this->parseXMLAndStoreInMemcacheData();

Ahora podemos empezar a encapsular este método en otros más pequeños y seguir con nuestra refactorización, continuar caminando y mejorando nuestro código.

Esto mismo también lo intento aplicar a los test, tener un test que sea testOk, pues no mola. Tenemos que escribir nombres de test que nos indiquen que hace el test algo así como show_error_when_user_not_logged()

Conclusiones

En definitiva, creo que todo esto del naming, no es más que iterar. Sé que a la primera no voy a acertar pero poco a poco iré llegando a un consenso, a una serie de nombres que me hagan la vida más fácil.

Refactoring y Connascence

Refactoring y Connascence

Hace poco tiempo hablamos de Connascence. En el post comentamos que el Connascence es una métrica de calidad software y una taxonomía (forma de clasificar) el acoplamiento entre componentes software. Por ello es una buena herramienta para tomar decisiones de diseño sobre todo cuando estamos refactorizando.

En el libro de Refactoring se habla de “code smell” como una manera de identificar la partes del código que pueden tener problemas y que sería bueno refactorizar. El inconveniente de los code smells es que son subjetivos y pueden variar según el lenguaje de programación, el desarrollador. Por ello podemos ayudarnos del connascence para identificar los code smell y así empujar el refactoring tomando decisiones basadas en el connascence.

Para ilustrar esto, lo ideal es tener en cuenta esta gráfica.

Seguir leyendo “Refactoring y Connascence”

Curso de Refactoring en PHP

Este es un post un poco especial, voy a impartir este curso sobre refactoring en PHP y me gustaría contar un poco como ha sido todo este proceso desde que empecé como alumno en geekshubs academy hasta que nos pusimos manos a la obra para grabar un curso.

Aunque Internet es una fuente inagotable de información. En la red hay miles de artículos, blogs, wikis, listas de distribución sobre programación, testing, docker,… no terminaba de encontrar un curso que de verdad me aportase algo más. Estaba buscando mejorar mis habilidades como programador, que fuese en español, con comunicación directa con los profesores.

rrss.jpg

Un día casi por casualidad, encontré un post de Xavi Gost hablando sobre el curso “De refactoring a patrones” impartido en GeeksHubsAcademy, la verdad es que era escéptico sobre los cursos en video, pero me convenció el hecho de hacer hangouts para poder resolver dudas y además @islomar me dio un empujón en forma de descuento 😉

Seguir leyendo “Curso de Refactoring en PHP”

Naming, que difícil es

¿Cuál debería ser mi primer test? ¿y el siguiente? Cada vez que empezamos a escribir test nos vienen a la cabeza cuestiones similares. La decisión a veces es fácil y otras, no tanto. Pero esto no solo cuando escribimos tests, al leer los nombres de los test no se acercan ni de lejos a lo que estamos intentando probar.

Seguir leyendo “Naming, que difícil es”

Como refactorizar utilizando PHPStorm

Ya llevamos tiempo hablando de refactorizar, de mejorar nuestro código y de que tengamos testado todo nuestro código para que así podamos hacer cambios y resolver bugs de manera más sencilla. Como dice Martin Fowler: “Refactorizar es una técnica para mejorar el diseño de una base de código existente”. Todo este tiempo hemos estado utilizando PHPStorm como IDE, creo que tenemos claro que es una gran herramienta, que nos ayuda a que seamos ma´s productivos, por eso hoy escribiremos una pequeña guía sobre Como refactorizar utilizando PHPStorm.

Empezaremos por lo más simple renombrar una variable e iremos mostrando distintos atajos para que podamos hacer refactoring de manera sencilla

Seguir leyendo “Como refactorizar utilizando PHPStorm”