Complejidad Ciclomática

Alguien ha decidido que este blog es un buen escaparate para publicar información sobre proyectos web 2.0 y me han enviado una nota de prensa por si me interesa. A pesar de ser consciente de que es publicidad voy a comentarlo porque creo que es un proyecto interesante, sobre un tema en el que hace unos meses mis compañeros de trabajo y yo estuvimos hablando.

Se trata de migoa.com , un buscador vertical de propiedades, vehículos y empleos, que ha recibido 280.000 € de una firma de capital-riesgo y del empresario catalán Albert Armengol, un individuo que se hizo conocido hace un tiempo por haber vendido el portal de networking eConozco.

Viendo las últimas noticias y lo que pude palpar en blogak, ahora mismo hay dos conceptos protagonistas para los emprendedores en Internet : el video y los buscadores verticales -sobre todo inmobiliarios-. ¿Cómo consiguen los buscadores inmobiliarios contenido de búsqueda? La opción de los webcrawlers de properazzi me parece interesante pero sería más eficiente contar con la colaboración de las inmobiliarias o directamente con las constructoras pero creo que hay un choque de intereses que no favorecen esta opción. Quizás el error es pensar que los buscadores van a sustituir a las inmobiliarias en lugar de presentarlos como un canal más para estas presenten sus ofertas.

Ahora migoa está en beta privada y en otoño pretenden abrirlo al público de España, Francia y Alemania. Por cierto, otro proyecto asentado en Barcelona… el Silicon Valley europeo.

Las empresas multinacionales son tan poderosas que es peligroso que se inmiscuyan en temas sociales y políticos, pero también lo es que solamente se dediquen a maximizar sus ganancias.

Dilema de Goodpaster y Mathews

Ayer por la noche estuve en el cafe Retros de Santander(C/. Santa Lucia) disfrutando del concierto de Small Details [WEB] , [MySpace]. Era la primera vez que les escuchaba y sinceramente me quedé gratamente sorprendido. Unos sonidos cinematográficos de los que no es habitual escuchar en España y menos en Cantabria. Pese a que no está bien etiquetar a los grupos diré que son como portishead pero más jazzisticos o tal vez como Marlango.

Escuchad el directo que tienen en MySpace y si teneis oportunidad de asistir a un concierto suyo no lo dudeis; la música, la voz y el ambiente son un auténtico lujo. Los conciertos se suelen anunciar en el fotolog del bateria.

Espero que alguien haya perdido el trabajo por esto

Tyler Durden en Fulltime Killer 

El dileme del prisionero dice lo siguiente “Supongamos que se detienen a dos componentes de una banda criminal, que son encarcelados. Cada prisionero está aislado sin poder comunicarse con el otro. La policia reconoce que no tiene suficientes pruebas para condenarlos por la acusación principal. Por lo tanto, piensan sentenciarlos a los dos con 1 año por un cargo menor. Sin embargo, la Policia ofrece a cada prisionero el siguiente pacto: Si testifica contra su compañero será libre, mientras que el otro será acusado del cargo principal lo que conlleva 3 años de prisión. Pero existe una trampa: si los dos prisioneros testifican el uno contra el otro, se condenará a ambos a dos años en prisión. Los prisioneros deberán decidir al mismo tiempo y no sabrán la decisión del otro hasta que lo hayan hecho”.

Lo curioso de este dilema es que desde la perspectiva de cada jugador la estrategia que tomaría , acusar al otro, parece la más racional y sin embargo,  el resultado no es óptimo. Este dilema es una abstracción de situaciones que se dan diariamente cuando nos relacionamos con los demás (Prestar apuntes, los escapados en una carrera de ciclismo etc…) Es muy interesante realizar este ejercicio con múltiples interacciones y estrategias. Parece demostrado que a lo largo del tiempo los individuos que cooperan  obtienen mejores resultados. Una táctica que se ha demostrado efectiva es comenzar cooperando pero en las siguientes interacciones tomar la misma decisión  en cada una de ellas lo que el otro hizo contigo en la anterior.Esta táctica es positiva porque:

