jueves, 21 de octubre de 2010

Cuidado! Un copo de nieve

Así como un simple copo de nieve puede convertirse en una bola de nieve incontrolable, a menudo en los sistemas ocurren situaciones similares.

Algo aparentemente tan inofensivo como no cambiar a tiempo el nombre de una tabla/campo de la base de datos o no renombrar una clase o método de la aplicación para que sea más representativo y coherente, puede originar una serie de pequeños inconvenientes y confusiones hasta convertirse en poco tiempo en un problema grave de mantenimiento.

Muchas veces me he encontrado con pequeñas y medianas empresas y organismos públicos que vienen trabajando con una o más soluciones de software desde hace varios años y han llegado a un punto donde el mantenimiento se ha vuelto tan costoso que dan ganas de tirar todo y empezar de nuevo, lo cual generalmente es inaceptable (aunque muchas veces no quedan muchas alternativas).

En estos sistemas, tareas habituales como solucionar un bug, agregar una nueva feature o una simple mejora pueden volverse tan complejas que muchas veces se prefiere no hacerlas o (lo que es peor) tratar de resolverlas con alguna artimaña rebuscada, con algún truco o parche. Lo que redunda una vez más en una mayor complejidad aumentando los costos de mantenimiento del sistema.

Todo es difícil

En estos sistemas todo se ha vuelto difícil.

La estimación de tareas es difícil. Una tarea que debería ser simple y fácil, se convierte en compleja y difícil y lleva mucho más tiempo del estimado.

No hay tiempo para análisis. Se necesita tiempo para analizar el impacto de agregar o cambiar cierta funcionalidad, pero no hay mucho tiempo porque estamos atrasados. Entonces, programemos y listo.

La programación diaria es frustrante. Lidiar todos los días con código difícil de leer, seguir y depurar se convierte en una tarea frustrante.

No hay tiempo para testing. Apenas alcanza el tiempo para desarrollar. Con suerte, el desarrollador alcanza a realizar un testeo superficial, una prueba de humo (Smoke Test) y el producto está listo para producción (Menos mal que no fabricamos autos o aviones).

La reutilización de componentes es un chiste. La complejidad de todo el sistema hace muy difícil crear funciones o componentes reutilizables. Recordemos que tampoco hay mucho tiempo para analizar. Como resultado se crean piezas de software muy similares una y otra vez, extendiendo los tiempos de desarrollo y aumentando aún más la complejidad.

La incorporación de nuevos desarrolladores es costosa. La productividad de los nuevos desarrolladores es muy reducida durante un largo tiempo, pues necesitan mucho más tiempo para entender el código pre-existente y poder hacer algo útil. Un desarrollador Senior se convierte en Junior. Y un desarrollador Junior cambia su color de pelo y religión.

Un salvador por aquí

En medio de todo el caos, aparece el desarrollador imprescindible. El más experimentado de los desarrolladores suele convertirse en el salvador de la empresa o del producto. Es el único capaz de entender la solución actual. Él sabe que se puede “tocar” y que no, cuándo tocar y cuando no. Él entiende el porqué de las cosas (no siempre). Sin saberlo, esto le genera una alta presión y exigencia, que se transforma en Stress y cuando Él se enferma, la empresa se “enferma”. Si Él se va de vacaciones, la empresa se “sufre”. Y si Él renuncia, la empresa empieza a “agonizar”. Esta situación es muy perjudicial para una empresa.

¿Cómo se llega a esta situación?

Como lo decía Pablo en la TV: “Una seguidilla de hechos bochornosos”. Generalmente, el problema principal suele ser una carencia total de arquitectura empresarial. Por diferentes motivos se ha subestimado el valor de construir sistemas basados en una arquitectura sólida. A esto se le suma una serie interminable de vicios: desde el simple desconocimiento de mejores prácticas de programación, al código heredado de diferentes programadores o equipos de programación, y también se puede sumar tecnologías y lenguajes de programación obsoletos.

Incluso una arquitectura sobredimensionada o exceso de patrones de arquitectura (patronitis aguda) pueden terminar con una solución inmanejable. Aunque esta última “enfermedad” no es muy común, lo más habitual es encontrar “antipatronitis crónica”.

¿Qué se puede hacer?

Cuando se llega a esta situación, el costo de intentar arreglar la solución actual puede ser más costosa que empezar de nuevo. Y cuando la tecnología en la cual está basada el sistema ha quedado obsoleta, ya no tiene mucho sentido arreglarlo.

Asumiendo que la tecnología del sistema no es obsoleta, hay que analizar cada caso en forma particular para determinar si todavía existen chances de cambiar la situación actual (cuando no se trata de una situación irreversible).

