En el ambiente del desarrollo de software comúnmente nos fiamos de la exactitud, es decir la lógica de los números hace que seamos más exactos, procurando que los cimientos de cada nuevo proyecto sean lo más sólidos posibles. Sin embargo, por encima de esa manera de pensar, hay prácticas que han demostrado ser útiles por algún valor agregado que dejan al desarrollo de software a pesar no ser del todo limpias o modernas.
En programación y desarrollo, algunas ideas que realmente se ven mal a simple vista pueden ser la mejor opción para tu proyecto. Revisemos algunas de éstas y su resultado.
1) Código rápido y sucio
Pocas cosas pueden matar a un proyecto tanto como un mal diseño y un código mal documentado. Incluso si su pila de producción se levanta, mantenerlo puede ser una pesadilla. Cualquier persona que hereda un código hecho por nosotros de manera rápida y sin documentación se convierte para nosotros en un enemigo jurado de por vida.
Por otra parte, fabricar el código con ligereza y sin demoras en documentarlo puede ser la mejor manera para ahorrar costos, si tu equipo de desarrollo cobra por hora es probable que quieras disminuir algunas horas dedicadas a la limpieza del código si este simplemente es funcional. La búsqueda de un código totalmente limpio y bien diseñado puede ser costosa.
Si tienes presupuesto para documentación puedes asignar un número de horas específicas del equipo para esa tarea. Sin embargo, no todo el mundo tiene acceso a ese tipo de presupuesto y pocos desarrolladores lo ponen como un valor en sus propuestas a menos que el cliente así lo exija.
Otro punto a considerar es que una documentación exhaustiva puede ser también extremadamente compleja, un código largo lleno de referencias y notas puede ser considerado limpio pero eso no es garantía de que vaya a ser entendido rápidamente por un nuevo desarrollador. El código sucio con unas pocas explicaciones puede ser que tome un poco de tiempo para ser comprendido, pero la demora será mucho menor que si tuviéramos la documentación completa que un programador erudito hubiere preparado para el mismo.
Cualquier persona que se ha abierto paso entre páginas y páginas de código bien diseñado con capas y capas de abstracciones sabe que a veces un poco de código con una entrada sencilla y una descripción simple del trabajo, es mejor que una pila maestra de ingeniería informática. Lo primero puede tomar 10 minutos para ser entendido – las arquitecturas sofisticadas pueden tomar semanas.
Cuando el tiempo es limitado, a veces lo rápido y descuidado puede ganar y hacerlo en grande.
2) Algoritmos derrochadores
A veces ser muy inteligente no vale el precio que se paga. Esto bastante evidente cuando se trata de algoritmos con fuertes fundamentos teóricos y estudiados a fondo.
Todo el mundo recuerda y conoce la normas y las lecciones de la universidad.
Una estructura de datos inteligente hará el trabajo en un tiempo proporcional al tamaño de los datos.
Una mala estructura podría ser tan lenta en tiempo proporcional que duplicaría o triplicaría de manera exponencial el manejo de la data.
En algunos casos la situación empeora cuando el volumen de datos crece.
Las lecciones de la clase de informática son importantes. Los malos algoritmos pueden ser muy lentos.
La cuestión acá es que en teoría algunos algoritmos eficientes inteligentes pueden ser lentos también. A menudo requieren estructuras de datos complejas llenas de punteros y depósitos de valores intermedios, cachés que saturan la memoria RAM. Algunos pueden tomar meses o años para hacerlos bien. Claro, a la larga van a ser más rápidos pero como decía el economista John Maynard «En el largo plazo todos vamos a estar muertos».
Parte del problema es que la mayoría de los modelos teóricos analizan el comportamiento de los algoritmos cuando el conjunto de datos crece a tamaños grandes. Pero incluso en la era del Big Data, es posible que nuestra data no se trate de un conjunto lo suficientemente grande como para hacer uso y sacar provecho de todos los ahorros teóricos.
Muchos gerentes de proyecto consideran comúnmente que es una buena idea lanzar un algoritmo descuidado en el desarrollo, aunque sea potencialmente lento, que tener una demora grande en la entrega tratando de hacerlo teóricamente perfecto.
3) El uso de un servidor de base de datos independiente
Cuando se trata del rendimiento del software, la velocidad es importante. Unos pocos milisegundos en la web puede ser la diferencia entre la jubilación temprana y un fracaso total.
La sabiduría popular dice que: Para acelerar las comunicaciones entre las capas del software, debes tener ubicada la base de datos en la misma máquina que en la que está el software que devuelve los resultados al usuario.
Con el código de base de datos y la capa de presentación comunicados de forma rápida, se elimina la latencia de tener que hacer ping a un equipo diferente.
Excepto que esto no siempre da los resultados esperados, sobre todo cuando la máquina sola no puede servir eficientemente a las necesidades de la presentación y de la capa de base de datos.
Los equipos que hacen un buen trabajo en la ejecución de las bases de datos son a menudo muy diferentes de los que ejecutan el software de presentación.
Para complicar más las cosas, las diferencias dependen del tipo y la estructura de la base de datos que está utilizando.
Más memoria RAM siempre ayuda, pero es esencial cuando se trata de índices. Las grandes tablas necesitan mucha más memoria RAM que un gran número tablas pequeños. Si vas a hacer muchas combinaciones, puede ser mejor que vuelques totalmente la data en un servidor de base de datos independiente.
Cuando tienes tu base de datos y el resto del software en el mismo CASE el equipo se ve obligado a convertirse en un felino negociador.
Puedes ser capaz de comunicarte con el equipo con rapidez, pero la máquina difícilmente podrá estar sintonizada para desempeñar con eficiencia cada una de las diversas tareas de su código.
Ahora puedes usar un equipo distinto e incluso utilizar un servicio en la nube que gestionará tus datos de manera escalable que usará más memoria RAM cuando lo requieras y te permita crecer.
4) El uso de un CMS como un martillo grande en un clavo pequeño
Una tendencia actual es generar un núcleo central que mueve el desarrollo y lo divide en microservicios ligeros.
En lugar de construir un portal para todos tus datos, construir decenas o quizás cientos de servicios web independientes dedicados a responder a preguntas específicas y a recolectar datos específicos. Si lo haces bien, te permite crear, depurar y desplegar cada servicio de forma independiente – muy bueno para hacer cambios iterativos sin tener que actualizar una base de código monolítico.
Pero el uso de un sistema grande, voluminoso en gestión de contenidos como Joomla WordPress o Drupal para hacer la misma cosa es otra manera de servir los datos JSON o XML con un poco de reconfiguración.
Esto puede parecer una idea horrible a primera vista, la complejidad adicional del CMS sólo contribuye a ralentizar la pila de ejecución.
Sin embargo, un enfoque de uso de un CMS también puede acelerar el desarrollo y mejorar la depuración. Todo el formato de datos y la «gestión de contenidos» puede ser útil al personal interno que maneja el sistema. Incluso si no hay usuarios que toquen las capas de administración, todavía puede ser una gran ayuda para los clientes internos.
El exceso de carga puede ser un dolor de cabeza, pero es relativamente fácil de resolver mediante la adición de más potencia de cálculo en el backend.
5) La integración de la vista con los datos
Una de las reglas cardinales de diseño moderno es dividir el proyecto en al menos tres partes: almacenamiento de datos, toma de decisiones y presentación. Tales separaciones hacen que sea más sencillo rediseñar cualquier parte independiente de los otros dos.
Hay desventajas sin embargo, debido a la separación de la vista respecto de los datos, requiere que la aplicación esté reprocesando constantemente los datos para ajustarse a la plantilla actual de la vista. Gran parte de esto se repite si la plantilla sigue siendo la misma.
Últimamente, los arquitectos han ido reelaborando formatos de datos para que sea más fácil para el código de visualización el proceso de la información. El paso a estructuras de datos y bases de datos JSON y NoSQL está impulsado en gran parte por el deseo de proporcionar datos en un formato que sea más sencillo de procesar para el navegador. No está exactamente mezclando los datos con el código de visualización, pero los está moviendo más cerca.
El uso de una memoria caché es con frecuencia la manera cómo las aplicaciones mezclan código de visualización con los datos. Cuando los datos se mezcla en la plantilla, el resultado se almacena en la base de datos para ser servido y otra vez.
6) El uso de una base subóptima
Hacer una elección de arquitectura «mala» en una estrategia para un proyecto que tiene objetivos de crecimiento a largo plazo significaba la muerte inminente. En estos días, sin embargo, recuperar datos desde estructuras subóptimas pueden ser relativamente fácil, siempre y cuando se utilicen equipos en la nube, el problema sigue siendo una solución viable.
Si tu pila de servidor es lenta o las bases de datos se están estancando, siempre puedes simplemente subir el ancho de banda o alquilar más máquinas. Luego, cuando las multitudes disminuyen en tamaño, se puede regresar a la potencia de cálculo original. Cuando las máquinas adicionales cuestan solo unos centavos por hora, ya no es tan catastrófico cometer un error arquitectónico en el lanzamiento inicial.
Por supuesto, no todos los errores pueden ser cubiertos invirtiendo poco dinero en ellos. Algunas malas decisiones conducen a estallidos exponenciales cuando la empresa crece. Ese tipo de fallas pueden vaciar rápidamente cualquier bolsillo cuando el medidor de los servicios de la nube se está ejecutando. La simple elección de una base de datos bastante pesada o un filtro elaborado que duplique la lentitud no es un tema de preocupación, siempre que el modelo de consumo de datos no se agrave.
La clave es evitar los cuellos de botella en la parte central del diseño que es crucial. Mantener las partes móviles separadas e independientes ayuda a asegurar que no interfieran entre sí y produzcan un bloqueo mortal. Mientras la arquitectura central no produzca estancamiento, las malas decisiones pueden ser cubiertas con un hardware más rápido. No es nada elegante, pero a menudo es eficaz.
Facebook, en sus inicios comenzó a usar PHP, uno de los primeros lenguajes para desarrollo de aplicaciones web que ya se sentía un poco anticuado en el momento en que la red social se lanzó. Las cuestiones desagradables sin embargo, molestaban a los programadores, no a los usuarios. A pesar de la sintaxis extraña y una capacidad limitado, el enfoque de PHP era sólido.
Facebook por el contrario ha estimulado el desarrollo de PHP desde la creación del HHVM, una versión mucho más rápida que inspiró una reescritura del núcleo de PHP. Ahora Facebook ejecuta el código antiguo mucho más rápido y los usuarios no conocen que la empresa está asentada sobre una plataforma de elección temprana que todavía hace que que los ojos de algunos programadores se salgan de sus órbitas.
La elección de una solución aceptable es muchas veces más barata que la ingeniería de un nuevo enfoque sofisticado. Si sientas a todo el mundo ha rediseñar el software para que se ejecute sin problemas y eficientemente, podría costarte una fortuna. Un programador inteligente cuesta $ 200.000 al año, pero mismo valor puede costear más de millones de horas de servidores en Amazon. Ese recurso inteligente no vale la pena cuando puedes tener hardware barato y rentable por hora con un desarrollo simple o considerado no tan óptimo.
7) Mantener el código sucio producción
Un equipo de gerentes alguna vez me llamó para mirar a una aplicación web de lujo, moderna desarrollada con las últimas ideas y el lenguaje más reciente (Java, en ese momento). El problema eran las quejas de que la antigua unidad central que se comunicaba con las terminales tontas monocromáticas era mucho más rápida en la percepción de todos los que tuvieron que utilizar la nueva aplicación. La frase que se escuchaba con frecuencia era: ¿No podemos volver a la tecnología de la era de los 60?
Uno de los nuevos programadores de Java, incluso dijo frustrado algo así como: «No es justo comparar el nuevo desarrollo con la aplicación antigua de pantalla verde. Estamos haciendo mucho más. Por «más» quería decir el uso de fuentes para web, colores de buen gusto y formas responsivas que siempre encajan en las ventanas de tamaño variable. Los mismos datos habían sido depurados en la base de datos, pero la gente que contestaba los teléfonos recordaba lo rápido que era trabajar con las pantallas verdes chillones con sus fuentes de ancho fijo.
La última tecnología de software no siempre representa una mejora. Hay bromas en el ambiente de programación que dicen que «los ingenieros de software se demoran millones de horas para hacer que el código nuevo funcione tan lento como lo hacía el primero». Sin embargo, si fuera así no habría necesidad de un nuevo hardware.
Algunos programadores serios hablan con tonos graves acerca de temas como «deuda técnica» y «refactorización continua». Ellos hablan con conocimiento de la importancia de invertir en la restauración de código. Pero a veces, todos los sueños de borrón y cuenta nueva o volver a escribir todo desde cero se convierten en una pesadilla.
Es una decisión difícil. Si el código viejo está libre de errores o en su defecto, la reescritura es la única opción. Pero a veces la reconstrucción de una aplicación simplemente para mantenerla actualizada puede ser un gran error. A veces es mejor ir hacia atrás que terminar con una arquitectura moderna escrita con el último lenguaje de programación lanzado, pero repleta de nuevos y recientes errores que también vendrán con ella.
