Cada maestrillo tiene su librillo, aplicado al código se podría decir que cada desarrollador/a tiene su propio estilo, vicios y manías... Esto puede dar lugar a problemas, inconsistencias, poca escalabilidad, etc. Afortunadamente existen una serie de principios, reglas y estándares que ayudan a que un equipo de trabajo funcione como un reloj
Cada maestrillo tiene su librillo, es un hecho al que no escapan tampoco los programadores. Todos y cada uno de los desarrolladores/as han mamado de diferentes fuentes de aprendizaje, tienen sus vicios, sus manías, su propio estilo…
Cuando se trabaja en equipo esto puede dar lugar a problemas, inconsistencias, poca o nula escalabilidad, e incluso a que te cueste hasta entender el código que ha elaborado tu compañero/a.
Afortunadamente existen una serie de principios, reglas y estándares que ayudan a que un equipo de trabajo funcione como una máquina perfectamente engrasada.
¿Es recomendable o deseable practicar el Clean Code?
Más que recomendable, debería ser un must para todos los equipos de desarrollo. Y como reza la regla de las 4Cs (Clean Code, Clever Code): Código Limpio, Código Inteligente.
Escribir código limpio es inteligente, y con ello obtendrás muchos beneficios. Dicho de otro modo, no hacerlo podría desembocar en código enmarañado, confuso, incongruente, ilegible y cada vez que haya que tocar algo, se invertirá mucho tiempo en investigarlo y entenderlo.
Mucho se ha escrito sobre Clean Code, quizá el libro más conocido sea el que lleva el mismo título, escrito por Robert C. Martin, aka Uncle Bob. Pero también existen otra serie de principios y filosofías que ayudan a conseguirlo: SOLID, DRY, KISS, YAGNI, patrones de diseño...
La responsabilidad de escribir clean code recae en cada uno de nosotros/as. Tu labor como desarrollador/a es defenderlo y evangelizar sobre él . No tienes excusas para no hacerlo. En este artículo quiero desgranar las bases para empezar a escribir código limpio:
0. Disclaimer
Aunque las buenas prácticas pueden aplicarse a cualquier lenguaje de programación, de aquí en adelante pondré algunos ejemplos basados en PHP.
1. Idioma
In English, please. Las estructuras de control (if, else, for, foreach, switch,…), las funciones (count, date, die, isset, empty,…), etc… están en inglés, por lo tanto por consistencia es aconsejable que el nombre de nuestras variables, clases y métodos estén escritas en inglés.
Parece una obviedad, pero programar en Español es más común de lo que podamos creer. Es algo que no afecta al funcionamiento del código, pero el inglés es un estándar, así que tomémoslo como tal y programemos en Inglés.
A lo largo de los años me he encontrado con métodos del tipo obtener_usuarios(), incluso alguna performance de alguien con una creatividad sorprendente que se desmarca con métodos en spanglish del estilo: get_usuarios(). No tiene sentido.
2. Naming Things
Hay una frase que dice: There are only two hard things in Computer Science: cache invalidation and naming things. Se podría traducir como: en informática hay dos cosas difíciles: invalidar la caché y nombrar las cosas.
Y tiene mucha razón, nombrar las cosas es algo que puede parecer trivial, pero no lo es. Es algo importantísimo. Los nombres deben revelar intención y ser cortos, claros, explícitos y descriptivos.
Un nombre debe expresar lo que hace con tan sólo leerlo. Es recomendable que empiece por un verbo (get_, set_, check_, is_, has_), para lo cual deberéis establecer un listado de verbos “comunes” y no salirse de ahí, para evitar inconsistencias por sinónimos (ej: get_, obtain_, receive_)
¿Y qué decir de las variables y números “mágicos”? ¿Quién no se ha encontrado alguna vez con algo tipo $s == 3? ¿Qué carajo es “s”? ¿“3” qué? Poneos en la piel de que se incorpora alguien nuevo al equipo y se encuentra con algo así, lo normal es que primero pierda tiempo en averiguar qué significa esto, y finalmente te lo haga perder a tí para explicárselo, si es que acaso te acuerdas…
Si en lugar de esto te encuentras un $status == PUBLISH, ya simplemente con leerlo tienes más idea de por dónde van los tiros. Repito, utiliza siempre nombres descriptivos, evita abreviaturas y sobretodo evita los “números o cadenas de texto mágicas”, mejor constantes descriptivas
3. Funciones
Lo ideal es que los métodos o funciones que desarrolles sean reducidas y que sólo hagan una cosa. De este modo cumpliremos con el Principio de Responsabilidad Única (SRP). Si un método hace dos cosas, mejor divídelo en dos métodos independientes.
Si un método hace sólo una cosa, será más sencillo (cumplimos con la filosofía KISS), será más fácilmente entendible, se mantendrá mejor, y será más fácilmente testeable, algo deseable en cualquier desarrollo de software.
Funciones o métodos kilométricos con cientos de líneas son un cacao, inducen a errores y es necesario invertir mucho tiempo en entenderlos cuando te toca modificar algo sobre ellos. A más complejidad, más problemas.
También es deseable que no reciban más de 2 ó 3 parámetros, y que retornen valores del mismo tipo. Es decir, si un método te devuelve un array con los datos de un usuario, en caso de no encontrar resultados porque el usuario no existe, trata de evitar que te devuelva un “false”, que es un valor de tipo boolean.
Utiliza strict_types, hará que tu código sea más robusto y estable. Si una función recibe un array como parámetro y por el motivo que sea tu aplicación llama a ese método pasándole un string, provocará un error. Pero es un error de los que hay que solucionar, es un indicador de que se está haciendo un uso no adecuado de un método, y podrás subsanarlo.
4. Clases
Al igual que en las funciones, su tamaño debe ser reducido y tener una única responsabilidad, la que indique su descriptivo nombre.
Por cuestiones organizativas, se aconseja que primero se declaren las constantes estáticas, a continuación las variables estáticas, después las variables de instancia y a continuación las funciones o métodos. De todo esto, primero las que son públicas y después las privadas.
Las clases deberán cumplir con el principio Open/Closed, es decir, deberán estar abiertas a extensión y cerradas a modificación. Si tenemos que hacer una nueva funcionalidad, o realizar alguna adaptación por un nuevo requisito, mejor que se introduzcan nuevas clases que extiendan, y no modificar la existente.
5. Comentarios
El Clean Code predica con que el código debe hablar por sí mismo. Los comentarios no deben compensar el código incorrecto. El código debe ser tan sencillo y tan descriptivo que se asemeja al lenguaje natural, por lo tanto será de fácil comprensión con sólo leerlo.
Por lo tanto, no se suele hacer hincapié en la documentación o en los comentarios, ya que sólo estarían justificados si no hemos sido capaces de expresarlo con el código. OJO, no se aconseja no documentar, si no documentar lo mínimo imprescindible.
Si tenemos un método que se llama get_user_by_id, puedo suponer sin temor a equivocarme, que pasándole un ID a este método me va a devolver un objeto con los datos del usuario, por lo tanto cualquier comentario o documentación de más, probablemente sea redundante y sobre.
6. Regla Boy Scout
Con el paso del tiempo todos los desarrollos generan lo que se conoce como deuda técnica.
La regla del Boy Scout predica con dejar el campamento un poco mejor de como te lo encuentras al llegar.
Aplicado al desarrollo, esta regla te aconsejaría que cuando vayas a realizar una modificación sobre un método o clase existente, aproveches para dejarla un poco mejor de lo que estaba, por ejemplo añadiendo más documentación, añadiendo tests, renombrando una variable para que se entienda mejor, simplificando la lógica, extrayendo parte de la funcionalidad a otros métodos para cumplir con SOLID…
De este modo el código mejorará con el tiempo, de hecho la mejora continua puede entenderse como una parte inherente a la profesionalidad.
La regla del Boy Scout puede resultar un arma de doble filo. Si no acotas el alcance de estas mejoras puedes verte envuelto en una refactorización que se coma tu tiempo o los recursos asignados a un sprint.
7. Testing
Protege tu código con tests. Los tests son tu red de seguridad. ¿A quién no le ha pasado que has tocado en un sitio y se ha roto otra cosa? Si tienes una buena cobertura de tests, probablemente este tipo de errores tiendan a desaparecer.
Los tests pueden resultar arduos, complejos y algunos desarrolladores/as los suelen dejar para el final, y muchas veces te comes el tiempo estimado y al final o no se hacen o se hacen menos de los que se recomendarían.
Dispones de técnicas, como TDD, que te obligan primero a crear los tests antes que el código, con lo que te aseguras que realizarás batería de tests si o si antes de desarrollar el software.
Conclusiones
Los beneficios de hacer código limpio los notarás desde el primer día, y a la larga obtendrás un código más robusto, escalable y mantenible.
Esto es sólo una base, algo por donde empezar. Te recomiendo que busques por internet que encontrarás muchísima información, artículos, vídeos y libros sobre ello.