Mes: noviembre 2011

Cada cierto tiempo me gusta volver, una y otra vez, a leer este interesante articulo, que describe la decadencia en la que estan o podrian estar algunos proyectos de software. Tampoco voy a mentir u ocultar que algun proyecto que paso por mis manos (y cayo en otras) ha llegado a “podrirse” irremediablemente. Pero si analizamos el articulo a un nivel mas general, a lo que se refiere es a la capacidad y cualidad de mantenibilidad (no se si esta palabra exista siquiera) que tiene un artefacto de software. En otras palabras una pieza de software tendera a podrirse mas rapidamente mientras menor sea su capacidad de ser mantenible

Entonces. el debate que debemos enfocar en cualquier caso (creo yo), NO ES si el software debe podrirse o no, sino cuan RAPIDO debe podrirse. Porque indudablemente en algun momento ese software que tanto nos costo disenar e implementar, terminara por derrumbarse (y aqui debo hacer uso de la mala analogia con las construcciones civiles,) al igual que un edificio terminara por sucumbir a su deterioro/desgaste natural. Y los arquitectos de software, disenadores, programadores debemos asegurarnos que nuestras edificaciones sean resistentes a esa podredumbre inevitable, que trae consigo, nuestro querido amigo “el cambio”.

Nuestro software puede y debe ser resitente a factores de cambio “obvios”, es decir a aquellos factores que podemos controlar, como los que son descritos en el articulo referenciado, tales como la viscosidad, rigidez, fragilidad e inmovilidad. Por otra parte, los factores que no podemos controlar, son aquellos que produciran el deterioro “natural” de un proyecto de software. Entre los factores que esta fuera de nuestro control, puedo enumerar: Los cambios en el liderazgo, cambios de vision del proyecto, cambios tecnologicos, cambios en los recursos humanos, etc. Yo puedo aceptar que un producto de software, se deteriore “o se vaya pudriendo” por aquellos cambios sobre los que yo no tengo control, pero no aceptare nunca que el mismo producto se derrumbe por aquellos factores en los que si pude hacer algo para evitar su caida.

Desde mi humilde punto de vista y como aporte a los articulos referenciados puedo decir que, muchos problemas de mantenibilidad de un producto de software se deben a la gran diferencia, entre Resolver un Problema y Solucionar un Problema.

Aunque a primera vista ambas frases podrian parecer lo mismo, el concepto detras de “Resolver un problema” va ligado a un parche temporal que se aplica para corregir un problema reportado, en cambio el concepto de “Solucionar un problema” esta vinculado a un proceso mas prolongado de razonamiento e implementacion, para corregir el mismo problema. Mientras el que resuelve el problema ve solo el arbol y se avoca a eliminar de la lista de sus tareas ese incomodo elemento llamado bug, lo mas rapido posible y aplicando una correccion inmediatista, que tarde o temprano provocara o iniciara otro punto de deterioro. En su lugar el que soluciona el problema ve el bosque, toma su tiempo para analizar la implicancia de su correccion y elige la alternativa que brinde un balance entre la urgencia por solucionar el problema y la batalla interna por sostener una buena estructura futura que impida el inicio de un punto de deterioro.

Es por esto que en los equipos de desarrollo que he tenido el gusto de dirigir, mi sugerencia implicita o explicita en otros casos fue: En desarrollo de software, cuando encuentras un problema, por favor NO resuelvas el problema, SOLUCIONA el problema!

La podredumbre del software, se puede retrasar aplicando soluciones a los problemas que vayan apareciendo y aunque estoy consciente que en algunos escenarios no es posible tomarse mucho tiempo para razonar una solucion, siempre es posible volver hacia atras y remover ese horrendo parche que introdujimos al resolver un problema.

Saludos.

Hace un tiempo atras escribi un post relacionado a como evitar los postbacks haciendo uso de ajax y obviamente jquery (Articulo referenciado). De ese momento hace practicamente un anio y hoy con algo mas de experiencia vuelvo a analizar un tema similar.

Como pasar un objeto JSON a un Action Method?

Escenario del problema

En el controlador existe el siguiente metodo (Action Method):

La clase Person, ridiculamente simple, es como sigue:

Las partes mas importantes del codigo html son los 3 botones locos para las pruebas y los manejadores del evento click para cada boton:

La idea principal es que cuando se presione uno de los botones HTML, automaticamente se pasa desde javascript hacia el Action Method los objetos que esta esperando dicho metodo y uno de esos parametros es la clase Person que, vendra desde un objeto JSON

Soluciones posibles

Pareceria una tarea trivial, pero en MVC2 experimente dos soluciones:

1. 1. El JsonBinder que propuse en el articulo mencionado.
2. 2. Eduar Tomas critico correctamente el uso de un model binder y propuso usar un Value Provider, solucion perfecta para mis necesidades

El codigo para usar el model Binder o el Value Provider es:

Solucion definitiva

Por la necesidad de migrar mi aplicacion hacia MVC3 me vi en la obligacion de volver a analizar esta solucion y vi que MVC3 ya traer un value provider por lo que la solucion es bastante simple y es la siguiente:

Lo mas importante a destacar de la solucion es la utilizacion del atributo contentType y de que todos los parametros se colocan en un unico objeto JSON y luego son sometidos al JSON.stringify.

Espero que les resulte util, tambien les dejo adjunta la solucion que utilice para que puedan hacer sus propias comprobaciones.

Abrazos