Programo desde hace relativamente poco tiempo (comencé a interesarme en el PHP en el 2009) y la verdad es que siempre he aprendido como suele ocurrir en muchas ocasiones: picoteando de aquí y allá, copiando código de StackOverflow, buscando en foros, etc. Como mucha gente vamos. Y seamos sinceros, a mí personalmente siempre me ha causado mucha inseguridad y no se aprenden buenas prácticas generalmente.

Durante el Curso de Programación Web en PHP realizado hace unos meses, impartido por el magistral Agustín Calderón (sé que le hará más ilusión si enlazo a IMDB ;-)), pude conocer algunas de las “buenas prácticas” aquí referenciadas y me empujó a seguir investigando. No importa que seas rápido. Importa que lo hagas bien, a la larga será lo más rápido.

Porque hacer que algo funcione no es lo mismo que fabricar algo para que dure. Imaginemos que nos piden que construyamos un vehículo, pero no nos especifican si es para bajar por una cuesta de nuestra ciudad (¿necesitamos motor?) o un monovolumen para viajar por autopista. Bueno, para eso está la entrevista con el cliente y las especificaciones. Vamos adelantando en esta primera entrevista y vamos viendo como las expectativas crecen y de repente sucede lo peor: necesitamos un todo-terreno para correr el Rally Dakar

Efectivamente llevar muchos años no te garantiza llegar a buen puerto cuando sigues unas prácticas o metodologías que has aprendido a “salto de mata”. Obviamente hablo en nombre de aquellos profesionales que se han ido adaptando y reconvirtiendo. En el caso de profesionales formados en universidades entiendo que llevan implicita esa formación orientada a seguir “buenas prácticas” a la hora de programar.

Clean Code: el libro

La verdad es que llevaba tiempo buscando un compendio de “buenas prácticas en la programación” pero me resultaba bastante difícil encontrar algún manual, que de modo abstracto, pudiera cumplir con ese objetivo. Sin embargo este verano oí hablar de un recurso que ha resultado ser toda una revelación: Clean Code de Robert C. Martin.

Enlazo a la edición en inglés por motivos obvios: sino eres capaz de leer un libro o recurso en inglés relacionado con tu profesión tienes un grave problema; además la diferencia de precio con la edición en castellano es de la mitad… ¿Alguna razón más?

No es mi intención revelar todos los consejos, métodos y recomendaciones que aborda en distintos aspectos de la programación, pero sí que me gustaría detenerme en algunas de las partes del libro pues me han resultado muy reveladoras.

El libro utiliza Java a la hora de poner ejemplos en las prácticas pero realmente no hace falta grandes conocimientos para entenderlo. Un ejemplo más de la calidad del código bien escrito. Algunas partes de código son impactantes. Sobre todo cuando ves un montón de código en Java que no sabes por donde coger (obtenido de desarrollos estables y conocidos) y tras refactorizarlo aplicando las premisas del libro fluye por las páginas siendo muy sencillo de seguir.

Programación Orientada a Objetos

Básicamente el paradigma OOP lo ha copado todo y cualquier utilización de programación estructurada debería de utilizarse sólo para proyectos de muy reducido tamaño y que no van a requerir mantenimiento.

¿Cuantas veces hemos escuchado eso? Nos hemos metido en un proyecto pequeño, el cual sólo íbamos a desarrollar y entregar al cliente en un plazo y olvidarnos. Pero el proyecto nunca se cierra. Aleatoriamente va llamando a tu puerta, solicitando la corrección de bugs, desarrollo de “pequeñas” funcionalidades, etc. Con suerte sigues facturando horas cuando vuelve a llamar a tu puerta, así que no todo es malo. Pero cada vez que tienes que volver a coger el código te vuelves a encontrar el mismo “lío” de código estructurado, hecho deprisa y sin pensar en futuras modificaciones (Martin utiliza el término “mesh” que hace referencia a “barullo o lío” durante todo el libro). Y entonces es cuando echas de menos el uso de clases, métodos heredados, quizás un framework que te facilite el acceso a una Bases de Datos, etc.

Conclusión: no existen los proyectos pequeños sino plazos de entrega reducidos. Sabiduría popular: “vísteme despacio que tengo prisa”. Aplica siempre OOP.

Poniendo nombre a las cosas: variables y funciones, propiedades y métodos