Alguien podrá decir: “Los sistemas siempre se pueden corregir”. Si, es verdad, el punto es que en ciertas situaciones el costo de “corregir” puede superar ampliamente el valor del sistema. En estos casos se opta por seguir lidiando con los problemas o empezar de nuevo.

¿Se puede evitar esta situación?

Absolutamente. Solo es cuestión de tener algunas cosas básicas:

  1. Un equipo de trabajo
  2. Una metodología de trabajo
  3. Una arquitectura de software clara y consistente.
  4. Un diseño de base de datos coherente
  5. Mejores prácticas de desarrollo

Pero por sobre todas las cosas hay una que quizás es la más importante: Ganas de mejorar desde el primer día. Esto no incluye solo al equipo de sistemas, sino a toda la empresa.

Saludos, Gus

Todo el problema no está en la programación

Trabajando en muchos proyectos para organismos privados y públicos he visto una y otra vez cómo los sistemas llegan a un punto extremo donde los problemas abundan y las soluciones escasean.

Desafortunadamente, muchos piensan que el problema de los sistemas inestables y costosos de mantener es solo un tema de programación.

La realidad es que el problema casi siempre viene originado por una mala arquitectura, malas prácticas de programación y malos diseños de bases de datos.

Enfocándome en el diseño de bases de datos, un mal diseño complejiza enormemente todo el sistema. No soy experto en bases de datos, pero como desarrollador de sistemas empresariales, el diseño de bases de datos relacionales debe ser un conocimiento básico y fundamental.

Me sorprende encontrar continuamente bases de datos con graves problemas de normalización, graves problemas de inconsistencia de datos, nombres de tablas y columnas incomprensibles o totalmente confusas, etc. Ni hablar del mal uso de los tipos de datos o la ausencia de los índices mínimos para acelerar las principales búsquedas. Posiblemente tampoco exista un plan de backup y mucho menos un plan de restauración testeado. ¿Y la seguridad? Nosé, hay un guardia en la entrada del edificio.

Una situación común es que se crea una tabla o campo con cierto nombre, luego se utiliza en diferentes partes del código. Pasa el tiempo y se le agregan nuevos campos para cubrir nuevos requerimientos. Tiempo después, el equipo se da cuenta que el nombre ya no es representativo. La tabla que se llamaba Ventas, ahora también almacena las Compras, y se prevé que posiblemente también almacene otros comprobantes como Remitos, Notas de crédito, etc.

Un nombre más representativo debería ser Comprobantes, incluyendo un campo discriminador que determine el Tipo de comprobante. Pero el equipo se resiste a cambiar de nombre o crear una nueva tabla, argumentando que también debería actualizar el código de la aplicación, las vistas y los procedimientos almacenados  dependientes, y eso es una tarea muy compleja.

Es cierto, es una tarea compleja. Es un cambio que puede “romper” muchas cosas. Pero es un cambio importante para mantener la salud del sistema. Si no lo hacemos, estamos ampliando los problemas futuros de mantenimiento. Empezamos a complicar las cosas. Creamos la primer bola de nieve que irá creciendo.

Alguien preguntará:

“¿Qué hago con los sistemas externos que dependen de esa base de datos?”

En primer lugar no debería tener sistemas externos que dependen directamente del esquema de la base de datos. ¿Donde quedaron los web services y la interoperabilidad? Si este es el caso, quizás las vistas o sinónimos de bases de datos puedan ayudar a disminuir el alto acoplamiento.

Conclusión:

Se necesita coraje y una visión de sistema saludable a largo plazo para saber que ciertos cambios son posibles y necesarios en el momento oportuno y si no se atienden, se convierten en una enfermedad que nosotros mismos creamos.

También hay que saber que existe mucha bibliografía, documentación, blogs y varias herramientas para refactoring de bases de datos. Es cuestión de conocerlas y saber usarlas cuando se necesitan.

Incluyo aquí algunos links interesantes sobre refactoring y deployment de bases de datos:

En futuros posts intentaré dedicar tiempo a los proyectos de bases de datos para Visual Studio.

Saludos, Gus.

lunes, 18 de octubre de 2010

Microsoft Sync Framework: 'min_active_rowversion' no es un nombre de función integrada reconocido

Me he encontrado con este mensaje de error al intentar sincronizar 2 bases de datos: SQL Server 2005 y SQL Server 2005 Express en una virtual PC con Windows XP.

Al buscar un poco en la red, encuentro que la función min_active_rowversion está disponible con el Service Pack 2 de SQL Server 2005.

