Tag Archives: desarrollo de software

Inteligencia de negocios en la nube

La mayoría de los sistemas que manejan grandes cantidades de información dentro de las empresas, son desarrollos in-house, o a la medida desarrollados por alguna entidad externa pero con la participación del cliente. Muchos de estos desarrollos tienen un análisis de requerimientos y un diseño muy pobres y/o el cliente no está seguro de lo que necesita hasta que lo prueba y el tiempo y costos del proyecto se ven seriamente afectados con los ajustes.

Uno de los principales factores que llevan a un proyecto como este a fracasar o terminar de una manera no deseada es la infraestructura del cliente, que en la mayoría de las ocasiones por cuestiones burocráticas, se vuelve difícil acceder a los servidores y optimizarlos para que el rendimiento de la aplicación antes, durante y después de la salida a producción sea el adecuado.

Sin pretender hacer una labor de mercadotecnia de un producto que no desarrollamos, me gustaría hablar de una posibilidad de evitar o aminorar estos problemas con un producto que pretende lanzar Google y que vale la pena echarle un ojo.

Google está desarrollando un servicio en la nube que permite analizar una gran cantidad de información. Se llama BigQuery. En un principio, ayudará a las organizaciones a analizar sus datos sin necesidad de construir o configurar infraestructura para ello. La compañía aprovechó los desarrollos internos que usa para analizar sus productos como GMail y AdSense, y llevó sus algoritmos a la nube para brindar la opción a ciertas empresas de subir sus datos(y alternativamente guardarlos) en grandes cantidades y posteriormente ejecutar análisis tal como se hace con cualquier sistema de inteligencia de negocios.

Una de las ventajas de este servicio es que se elimina el uso de un data warehouse; tanto el desarrollador como el cliente evitan preocuparse por la seguridad pues se usa la infraestructura y cuentas de Google para ello y además se automatizan los respaldos de la información cargada. Sus capacidades parecen ser simplemente sorprendentes: procesar billones de registros en segundos, capacidad de almacenar terabytes de información, facilidad de ejecutar análisis mediante consultas tipo SQL, administrar los grupos y usuarios a través de la cuenta de correo electrónico, seguridad mediante SSL y el poder acceder a la información a través de cualquiera de sus interfaces: BigQuery browser, línea de comandos, a través de su API con arquitectura REST o Google Apps Script.

A pesar de que lo escrito anteriormente puede sonar a promoción, personalmente lo veo como una gran oportunidad de negocio, por lo menos de manera alternativa, para las empresas o desarrolladores independientes de hacer llegar una solución con bajos costos pero con muchos beneficios a los clientes que lo necesiten y no estén dispuestos a mantener un sistema desarrollado in-house.

Si están interesados en sus bondades, quieren darle seguimiento a este servicio y ver la posibilidad de crear algo interesante, cuenten conmigo para hacerlo.

Espero sus comentarios.

Código apestoso

El crear software, a mi muy humilde opinión, más que una profesión o un burdo oficio (para muchos), es un arte que requiere de toda la creatividad, dedicación y pasión necesarias ya que no es solo cuestión de cumplir con n requerimientos y que el programa “corra”, realmente hacer un buen programa requiere de un proceso mucho más complejo y parte de este complejo proceso es escribir código de calidad, pero ¿qué implica esto?

La calidad es un concepto tan abstracto que fue necesario crear una lista interminable de reglas y normas para poder “alcanzarla” pero todos sabemos que eso no es suficiente siempre existe una falla y la calidad se pierde un poco. En software es evidente que no es la excepción y averiguando un poco descubrí que en la programación orientada a objetos un par de muchachos: Kent Berck y Martin Fowler definieron un concepto muy ilustrativo para detectar problemas dentro del código: bad smells in code o malos olores en el código.

Este concepto se refiere a detectar algunos problemas como: tener muchos parámetros dentro de un método, o tener clases muy largas con muchas responsabilidades, o clases que dependen mucho una de la otra y así una lista un poco extensa de los muchos problemas que pueden encontrarse dentro del código de cualquier programador, por muy experto que este sea.

Pero  y ¿esto de qué nos sirve? Pues la respuesta más inmediata es: estos “olores” nos ayudan a detectar errores de forma (estilo o modo de escribir el código) en nuestras líneas de código y nos permiten optimizarlas para realmente tener un programa con cierta calidad.

Y ¿qué “olores“ se pueden encontrar? A continuación listaré una serie de “malos olores” y a qué se refiere cada uno.

Nombre ¿A qué se refiere?
Comentarios Se tiene un exceso de comentarios dentro del código. Los comentarios existentes contestan más a la pregunta ¿por qué lo hace? que la pregunta ¿qué hace?
Método largo Se tiene un método demasiado largo. Los método cortos son más fáciles de entender, de leer y de mantener.
Lista de parámetros muy larga Entre mayor sea el número de parámetros, mayor será la complejidad del método.
Código duplicado El código duplicado es la ruina del desarrollo de software. Hay que evitar esto a toda costa.
Explosión combinatoria Se tienen métodos que hacen casi lo mismo pero, el comportamiento de la información varía poco.
Clases largas Tal como los métodos muy largos, las clases muy largas son muy difíciles de mantener, de entender y de leer.
Tipo dentro del nombre Se tienen tipos de datos en los nombres de los métodos. Esto no sólo es redundante sino que obliga a cambiar el nombre del método si el tipo cambia.
Nombre poco comunicativo. ¿El nombre del método describe lo que este hace?
Nombres inconsistentes Si ya se ha elegido un estándar para asignar métodos, es necesario que este estándar se siga.
Código muerto Se tiene código que no se usa.
Especulación general Se tiene código que “resuelve” problemas del futuro pero no los presentes.
Solución excéntrica Se tienen varias soluciones para un mismo problema.
Campo temporal Se tiene un objeto con muchos campos innecesarios.

Bueno, lo más interesante de esto ¿cómo arreglar estos problemas? Pues para esto se usa una técnica llamada “refactorización” pero, este tema es un poco extenso así que lo dejaré para el próximo número. Espero que estos problemas sean mínimos en nuestros códigos.