Bueno, una de las cuestiones que se aborda desde el principio es el “nombrado” de los componentes del código: variables y funciones, propiedades y métodos. Robert C. Martin pone un especial énfasis en este tema y recoge una reflexión muy interesante: un programador se pasa un 90% del tiempo poniendo nombre a cosas: variables, funciones, métodos, clases, interfaces; y trabajando con ellas. Y cuando tenemos que decidir qué nombre darle sólo tardamos uno o dos segundos en decidir qué nombre le damos. ¿Algo falla no creéis?

Naturalmente en una clase breve o en un código simple quizás no merezca la pena perder mucho tiempo. Pero recordemos: no existe proyecto pequeño y quizás un día tengas que aumentar el tamaño de la aplicación y vayas arrastrando esos nombres de variable que tarde o temprano tendrás que renombrar (seguramente muchas más veces de las que pensabas).

Estas son algunas de las recomendaciones que apunta y me parece interesante recopilarlas.

[list type=”check”]

  • Empleo de la CamelCase. A día de hoy creo que es obvio que cualquiera que se dedique a la programación debe de conocer y emplear este estilo de escritura.
  • Evita incluir en el nombre de la variable el tipo de dato o Notación Húngara. Intenta abstraerte del lenguaje de programación y cíñete al problema en sí, no en la herramienta. Nombres como $arrayUsuarios o $stringTitulo nos aporta más bien poca información. Si tenemos un listado de cosas muy probablemente será un array o un objeto que se comporte como tal. Lo mismo con $stringTitulo, obviamente será una cadena ¿pero el título de qué? Serían mucho más aconsejables nombres como $listaUsuarios o $tituloPelícula.
  • Pierde todo el tiempo que necesites en nombrar una variable y considera las posibles alternativas. Debes de tener en cuenta dos factores fundamentales: 1) ¿El nombre escogido es lo suficientemente autoexplicativo para identificar su contenido en cualquier parte de mi código? 2) Y por oposición: adecua también la extensión del nombre de la variable al ámbito en el que se va aplicar. Obviamente no es lo mismo declarar $i como una variable utilizada para asignar el valor de un ID que se repite por todo el código que emplear $i como índice incremental en la iteración de un while.
  • ¿Trabajáis solos en vuestro código? ¿Toda la comunicación es escrita con otros colaboradores? Un punto que me parece muy interesante y divertido es el de asignar nombres de variables pronunciables. Por supuesto en inglés. Tontería o no yo supongo que los suecos asignarán nombres de variables en inglés. Finntroll es un grupo de heavy que canta en sueco “porque suena más a troll”. Pues eso. Imaginaos trabajar con un sueco que nombre las cosas en su idioma. Así pues deberíamos de utilizar nombres de variables como $userList ó $movieTitle. Yo soy el primero que salpico mi código de términos en castellano e inglés indiscriminadamente, que conste. Lo corregiremos.
  • Los nombres de clase deben de referirse a entidades y los métodos a acciones. Obvio ¿no? Traslademos la abstracción de la OOP al nombrado y no mezclemos cosas. Los nombres de clases deben de ser exclusivamente nombres (gramaticalmente hablando) y los métodos, verbos o frases que expliquen claramente qué hacen.
  • No tengas miedo a cambiar el nombre de tus variables/funciones (propiedades/métodos) si tras un tiempo de desarrollo ves que ya no se ajustan exactamente a lo que contienen o entran en conflicto con otras y resultan ambiguos. Hoy en día el empleo de IDEs facilitan mucho la tarea de renombrar propiedades o métodos a la hora de refactorizar.

[/list]

Recomiendo leerlo

Y bueno, estos son algunos de los conceptos más importantes que puedo recordar sobre el tema del nombrado. En el libro Robert C. Martin hace referencia a muchos más conceptos y recomendaciones pero tampoco voy a revelar todo lo que recoge. Vuelvo a insistir que es un buen libro y sí que merece la pena tenerlo en papel/digital para ir releyendo de vez en cuando.

Intentaré en sucesivos post ir comentando algunos apartados más del libro pues realmente abarca un montón de conceptos como la programación de OOP, empleo de patrones, ejemplos de refactorización (donde más se aprende), manejo de excepciones y errores, test unitarios y un sin fin de cosas más.

Comparte si te ha gustado

Autor:
Última actualización:

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.