1.  Evita conflictos innecesarios; nunca se toma la iniciativa de dejar de cooperar.
2. Capacidad de defensa; en caso de que otro jugador no coopere en la siguiente interacción tu tampoco lo harás permitiéndote defenderte.
3. Mostrar indulgencia, si otro jugador vuelve a cooperar tu lo harás en la siguiente oportunidad.
4. Clara, el resto de los jugadores rápidamente conocen tu forma de actuar.

No parece una estrategia “muy moral” de actuar en la vida pero sin embargo, es mejor que actuar con egoismo y es muy justa: uno no exige más de lo que está dispuesto a dar.

No obstante, lo verdaderamente racional es actuar para que no se den situaciones “del dilema del prisionero”.

Los antipatrones son “fórmulas literarias que describen soluciones comúnmente dadas a problemas que generan consecuencias negativas irremediablemente” según William J. Brown, coautor del libro “Antipatterns” publicado en 1999.

Los tipos de antipatrones que hay son tres: antipatrones de desarrollo de software, antipatrones de arquitectura de software y antipatrones de gestión de proyectos de software.

El estudio de los antipatrones es muy útil porque sirve para no escoger malos caminos en el desarrollo de sistemas, teniendo para ello una base documental y así evitar usar simplemente la intuición. Además proporciona una denominación común a problemas que facilita la comunicación entre diferentes desarrolladores.

Antipatrones de desarrollo de software

• The Blob

Este antipatrón se da en objetos con muchos atributos o muchas operaciones. Esto rompe las ventajas de la programación OO, ya que estas clases tan grandes son muy difíciles de mantener, de reusar y de probar. Suele aparecer por un diseño malo o debido a sistemas heredados. El tamaño de estos objetos perjudica su tiempo de carga.

Ejemplo -obtenido de http://www.antipatterns.com/briefing/ -:

Los métodos y atributos relacionados deben situarse en sus lugares naturales.

• Lava Flow

Este antipatrón se da cuando se entrega software antes de ser terminado o suficientemente probado que tiene un código no óptimo y al ser expuesto, sus características no pueden ser modificadas – como un flujo de lava cuando se solidifica -.

Al ser utilizado por usuarios o a partir de otros componentes, el margen de posibilidades para realizar modificaciones posteriores a su entrega es muy reducido. Si se encuentran debilidades en el diseño o en la realización, pero que permiten de todas formas su utilización, éstas probablemente no podrán ser corregidas, dado que los usuarios o las aplicaciones que utilizan el software ya se han adaptado a sus características manera de evitar este problema es fijando un alto nivel de calidad o pruebas en el software como paso previo a su distribución.

• Poltergeist

Esta mala práctica se refiere a objetos de un ciclo de vida corto cuya única función suele ser invocar métodos de otros objetos. Esto hace que crezca la dificultad para mantener el sistema. Suelen identificarse por su nombre: “start_”, “manager_”. La solución para evitarlos es eliminarlos y poner su funcionalidad en la clase a la que invocan.

• Golden Hammer

Este antipatrón se refiere al uso de una tecnología, patrón, arquitectura etc.. para cualquier problema o situación incluso cuando es evidente que no va ser útil.

• Spaghetti Code

Este antipatrón se refiere a un código mal estructurado, ausente de estructuras de control etc… Es frecuente cuando usamos GOTOs, programamos a base de interrupciones o excepciones etc. También es frecuentemente denominado “Código canguro” por lo contiguos saltos que hay que hacer en él para seguir el flujo de ejecución.

Cerca del 50% del tiempo de las operaciones de mantenimiento de este tipo de aplicaciones se invierte en descubrir como funcionan. En la programación orientada a objetos, este tipo de código es  tiene clases con muchos métodos sin parámetros, aparecen clases “extrañas”, variables globales etc…

• Magic PushButton

Esta mala práctica se da en el desarrollo de interfaces gráficas. Primero construiremos la interfaz y luego las llamadas a la lógica de negocio se realizan en los huecos de los métodos de acción de los elementos de la interfaz.

Los problemas que acarrea esta práctica son: Código asociado a cada botón crece de manera inmanejable y parte de la lógica de negocio aparece en la capa de la interfaz, crecen las dificultades para realizar cambios en la interfaz de usuario o al agregar una nueva, aumento de la dificultad para realizar pruebas, etc…

