65. El código limpio en programación

Creando Apps

Hay muchas formas de hacer un programa, una aplicación, de hacer cualquier tipo de software; no hay una única manera de conseguir un mismo objetivo, es decir, se puede programar la misma aplicación de formas totalmente distintas y quizás con ninguna línea de código en común.

Es como construir una casa, puedes utilizar distintos materiales, distintos procesos o arquitecturas, al fin y al cabo, va a ser una casa y puede tener “x” habitaciones y puede tener “x” metros cuadrados, pero el caso es que se puede construir de formas muy distintas.

El código limpio trata de construir un programa, un software, una aplicación de la mejor manera posible.

Importancia del código limpio

Tiene que quedar claro que aunque un programa haga lo que tiene que hacer, no quiere decir que esté bien construido; es decir, que tú encargues una aplicación que haga “x”, “y“ “z”, y que alguien te entregue ese programa haciendo “x”, “y” “z”, es decir, que tú cojas esa aplicación y confirmes que esté haciendo lo que tú has pedido, no tiene por qué estar construido de una buena forma, que tenga código limpio, al fin y al cabo.

Aplicación bien construida

En primer lugar, para que una aplicación software esté bien construida, para que tenga código limpio, tiene que hacer lo que debe hacer, esto es obvio. Si tú tienes una aplicación que haga una cosa y resulta que hace otra o que no lo hace, obviamente ya no es que sea código limpio, sino que no funciona, que es código directamente inválido.

Otra cosa que debe tener una aplicación bien construida o un código limpio es que no debe contener errores, o por lo menos debe contener los mismos errores posibles, porque el software nunca absolutamente es perfecto.

Es muy difícil hacer un programa que sea totalmente perfecto y mucho más en el mundo de las aplicaciones móviles donde hay mucha fragmentación, hay mucho movimiento, mucho cambio, es totalmente imposible hacer una aplicación que nunca vaya a tener un error y que nunca se le vaya a tener que corregir algo.

Código entendible

Otro punto a tener en cuenta, para que el código sea limpio, para que la aplicación esté bien construida, es que tiene que ser entendible para otros programadores ¿y por qué?

Básicamente, porque los programadores a veces tienden a pensar que el código que están escribiendo, lo van a escribir ahí y que siempre se va a perpetuar por los siglos y los siglos, que nadie lo va a tener que tocar, da igual cómo lo hagamos, si lo hacemos mejor o peor; simplemente con que haga el cometido para que el que se ha hecho, no hace falta que nos esmeremos mucho más.

El caso es que en el 90% de los casos nunca es así, ese código se va a tener que cambiar, siempre se va a tener que modificar de una forma u otra.

El caso es que, además, seguramente, el programador que lo cambie no sea el mismo que lo escribió originalmente; con lo cual, si ese código no es entendible para otro programador, va a ser muy complicado que pueda hacer cambios, con lo cual se considera que es un código no limpio.

Y, por otro lado, tenemos que tener en cuenta que puede incluso no ser entendible para el mismo programador que ha escrito algo, ya que muchas veces el programador piensa que nunca más va a tener que tocar ese código con lo cual suele hacer las cosas a veces rápido y sin pararse a pensar mucho si eso lo entenderá después cuando tenga que volver a ello.

Y lo que suele pasar es que, pasados unos meses, incluso unos años, tienes que cambiar esa funcionalidad que tú mismo habías escrito meses o años atrás, por lo que si tú no te has esmerado en hacer eso entendible y sencillo de asimilar, puede ser incluso muy complicado para ti mismo entender qué querías hacer en el pasado, es decir, por qué escribiste este código, qué hacía y qué sentido tenía la forma en que lo hiciste.

Código simple y bien construido

Otro punto, para que una aplicación esté viene escrita y que va muy de la mano del anterior, es que tiene que ser simple o lo más simple posible. A veces no es fácil escribir código simple, porque estás solucionando problemas complejos, pero siempre hay una forma de intentar hacerlo más simple, aunque el problema que tú estés solventando sea complejo.

Siempre hay formas de partirlo por trozos, de esmerarte más en que sea entendible, en que sea fácil, en que sea simple. Si tú intentas escribir el código lo más simple posible, generalmente siempre va a hacer beneficioso.

Un código limpio tiene que ser fácil de modificar y esto es muy importante. Si tú escribes un código que no es simple, no es entendible, no va a ser fácil de modificar a la larga, cuando alguien tenga que hacer un cambio, va a ser muy difícil poder modificar el código y hacerlo bien, y no introducir nuevos errores.

Si tú haces una aplicación y hace las cosas que te han pedido, pero luego a la hora de modificarla en un futuro, no se puede modificar o es muy complicado de modificar, vas a estar perjudicando a ese software.

Para empezar la empresa o la persona que sea, va a tener a los programadores que sean para que puedan hacer esas modificaciones, y obviamente los programadores tampoco van a ser productivos, porque cada vez que tengan que hacer un cambio o, aunque sea un cambio sencillo, van a tardar un montón en entender lo que tienen que modificar, con lo cual si el software, si la aplicación no es modificable en un futuro, no es código limpio.

