Hace algún tiempo publicamos un artículo con tips sobre como optimizar nuestros sitios Web. En esa ocasión recalcamos el hecho de que hubo algunos puntos que se nos escaparon o que queríamos profundizar de mejor manera, por lo que probablemente haríamos una nueva edición en el futuro. Bueno, el momento ha llegado, aunque no precisamente continuando el mismo tema, si no que algo relacionado. Hoy les traemos una segunda parte enfocada netamente a código, compuesta de consejos y buenas prácticas que nunca están demás, especialmente en estos momentos que casi todo lo que vemos en Web envuelve, aunque sea en una pequeña parte, programación.
El detalle, como siempre, después del salto.
Al no haber implementos necesarios (a excepción quizás de un editor Web), vamos de lleno al contenido:
El siguiente tutorial está compuesto de un conjunto de consejos y buenas prácticas a la hora de programar. A pesar de que está orientado a Web, algunos puntos son aplicables a otro tipo de lenguajes en los que se puede extrapolar.
En la programación, las variables en las que almacenamos datos tienen lo que llamamos un “ciclo de vida”: Desde su nacimiento (el momento en el que las declaramos) hasta su muerte (última línea en que han sido utilizadas), toman distintos valores y forman parte de una serie de procesos que nos llevan a obtener resultados.
Posterior a su último uso, estas variables permanecen sin prestar utilidad. A pesar de que muchos lenguajes tienen implementada una característica conocida como recolector de basura, el cual se encarga de desocupar o limpiar todas las áreas de memoria que se encuentran utilizadas pero inactivas, en muchas ocasiones esto no ocurre o existe un periodo durante la ejecución de un programa en que seguimos creando variables y vamos ocupando más y más áreas de memoria, lo que adicionalmente nos puede llevar a confusión con el nombre de las mismas.
Es por esto que es recomendable, si vemos que hemos dejado de utilizar una variable en particular, reutilizarla, siempre y cuando no afecte el código donde las usamos originalmente. Por ejemplo, en vez de usar esto:
i=0; while(i<10) { echo 'Hola mundo'; i++; } j=0; while(j<10) { echo 'Adios!'; j++; }
Podemos utilizar esto, obteniendo el mismo resultado de manera más óptima:
i=0; while(i<10) { echo 'Hola mundo'; i++; } while(i>0) { echo 'Adios!'; i--; }
No solo reutilizamos la misma variable para ejecutar ámbas tareas, sino que a su vez optimizamos el código, mejorando la ejecución final.
Claramente es un ejemplo bastante básico, pero nos sirve para ilustrar el punto. A medida que nuestras aplicaciones van creciendo, necesitamos manipular una mayor cantidad de variables, por lo que puede volverse algo confuso de manejar. La reutilización nos sirve para tener un mejor control de lo que tenemos y al mismo tiempo nos permite hacer nuestro código mucho más simple.
Escribir código es de cierta forma contar una historia. Desde la declaración o nacimiento de las variables, hasta lo que hace cada una de ellas hasta el final, tenemos actos claros y definidos que permiten a cualquiera con conocimientos de programación poder seguir la historia del principio hasta el término. Y como tal, es importante tener consistencia en lo que escribimos, con respecto al nombre que le damos a las variables y funciones que utilizamos.
En lo anterior recalcamos un hecho muy importante: todo el código que escribamos será revisado por alguien. Ya sea otros programadores o bien nosotros mismos más adelante cuando queramos optimizar o reutilizar, siempre habrá alguien que deba hacer la traza del código y ver que hace cada cosa. Es por esto que es importante que mantengamos concordancia con respecto a los nombres y seguir una lógica que nos permita mantener un orden y claridad a futuro.
Por ejemplo, si recibimos los datos de un usuario a través de un formulario, es bueno que las variables a las que asignemos valores tengan un prefijo definido (por ejemplo usuario). De esta forma, cuando nos encontremos 30 líneas más abajo y necesitemos recurrir a ellas, ya sabremos bajo que estructura trabajamos y minimizaremos el margen de error.
Existen 2 convenciones definidas para nombrar elementos a la hora de programar, que si bien no es obligación usarlas, si pueden servir en demasía:
Al programar somos libres de definir nuestras propias reglas para nombrar. No obstante, si estamos realizando trabajo colaborativo con otros programadores, es bueno utilizar alguna de las convenciones aceptadas, con el fin de estandarizar el trabajo y hacer todo más entendible para los demas. Lo importante es definir una estructura y un estándar que nos permita hacer más uniforme nuestro código y de esta forma hacerlo mucho más entendible.
Si tomamos cualquier programa que hayamos escrito en el pasado, podremos apreciar que dentro de el, hay pequeñas secciones de código relacionadas entre sí por las funciones o tareas que realizan y que pueden o no tener directa relación con lo que viene líneas más abajo. Por un tema de orden, y para facilitar la documentación (punto que veremos más adelante) es bueno ir agrupando estas secciones y separarlas del resto del código con una línea en blanco. De esta forma, cada vez que necesitemos modificar una porción del programa será mucho más sencillo aislarlas y trabajar sobre ellas, ya que sabremos exactamente en donde empieza y donde termina esa parte del programa.
Por ejemplo, en un programa donde recibimos datos a través de un formulario, los insertamos en una base de datos y desplegamos el resultado al visitante:
$usuario_id = $_POST["usuario_id"]; $usuario_clave = $_POST["usuario_clave"]; $usuario_correo = $_POST["usuario_correo"]; $conexion = mysql_connect("localhost", "usuariobd", "clavebd"); mysql_select_db("mibd"); $consulta = "INSERT INTO usuarios VALUES('$usuario_id', '$usuario_clave', '$usuario_correo')"; $resultado = mysql_query($consulta); echo 'El usuario se ha creado satisfactoriamente';
En el código anterior podemos ver claramente que hace cada parte del programa: Primero recibimos los datos desde un formulario, luego hacemos la conexión y selección de base de datos, posterior a eso ejecutamos la consulta y finalmente mostramos el mensaje de éxito al usuario. Claro y limpio. Si al momento de ejecutar encontramos un error en una de las partes será mucho más sencillo volver a ella, ajustar y volver a probar.
Probablemente los 2 errores más clásicos que obtenemos al programar son la ausencia del punto y coma ( ; ) al terminar una sentencia y la falta de una llave de apertura o cierre en una iteración.
Sobre el primero no es mucho lo que se pueda hacer, más que fijarse, pero sobre el segundo una de las causas más comunes de la ocurrencia de este error es la falta de indentación del código, lo que muchas veces nos hace confundir una llave de otra iteración con la que estamos escribiendo actualmente, lo que puede llevar a 2 situaciones, o bien el código no se ejecuta bien, o la iteración se ejecuta como sub-sección de otra, lo que puede llevar a resultados aún peores.
Adicional a lo anterior, y tal como hemos remarcado en casi todos los puntos anteriores: orden. Siempre, y repito, siempre deberemos releer el código en algún momento y si bien cuando lo escribamos sabremos perfectamente que hace cada parte, no será así al tiempo después, por lo que mientras más ordenado y estructurado lo mantengamos, más sencillo será volver a trabajar sobre el.
Así que recapitulando, esto no es correcto:
while(i<10) { if(x == 'Letra equis') { echo 'Es la letra equis!'; } else { echo 'No es la letra equis!'; } }
Esto si es correcto:
while(i<10) { if(x == 'Letra equis') { echo 'Es la letra equis!'; } else { echo 'No es la letra equis!'; } }
De esta forma, a primera vista ya sabemos que el if y el else se ejecutarán dentro del while y cada vez que se repita la iteración, queda todo más ordenado y hasta estéticamente se ve mejor.
Este es un error bastante común que todos cometemos, especialmente cuando empezamos a programar y de forma inconsciente. Es natural que dentro de nuestros programas escribamos una, y otra, y otra vez el mismo código, o que bien en distintos programas de una misma aplicación (por ej. en distintas páginas PHP que forman parte de un mismo sistema) repitamos el mismo proceso o tengamos líneas repetidas.
La gracia de la programación es justamente evitar eso y nos entrega una serie de herramientas a tener en consideración. Tal como utilizamos ciclos para ejecutar una misma tarea varias veces, siempre es posible parametrizar un proceso. Solo bastante notar que es lo que estamos repitiendo, descubrir o definir el algoritmo, buscar los parámetros y formar una función a la que podamos llamar que haga la tarea independiente de los valores entregados.
Por otro lado, ¿tenemos un pié de página que se repite en cada página del sitio?, ¿un menú fijo que aparece en cada sección?. Hagamos uso de los includes y requires que PHP nos entrega, definamos funciones y plantillas que podamos reutilizar una y otra vez sin problemas. Una de las mayores bellezas de la programación es justamente esa: reutilizar. Podemos adaptar un mismo trozo de código para múltiples situaciones, haciendo la ejecución mucho más rápida y armónica.
Esta es una costumbre personal que adopté cuando empecé a hacer mis primeras armas en programación Web, por lo que fue una agradable sorpresa ver que estaba considerado como una buena práctica, y por eso hoy la remarcamos acá.
Las sentencias SQL pueden llegar a ser largas, y por ende complejas de leer, especialmente si están insertas en una maraña de código PHP y/o HTML, por lo que debemos hacer lo posible para mantener un orden dentro de ellas y así hacerlas más fáciles de revisar en caso de errores. ¿A qué nos referimos con esto?, en particular a un punto: Poner en mayúscula las palabras reservadas de SQL. Esto nos permitirá siempre saber a primera vista que es lo que se hace y no nos llevará a confusión en caso de que alguna tabla o variable con la que estemos trabajando tenga un nombre similar a ellas. Por ejemplo:
SELECT auto_patente, auto_marca, auto_color, auto_id_propietario, propietario_nombre, propietario_telefono FROM auto a, propietario p WHERE auto_id_propietario = propietario_rut ORDER BY auto_patente DESC
Es mucho más sencilla de leer que:
select auto_patente, auto_marca, auto_color, auto_id_propietario, propietario_nombre, propietario_telefono from auto a, propietario p where auto_id_propietario = propietario_rut order by auto_patente desc
Cuando estemos revisando código en texto plano a las 3 AM buscando el fatídico error agradecerán destacar las palabras reservadas, las cuales si se fijan, establecen una separación entre las distintas partes de la consulta.
Famosa frase que más de alguno ha escuchado anteriormente. Al programar, muchas veces tenemos la mala costumbre de querer hacer todo y confundimos la propiedad sobre una aplicación con generar el 100% del código. Nada más alejado de la realidad. Una de las gracias de esta gran red llamada Internet (¿Inter.. net?) es la cantidad de recursos que tenemos a nuestra disponibilidad, desde clases a trozos de código, es muy probable que muchas de las funcionalidades que necesitamos implementar ya hayan sido desarrolladas y puestas a disposición para utilizarlas, así que ¿por qué no aprovecharlas?.
No tiene nada de malo, y en realidad es muy ventajoso. No perdamos tiempo reinventado la rueda, y mejor veamos que podemos construir a partir de ella. No hay que tener dudas sobre incorporar librerías externas a nuestros desarrollos, siempre que respetemos cualquier licencia bajo las que hayan sido liberadas obviamente. Esto nos permitirá ahorrar un tiempo considerable que podemos dedicar a mejorar otras partes más críticas de la aplicación y mejorar los tiempos totales del desarrollo, que es algo que siempre debemos vigilar.
Lo más importante de recordar es que ser un buen programador no significa hacer todo desde cero, si no que tener la habilidad de identificar que integraciones podemos hacer con herramientas existentes y optimizar así el tiempo total de trabajo.
Un par de puntos más atrás hablábamos justamente de no repetir código. Este punto va precisamente de la mano. En muchos desarrollos en los que trabajemos a través del tiempo, veremos que es necesario desarrollar funcionalidades similares a las que hemos trabajado en el pasado, por lo que un buen consejo es hacer desarrollos genéricos con el fin de poder reutilizarlos y ahorrar tiempo.
Por ejemplo, si inicialmente hacemos un sistema que incluya un registro de usuarios y en otro sistema necesitamos de lo mismo, ¿por qué no desarrollar una función genérica que reciba los parámetros necesarios para crear el usuario y así reutilizar bajo distintas situaciones?. De tal forma son muchos los casos en los que podremos ver que es posible reutilizar código de desarrollos anteriores, así que ahorremos tiempo y preparemos código estándar para utilizar.
Hace algún tiempo tuve la fortuna de trabajar como ayudante en un curso de programación gráfica en la Universidad, lo que me dió la oportunidad de revisar código de otros desarrolladores todas las semanas, una experiencia a la que todos deberíamos someternos en algún momento.
Todos pensamos de forma distinta, y como tal, todos encontramos distintas soluciones o distintas formas de ejecutar una solución en particular, por lo que siempre es bueno revisar código de otros programadores, ya sea en librerías que descargamos o en sistemas que tengamos la posibilidad de ver. Eso nos ampliará la visión que tenemos sobre un lenguaje en particular y muchas veces nos permitirá ver formas más óptimas que las nuestras de codificar, lo que podremos incorporar a futuro.
De la mano con lo anterior, siempre es una buena práctica plantearse nuevos desafíos al momento de hacer un desarrollo comparado con lo que hemos hecho anteriormente, y revisando código de otros programadores es una buena forma de plantearselos.
Uno de los puntos más importantes, sino el más importante, de esta guía. No podemos enfatizar lo suficiente la importancia de documentar el código y sobretodo de hacerlo correctamente.
Si hay un punto en común de casi todo lo que vimos hoy, es el de facilitar la revisión del código, ya sea para otros desarrolladores o para nosotros mismos a futuro, y la documentación es fundamental en aquella tarea. Comentar que hace cada función, que rol cumple una variable en especial o porque hicimos algo de cierta manera será clave cuando los recuerdos no sean tan frescos en el futuro y necesitemos hacer modificaciones sobre el código.
Adicionalmente a lo anterior, no es bueno exagerar. Si bien mientras más documentado esté el código será mejor, es bueno evitar comentarios obvios. Por ejemplo, si tenemos un ciclo que lo único que hace es mostrar el valor de una variable, no es necesario comentarlo, ya que a primera vista se puede ver sin problemas lo que hace.
Así que en resumen es eso, comentar, pero ser criterioso a la hora de hacerlo. A final de cuentas es por nuestro propio bien, así que estimemos de forma correcta cuando y como hacerlo.
Y con eso terminamos esta sencilla guía sobre 10 consejos para optimizar nuestro código, la que esperamos que sea de utilidad para todos aquellos dedicados a la programación o que buscan aprender más al respecto.
Como siempre, les recordamos que este tutorial ha sido:
Cualquier duda o comentario que puedan tener, los invitamos a dejarnos unas líneas en el área habilitada a continuación.
Muchas gracias por leer y será hasta una próxima oportunidad.
1:56:25 am
– Reutilización de variables
– No reinventar la rueda
– Documentar como un campeón
eso es lo que me falta lo demas ya lo hago.. como tu lo aprendi con la experiencia…
muy buenos los consejos
4:16:50 pm
Si, definitivamente me sirvió mucho el tip de Reutilización de variables, por esa “mala costumbre” algunas páginas tardan mucho en cargar, y además se vuelve confuso al tratar de releer el código.
12:34:11 pm
Muy buenos consejos, si hay algo que apasiono es revisar código de otros programadores!
Puedo estar horas y horas estudiando su funcionamiento.
9:35:37 pm
Ah caray, yo no entiendo, el post data del 22 de agosto del 2012 (ayer) y hay comentarios del 2010…
Eso es normal.? O_o
10:56:05 pm
estamos igual aunque este es viejo, solo lo republicaron.. ya esta pagina no la actualizan desde el el 2010 :/
1:51:07 pm
Porfa! ayúdennos con Joomla para dummies!
8:08:37 pm
q paso con CLH, hace como 1 año que no me metia(visitaba la pagina) y no a pasado nada, esta todo igual!!
como lo hacen ahora