La solución a este antipatrón pasa por la creación de una sub-capa dentro de la capa de presentación que sirva “de intermediaria” con la capa de la lógica de negocio.

• Optimization Premature

Este antipatrón sucede cuando un programador permite que las consideraciones de costo en tiempo o espacio afecten el diseño de un componente de software antes de tener un diseño correcto, lo que puede resultar en un diseño más complicado que lo necesario.
Un mejor enfoque es el de diseñar primero, luego codificar el diseño y finalmente tomar en cuenta las consideraciones de costo  para decidir en que partes se debe invertir tiempo para realizar optimizaciones.

• Hard Code

Esta práctica se refiere a incrustar datos directamente en el codigo de una aplicación que deberían ser obtenidos de archivo, de la línea de comandos etc. Esto hace que cualquier cambio implique la modificación del código fuente. El ejemplo más habitual es fijar en el código el path de un fichero, si este cambia el programa no funciona. Lo correcto sería obtener la ruta de un archivo de configuración.

• Zero means null

Esto sucede cuando en una aplicación o BBDD se admite un valor como “ausencia de valor -null-” sin verificar si se va dar.
Lo correcto es usar la representación de valor nulo y de no existir, profundizar en la aplicación y en el dominio para tomar un valor que no pueda darse y tomarlo como nulo. Si no encontramos un valor para asignarlo a nulo deberemos usar otros sistemas, como booleanos, para indicar si el campo esta o no definido.

• Singleton

Muchos desarrolladores piensan que el patrón “Singleton” de GOF es en realidad un antipatrón, las razones que esgrimen son su naturaleza estática y su disponibilidad pública que permite la escritura de componentes que referencian a otros de manera poco clara. En definitiva podemos resumir:

a) Los singleton hacen que tengamos que movernos por el código para estudiar las dependencias en lugar poder saberlas viendo los interfaces de nuestras clases.
b)Los singleton permiten controlar las instancias de nuestras clases, esto no está bien porque una clase solo debe tener responsabilidades de negocio. Para controlar la creación de clases deberemos usar un patrón Factoría sobre las clases de negocio.
c)Dificulta las pruebas de código ya que promueve un alto acoplamiento.

• Dredge

Este patrón se da en los accesos a datos. Consiste en realizar una “query” muy cara -muy grande- en lugar de varias sucesivas más ligeras. Se debe realizar un estudio de complejidad temporal y espacial de la búsqueda y sus alternativas para quedarnos con la opción más óptima. -La que menos recursos consuma o la más rápida en función de nuestras necesidades o limitaciones-.

Antipatrones de arquitectura de software

• Stovepipe enterprise

Este mal se da cuando disponemos de varios sistemas aislados entre si – lo que se llama islas de automatización – y que no pueden colaborar entre si para desarrollar otros sistemas más grandes y útiles para la organización. Sucede cuando no se dispone de una planificación de los sistemas y no se ha tenido en cuenta la interoperatibilidad.
En los últimos tiempos han aparecido multitud de arquitecturas que pueden ayudar a solucionar este antipatrón como son los servicios web,E.D.A, etc…

• Stovepipe system

Este antipatrón se refiere a 2 posibles circunstancias:

a) Un sistema que no puede interoperar con el resto de los sistemas de una organización.
b) Un sistema heredado que un ensamblaje de pequeños sistemas que están tan unidos entre si que no es posible diferenciar cada uno de ellos, imposibilitando su actualización, refactorización etc… También serán de este tipo de sistemas aquellos donde no este disponible hardware de sustitución o donde se haya perdido el código original. Al final será preciso la construcción de un nuevo sistema que sustituya a este.

• Vendor Lock-In

El antipatrón “Vendor Lock-in” sucede cuando dependemos de una arquitectura, plataforma o tecnología. Esta dependencia puede tener unas consecuencias muy negativas puesto que nuestros desarrollos pueden ser dependientes de características proporcionadas por terceros, pueden verse “rotos” por el cambio de las características de estas tecnologías, etc…

Este antipatrón esta muy relacionado con el de “lava flow” porque los sucesivos cambios en plataformas hacen que tengamos porciones de código cuya única finalidad sea soportar versiones determinadas y que muchas veces no sea óptimo.