Inmediatamente verifico si lo tengo instalado ejecutando el comando:

select @@version

Microsoft SQL Server 2005 - 9.00.1399.06 (Intel X86)   Oct 14 2005 00:33:37   Copyright (c) 1988-2005 Microsoft Corporation  Standard Edition on Windows NT 5.1 (Build 2600: Service Pack 3)

Una rápida lectura permite ver que tengo instalado el Service Pack 3. Entonces intento ejecutar el comando:

select min_active_rowversion()

y obtengo el mismo mensaje de error inicial.

Vuelvo a buscar en la documentacion oficial, los foros, blogs, etc. y encuentro una y otra vez que tal función está disponible con el SP2 de SQL Server 2005.

Empiezo a pensar que el SP3 que tengo instalado no incluye al SP2, lo cual me parece raro porque el SP3 es generalmente acumulativo. Empiezo a generar diferentes especulaciones y dudas, sigo buscando en la red, hasta que se me ocurre volver a leer el mensaje de select @@version:

Microsoft SQL Server 2005 - 9.00.1399.06 (Intel X86)   Oct 14 2005 00:33:37   Copyright (c) 1988-2005 Microsoft Corporation  Standard Edition on Windows NT 5.1 (Build 2600: Service Pack 3)

Bingo! El service pack 3 que tengo instalado no es de SQL Server sino de Windows XP.

Así que decido descargar e instalar el SP3 de SQLServer 2005 y también el SP3 de SQL Server 2005 Express.

Después de instalar el SP3 (tarda un rato) vuelvo a ejecutar el comando select @@version obtengo el siguiente mensaje:

Microsoft SQL Server 2005 - 9.00.4035.00 (Intel X86)   Nov 24 2008 13:01:59   Copyright (c) 1988-2005 Microsoft Corporation  Standard Edition on Windows NT 5.1 (Build 2600: Service Pack 3)

Ahora veo que tengo una versión mayor y el comando select min_active_rowversion() ya no muestra un error.

Finalmente, pruebo mi aplicación de sincronización y todo funciona correctamente. Los registros de base de datos se sincronizan sin problemas.

Conclusión:

Yo debo leer mas detenidamente los mensajes. Pero el equipo de SQL Server podría reconocer que es un poco confuso agregar el service pack instalado de Windows al consultar la versión de SQL Server.

Espero que sirva.
~Gus

Próximamente: IIS Express

Nuevamente Scott Guthrie nos comenta en su blog sobre esta novedad interesante para los desarrolladores de ASP.NET que proximamente estará disponible en forma gratuita.

Pueden ver el post original o su traducción al español por Juan María Ramos.

Enjoy it!
~Gus

viernes, 15 de octubre de 2010

SQL Server CE embebido en ASP.NET

Estas últimas semanas estoy bastante atareado aprendiendo y creando soluciones con VSTO (Visual Studio Tools for Office). Ya tengo agendado media docena de posts sobre este tema para compartir.

Pero ahora quiero compartir otra novedad que me parece muy interesante y útil para muchos.  Hace pocas semanas Scott Guthrie anunciaba que proximamente estará disponible una beta de SQL Server CE 4 (Compact Edition).

Pueden leer el post original de Scott o la traducción al español del bueno de Julian Ramos.

Actualmente pueden descargar el CTP 1 (Community Technology Preview) de SQL CE 4 desde el siguiente link: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=0d2357ea-324f-46fd-88fc-7364c80e4fdb&displaylang=en

Con SQL CE 4 podremos disponer de un motor de base de datos liviano en nuestros sitios web que no requiere la instalación ni configuración de ningún servidor de base de datos.

Solo hay que copiar los ensamblados de SQL CE 4 en nuestro directorio /bin y ya tenemos un motor de base de datos disponible en nuestra aplicación. Sin permisos especiales, sin cuentas administrativas, sin instalación, sin configuración. SQL CE 4 creará archivos de datos con extensión sdf que podemos alojarlos en nuestra carpeta /App_Data.

Una buena noticia es que este motor de SQL CE 4 será compatible con nuestras tecnologías de Acceso a datos como ADO.NET u ORMs como Entity Framework o NHibernate. Adicionalente, podremos escalar nuestra base de datos a motores más avanzados como SQL Express, SQL Server o SQL Azure simplemente cambiando nuestra cadena de conexión.

Un punto a saber es que esta versión de SQL CE no soportará procedimientos almacenados, un feature bastante común en muchos desarrollos, pero muy prescindible para quienes trabajan con ORMs.

Bueno, espero que sirva.
Saludos, Gus