Por otro lado, es que tiene que ser escalable, normalmente el software comienza con una base, con ciertas características básicas que a la larga siempre van escalando, es decir, se le van añadiendo funcionalidades encima.

Si tú desarrollas la aplicación de una forma que no es escalable, es decir, que es muy difícil añadir nuevas funciones, que es muy difícil modificar las existentes, es software que no está bien construido, ese software no tiene código limpio. Y una vez más esto va a afectar a la empresa, porque va a tener que pagar más por ello y a los programadores, porque no van a ser productivos.

Finalmente, otro punto bastante importante a la hora de decir si un código está bien construido o no es que debería tener test. Los test automatizados, te permiten saber que un código que tú no conoces, que quizás aún no has mirado, funciona o deja de funcionar, es decir, te puede confirmar si ese código está funcionando como debe o no, sin que tú entiendas, o lo pruebes manualmente.

Con lo cual los test automatizados son una forma muy sencilla de modificar cosas, de escalar cosas, porque puedes cambiar ese código que tú aún quizás no entiendes al 100% y realmente ver si todo está funcionando como debería.

Si hacemos código limpio, nos llevará a la consecución de un trabajo más alegre, más divertido, más llevadero, y por tanto, más productivo. Es decir, si tú estás manejando una base de código que es fácil de entender, simple, que tiene todas las características mencionadas anteriormente, siempre vas a ser más productivo, siempre vas a hacer las cosas más rápido, las va a hacer mejor y nos va a tener que estar volviendo y volviendo sobre el mismo punto todo el rato.

Por otro lado, piensa también en los otros programadores, después de ti van a venir otros programadores, si el código que tú escribes es un desastre, todo ese desastre va a pasar a ellos y encima si era difícil para ti entender tu propio desastre, más difícil lo va a ser para otra persona.

Así que ten en cuenta que siempre que escribes código, el 90% de las veces va a venir otro programador después, y va a tener que trabajar sobre él, sea modificándolo, sea comprando “x” cosa, sea escalándolo y añadiendo más cosas.

Por qué debes tener código limpio

Ahora veamos por qué debes preocuparte de tener código limpio, desde el punto de vista de alguien que encarga un software, una aplicación, un programa, lo que sea.

Básicamente se basa en los puntos que hemos mencionado desde el punto de vista del programador, para seguir escalando tu producto y para hacer modificaciones de forma más sencilla, y todo esto se resume a un solo punto que es ahorrar costes a la hora de coger otros programadores.

Si tu base de código es un desastre, está mal escrito, por mucho que funcionara en su día para aquellas características que encargaste, si no está bien escrito, tarde o pronto, cuando vayas a coger a otros programadores y tengas que hacer modificaciones sobre ese código, mantenerlo, escalarlo, lo que va a pasar es que esos programadores van a tardar mucho más tiempo para poder hacer esos cambios o cualquier cosa sobre ese código y eso se va a traducir en más costes para ti.

Ya sea porque contrates programadores internos, dentro de tu empresa o como si contratas a un freelance, van a tardar más, con lo cual al fin y al cabo lo vas a ver repercutido en el coste que te supone mantener esa aplicación.

Ahora que hemos visto la importancia del código limpio y las desventajas que trae el no tenerlo, vamos a ver cómo podemos saber si tengo código limpio. La verdad que esto es algo muy difícil de saber si no tienes conocimientos técnicos, pero es algo que se suele ver a la larga.

Cómo saber si es código limpio

Como mencionábamos anteriormente, si tú encargas una aplicación, es fácil ver si lo que has encargado funciona o no, porque tú manualmente lo puedes probar, y puedes básicamente con tus ojos ver si funciona o no; sin embargo, las desventajas que comentábamos del código no limpio se suelen ver siempre a la larga, ya que quizás a corto tiempo no te vas a dar cuenta.

Lo que vas a ver es que, a la larga, cuando los programadores tengan que hacer cambios, tengan que añadir cosas, tengan que mantener el código, vas a ver cómo se va complicando cada vez más la cosa y este es el gran problema del código mal escrito, que sea vea a largo plazo y no lo puedes ver a corto plazo.

Así que, como esto es algo, que sólo se puede ver técnicamente, lo que podrías hacer es contratar a alguien que sabe lo que hace, que sabe cómo escribir código limpio, y que te haga una pequeña auditoría del código que tienes entre manos.

Por norma general, si has encargado algo y te lo han hecho muy rápido, si has contratado un desarrollo low cost en comparación con los otros presupuestos que tenías, si has ido al desarrollo más barato, el que lo hacían en menos tiempo, el más económico; por norma general quizás vas a tener código no limpio.

Así que, vale más la pena gastar al principio un poco más en ese presupuesto inicial, que ir siempre a lo barato, porque al final a la larga si tú tienes código limpio, te va a costar menos que mantener un código que sea un desastre, porque al final no va a ser sostenible.

