Your avatar

Buenas Prácticas

@buenas_practicas

Soy un entusiasta de la programación y amante de las buenas prácticas! Espero que disfrutes y compartas mi contenido! Work in progress
34

followers

0

following

  • Posts
    2
Post image : KISS - Keep it simple, stupid!

KISS - Keep it simple, stupid!

A lo largo de mi carrera he coincidido con compañeros a los que les costaba mucho hacer código que fuese mantenible. En muchas ocasiones hacían algo que a los pocos días de haberlo hecho, no podían entender su funcionamiento.
Este es un problema real del día a día de los desarrolladores de software, si no se aplican una serie de buenas prácticas, a medio-largo plazo cualquier proyecto puede convertirse en una pesadilla de mantener.
Hoy hablaremos sobre la complejidad innecesaria que solemos agregar a nuestro código y de algunas técnicas que nos ayudarán a reducirlo y a hacerlo más comprensible por nosotros y nuestros compañeros.
El acrónimo KISS nos recuerda que para que algo funcione bien, debe ser lo más sencillo posible. Haciendo un poco de uso de la reducción a la absurda, "cuanto menos código, más probable es que funcione bien". No, esto no lo dijo Mariano Rajoy.
Los problemas que pueden derivar de una complejidad innecesaria en un proyecto son muchos y muy variados, por ejemplo comportamientos anómalos en nuestras aplicaciones, aumento de los costes de depuración (sobre todo en tiempo), y en casos extremos puede darse el caso de llevar el proyecto directo a la bancarrota.
En el mundo de software, la complejidad es algo que debemos tener muy en cuenta ya que no solo afecta a la compresión del código si no a los recursos que un ordenador requiere para ejecutarlo.
¿A quién no se le ha quedado colgado un programa durante una sesión de estudio o de trabajo? ¿O un juego en mitad de la mayor batalla de tu juego favorito?
Este tipo de problemática, suele producirse en la mayoría de los casos cuando un programa no está optimizado y en algunas ocasiones, mantener nuestro código sencillo, nos ayudará a recortar tiempos de ejecución y consumo de memoria o CPU.
Este problema puede aparecer en diferentes etapas de un proyecto, desde la decisión de un "cliente" en una consultora o el departamento de negocio de una empresa de producto, pasando por el análisis de una implementación hasta su ejecución en el código.
En este artículo abordaremos la etapa que más nos concierne a nosotros como desarrolladores, que viene a ser la última mencionada.
La gran mayoría de desarrolladores estamos en continua formación (Si no te sientes identificado con esta última información, lárgate de aquí) y es por ello que cada vez conocemos nuevas formas de hacer lo mismo (o algo muy similar), nos van llegando nuevos enfoques, librerías, lenguajes... y llegamos al punto de pensar que cuanta más azúcar más dulce.
Es decir
- Cuantas más tecnologías tenga mi proyecto, mejor.
- Cuantas más librerías use, mejor.
- Cuanto más largo sea mi código, mejor
Lo cierto es que:
- Cuantas más tecnologías tenga tu proyecto, más lento es su desarrollo y más complicado es encontrar nuevos miembros para el equipo.
Cuantas más librerías use, menos control tienes sobre tu proyecto.
Cuanto más largo sea mi código, cuesta más de testear, comprender y modificar.
En este caso, no usaremos solamente un ejemplo si no varios para entender que KISS no solo se debe aplicar a nivel de código.
No reutilices variables
Existen muchos ejemplos en código, por ejemplo la reutilización de variables. ¿Quién no ha visto una variable definida que muta pocas líneas más tarde?
# Ejemplo en PHP
Esto es un problema, dado que la variable, tiene dos valores dependiendo del momento de ejecución del código. Esto agrega complejidad innecesaria.
En su defecto, deberíamos definir una nueva variable que exprese con criterio lo que contiene.
# Ejemplo en PHP
Puede parecer un ejemplo muy tonto, pero cuando son archivos de 100 líneas de código, identificar este tipo de cosas puede ser una pesadilla.
Evita el código duplicado
Como ya vimos en el anterior artículo (DRY - Dont repeat yourself) evitar duplicar código, también ayuda en gran medida en mantener proyecto lo más simple posible.
Evita introducir tecnologías que no sean completamente necesarias
Antes de incorporar una nueva tecnología a tu proyecto, pregúntate si el coste de implementación de este, es mayor que su beneficio. Muchas veces introducimos tecnologías como ElasticSearchRedis o algún servicio de AWS como EC2 o S3 porque molan sin pararnos a pensar el coste que tiene mantenerlos (Hablamos de coste considerando dinero y tiempo) o configurarlos apropiadamente.
La gran mayoría de los casos en que pensemos en utilizar alguna nueva herramienta para algo, es altamente probable que exista una solución menos cool pero más rápida y barata que nos sirva temporalmente hasta que podamos hacer frente al coste de introducir en nuestro proyecto nuevas tecnologías.
Naming: Por favor, haz que tu código hable por si mismo
Aquel código que no precisa de explicación por parte del autor, ni mediante comentarios ni mediante una explicación en vivo, es un código que respeta KISS.
Parte del trabajo de simplificar un código pasa por hacerlo legible. ¿Todos estaremos de acuerdo que si cogemos un libro en español y lo leemos, nos costará menos que coger el mismo libro en una lengua que desconozcamos, no?.
El primer paso para modificar código existente, es entender que hace dicho código, tarea facilita mucho un código que es autoexplicativo.
Aquí algunos errores y posibles soluciones
# Ejemplo en PHP
Ante todo hay que evitar usar variables con nombres genéricos, como por ejemplo file, que es una variable que he encontrado en cientos de proyectos.
Siempre que he encontrado una variable denominada file he tenido que investigar que contenía, si un la ruta al fichero, su nombre, su contenido...
Hasta aquí el articulo hablando de KISS. Al ser un concepto aplicable a tantas cosas, iremos haciendo referencia a KISS en futuros artículos con seguridad, así que si conocéis alguna principio aplicable a tantas cosas, si conocéis alguno no dudéis en compartirlo con el resto!