La solución para evitar estos problemas es colocar una capa de aislamiento entre nuestras aplicaciones y la plataforma de desarrollo.

• Big Ball of Mud

Relacionado con Spaghetti Code, nos encontramos esta mala práctica que se refiere a arquitecturas de software que son indistingibles. Suele aparecer el proyectos desarrollados como piezas independientes o desarrollados por personas sin formación en Ingeniería de Software.

• Gas Factory

En Ingeniería de Software esta mala práctica se refiere a diseños o implementaciones demasido complejos para los riquisitos de los que parten.

Antipatrones de gestión de proyectos de software

• Analysis Paralysis

Parálisis del Análisis (en inglés analysis paralysis) sucede cuando se pretende descubrir y modelar todos y cada uno de los detalles de un sistema informático en una fase inicial, invirtiendo un tiempo excesivo con la intención de no regresar a la etapa de análisis. Las dos creencias que provocan este fallo son la creencia de que se ha de codificar solo cuando se ha terminado el análisis y que una vez que hemos comenzado a codificar no se debe volver al análisis.
Frecuentemente se desarrollan proyectos no lleguen a implementar prototipos porque se ven inmersos en una constante fase de análisis.

• Corncob

Es habitual que en el desarrollo de un proyecto de un proyecto de software, ciertas personas dificulten su desarrollo. Se ha calculado que al menos la mitad del tiempo en un proceso de desarrollo de software se invierte en la comunicación entre personas. Las dificultades de comunicación son debidos al stress, a la personalidad, a la falta de preparación, negativa a recibir formación etc…

Las soluciones que se han encontrado para estas situaciones son muy variadas; desde una reducción del stress a fiestas de reconciliación, pasando por entrevistas o el clásico que apela a la responsabilidad: “el problema lo has creado tú así que es tu problema”.

• Reinvent the wheel

Este es un antipatrón obvio; en muchas ocasiones por falta de un estudio de las tecnologías, diseños o posibilidades existentes se pierde mucho dinero y tiempo desarrollando cosas que ya estaban en el mercado o que ya se encontraban disponibles.

Hoy se ha celebrado la segunda edición de Blogak. Ana, sacando fotos, y yo, haciendo live blogging, hemos intentado hacer un seguimiento del evento en vivo. Respecto de la edición anterior se ha mejorado el contenido del evento y sobre todo, el tiempo y el control sobre el mismo en las charlas. El año pasado había poco tiempo para cada charla y además hubo un constante incumplimiento de los horarios. La exposición de Rob Malda ha sido muy interesante, aunque para los menos técnicos tal vez habido momentos aburridos. El aspecto que menos me ha gustado este año ha sido la falta de más estudiante entre el público, las fechas no han sido las mejores por los exámenes, ya que esta presencia proporcionó más interacción en las aplicaciones 2.0 durante el evento.

Para terminar una entrevista en “El Mundo” a Rob Malda.

Bueno, bueno.. al final ganó sclipo.com, después 5min.com y en tercera posición properazzi.com.

Sólo un apunte final, la web www.todosconlapantoja.com era parte del concurso de hazruido.com y no solo eso, que ha sido la ganadora. Más info.

Un aplauso para los ganadores; lástima que la gente de 11870.com no se llevara nada pues eran los favoritos de Ana y mios - aunque no me cabe duda de que es uno de los proyectos con mejor capacidad de hacer ingresos -.

Tal como se ha dicho en la charla; no tiene sentido hacer diferenciación con el género en Internet. Es decir, en la charla se ha llegado a la conclusión que no tiene sentido la charla.

Lo que todos sabemos: las herramientas para el trabajo en grupo están disponibles. El problema surge cuando los usuarios no están preparados para trabajar en grupo y para difundir conocimiento. Esta mesa está resultando muy interesante. Se ha hablado de Moodle que una plataforma educativa que se usa en muchas universidades.

Nos cuentan que el Messenger se ha convertido en lo “único” para los estudiantes de secundaria.

Por cierto, nunca me había dado cuenta lo que tardan en actualizar los buscadores de blogs.

–Actualización

Menuda intervención de txipi ! Los estudiantes de ESIDE siempre tendremos en muy buena consideración su web .