Qué puedo hacer si no tengo código limpio

Si eres programador y ves que el código es un desastre, que no se puede mantener, que no es escalable o si ves que tus programadores (si eres el dueño del proyecto) te están diciendo que ese código no es sostenible o están tardando mucho en hacer cambios que antes llevaban poco tiempo, lo mejor es actuar cuanto antes.

En el peor de los casos tendrías que reescribir la aplicación o el software desde cero, pero quizás esta no es la mejor opción de todas, porque generalmente no suele salir bien y se pierde muchísimo tiempo en volver a reescribir todo.

Depende del tamaño del programa, del software, de la aplicación, pero la mejor idea es ir arreglándolo poco a poco. A la larga va a valer la pena, tanto si eres programador, como si eres el dueño de la aplicación, al final vas a hacer más productivo, te va a suponer menos coste.

Aunque hagas código limpio, aunque seas el mejor programador en la faz de la Tierra, siempre vas a tener que ir arreglando tu código, porque el software es cambiante, muchas veces las cosas que pensabas en un inicio de una manera, al final son de otra con lo cual siempre tienes que ir mirando, tienes que ir pivotando un poco la forma en la que programas.

Cómo escribir código limpio

Pasemos al último punto, y es cómo escribir código limpio. Desde el punto de vista técnico, desde el lado del programador, explicar cómo se puede escribir código limpio, no es algo sencillo de explicar en unos minutos. Quizás el mejor ejemplo de ello es el libro de Clean Code del cual se darán algunas guías de forma rápida a continuación.

En primer lugar, elegir bien los nombres para variables, funciones, para archivos, y aunque suene una tontería, es una de las cosas más complicadas en programación, porque muchas veces se solapan unos con otros.

El segundo punto es evitar código duplicado y esto es algo siempre muy importante en programación, cualquier lenguaje y cualquier tipo de tecnología. No puedes estar haciendo lo mismo en varios sitios duplicando el código, porque luego cuando tengas que cambiarlo, vas a tener que cambiarlo en varios lados.

El tercer punto es hacerlo simple y sencillo, fácil de entender, funciones pequeñas, archivos pequeños, nombres que se entiendan, intenta no complicarlo mucho, porque cuánto más simple sea el código, más fácil es de entender, más fácil es de modificar, de escalar y de asimilar para otros programadores.

El cuarto punto es que sigas una arquitectura, que sigas una misma manera de hacer las cosas dentro de tu aplicación, construye tu proyecto en torno a un patrón común, no intentes hacer en unos sitios de la aplicación unas cosas y en el otro sitio otras cosas.

Hay muchas formas de construir una aplicación, por ejemplo, en el mundo móvil hay que estar al tanto de MVC, MVVM, MVI, hay muchísimas arquitecturas que tú puedes seguir para que tu proyecto sea consistente, que esté construido de la misma forma.

El quinto punto, es que utilices patrones de diseño que te ayuden a simplificar, estandarizar y solucionar los problemas que se te plantean. Los patrones de diseño son básicamente pequeñas recetas o soluciones para aplicar a problemas comunes.

Seguramente el problema que muchas veces intentas solucionar ya ha sido solucionado por otras personas antes y han encontrado una forma de hacerlo, que es estándar, que es simple y que será fácil de entender para otras personas porque, seguramente también estén familiarizadas con esa forma de solucionar las cosas. Así que, lo que tendrías que hacer es leer sobre patrones de diseño, para lo que hay mucha información disponible.

El sexto punto, es que organices bien el código; por ejemplo, no puedes tener carpetas, paquetes o lo que tengas con la tecnología en la cual trabajes, que hagan varias cosas a la vez o que tengan contenido de la interfaz de usuario y luego de la comunicación con el servidor o la comunicación con la base de datos.

Tienes que intentar siempre, partir de modular todas las partes de tu código, por ejemplo, en un paquete, en una carpeta, las pantallas, la interfaz de usuario; en otro la base de datos; en otro el servidor, para hacerlo una vez más simple y sencillo de entender.

Y finalmente escribe con test automatizado que intente respaldar todo el código que haces, y que pueda verificar que eso funciona, porque luego va a ser mucho más fácil hacer cambios. No vas a tener que acordarte exactamente de la razón por la que habías hecho eso. Siempre tendrás esos test que te van a decir de una forma u otra, si lo que estás cambiando va a romper algo o si lo que estás añadiendo de nuevo va a entrar en conflicto con otra funcionalidad.

Este concepto de escribir código limpio es algo que va más allá de un check list y hay que leer a fondo sobre ello y ser constante; seguir leyendo siempre sobre este tema y entender el porqué de cada cosa, porque esto es importante.

Para ello léete el libro de Clean Code, busca información por internet, que hay muchísima, lee sobre patrones de diseño, en fin estate al día con todo lo que se mueve en esa tecnología o lenguaje en el cual trabajas.

The post 65. El código limpio en programación appeared first on Diego Laballós.