Original
This publication's author has indicated that the content is his/her own.
Post image : DRY - Don't repeat yourself

DRY - Don't repeat yourself

Hola! Antes de entrar en materia, dejad que me presente brevemente y os explique un poco la motivación que me ha llevado a empezar a crear este contenido.
Soy desarrollador de software desde hace más de 15 años, orientado sobre todo al ámbito de la web.  He pasado tanto por consultorías como por empresas de producto y ahora aquí me tenéis en Mamby tratando de divulgar algo del conocimiento y la experiencia que mi carrera profesional me ha permitido adquirir.
A lo largo de mi carrera he coincidido con compañeros a los que les costaba mucho hacer código que fuese mantenible. En muchas ocasiones hacían algo que a los pocos días de haberlo hecho, no podían entender su funcionamiento.Este es un problema real del día a día de los desarrolladores de software, si no se aplican una serie de buenas prácticas, a medio-largo plazo cualquier proyecto puede convertirse en una pesadilla de mantener.
Me gustaría que mi contenido sirviese a aquellos desarrolladores con poca experiencia (o no tan poca) para mejorar sus habilidades con la programación. Para ello iré añadiendo contenido de nivel básico para poco a poco ir aumentando la complejidad.
En este primer capítulo, hablaremos sobre la duplicidad de código o más bien, de cómo evitarla.
Si alguno de vosotros ha trabajado en alguna consultoría de desarrollo, os habréis encontrado seguramente con código repetido en dos o más lugares del proyecto, debido a diferentes factores como por ejemplo, la falta de tiempo, falta de experiencia o simplemente pereza de la persona que duplicó en lugar de fomentar el uso de las buenas prácticas.
El hecho de tener código duplicado en tu proyecto no en todos los contextos es una mala práctica, aunque por norma general así suele serlo.
Uno de los principales problemas que conlleva duplicar código es que en caso de tener que modificarlo, el trabajo es doble, triple o tantas veces como copias de ese código tengas en tu proyecto. Por lo que un cambio en el código, requerirá de más esfuerzo y tiempo por vuestra parte.
Otro de los problemas más importantes es que la superficie de vuestra aplicación vulnerable a fallo se va a multiplicar. 
Supongamos que trabajáis para una tienda online. Llega vuestro superior un dia y nos pide que desarrollemos una nueva funcionalidad para el carrito de compra.Quiere aumentar la conversión de clientes potenciales introduciendo cupones descuento. Para ello nos pide que en los pasos 1, 3 y 5 del carro de la compra, aparezca un campo de texto que permita al cliente introducir un texto que abarate el precio de la cesta.
¿Cómo abordariamos esta funcionalidad?
Según mi experiencia, el desarrollador medio, este sería el posible resultado de la funcionalidad. 
# Ejemplo en PHP
Como se aprecia, hay código repetido tres veces dentro de este controlador que se encarga de mantener el carrito de nuestra tienda online. Este código es perfectamente funcional y podría funcionar durante años sin problema.Pero a las dos semanas, vuelve a llegar nuestro superior y nos pide que todos los cupones deben comenzar ahora con un prefijo 'CUP' y si no es así, debemos mostrar al cliente un mensaje de error.
Llegados a este punto y con el código que hemos desarrollado, deberíamos escribir nuestro código en uno de los pasos y copiarlo nuevamente en los dos casos adicionales. Siendo muy optimistas, este cambio lo realizará el mismo desarrollador que implementó la funcionalidad en primera instancia y se acordará de que al menos duplicó el código una vez, por lo que copia el código en los pasos uno y cinco, dejando el tres sin modificar.Al cabo de unos dias empiezan a aplicarse descuentos con cupones sin prefijo y el lío está asegurado.
¿Cómo evitamos este problema?
Si todo ese código para aplicar un descuento estuviese centralizado, este problema no se hubiese producido.
Con una simple abstracción (Qué es la abstracción) podríamos haber evitado esta situación.
# Ejemplo en PHP
Ahora disponemos de la lógica para aplicar cupones en un único lugar, por lo que si añadiésemos las modificaciones para comprobar que el cupón tiene un prefijo, afectaría a todos los pasos en los que el cliente puede meter un cupón descuento.
Haremos puntualizaciones sobre DRY en futuras publicaciones matizando en que contextos es viable duplicar código, ya que este principio, choca a veces con otros y está en nuestra mano, tomar la decisión más acertada para cada etapa de nuestros proyectos.
El próximo capitulo abordaremos otro de los errores que mayormente cometemos en nuestras primeras fases como desarrolladores. Complicar en exceso nuestro código. Veremos como evitarlo con ejemplos haciendo uso del principio KISS (Keep it super simple).

Original
This publication's author has indicated that the content is his/her own.
Your avatar
Created 2 months ago