Thursday, January 22, 2009

Utilizar Expression para lograr AOP: primitivo pero interesante

Esta es una idea que me vino a la cabeza y que no tengo tiempo de desarrollar ahora. Y tampoco quisiera que se me olvidara.

La principal dificultad a la que se enfrentan los frameworks que ofrecen AOP es la intercepción de las llamadas a los métodos. (Por cierto, este framework luce prometedor: PostSharp)

¿Y si al escribir el código los desarrolladores utilizaran un método que recibe como parámetro un Expression, un Action o un Function, que sirva para aplicar aspectos?

Debo mirar con más profundidad.

Thursday, January 15, 2009

Tenemos un equipo de probadores! (Testers)

Me gusta pensar que mis opiniones al respecto han tenido algo que ver con que finalmente contemos con un equipo dedicado exclusivamente a probar como lo haría un usuario.

No creo que esté muy bien articulado, pues a pesar de estar en la habitación contigua no tenemos interacción con estos testers más que a través de los jefes de proyecto.

Aún así, creo que es un paso de avance y mejorará la calidad de los productos que entreguemos.

Dado el paso de asumir el gasto necesario ahora sólo falta que se interesen por obtener el mayor beneficio a cambio, implementando mecanismos de interacción entre equipo de pruebas y equipo de desarrollo que favorezcan un ciclo rápido de retroalimentación mutua.

Peligroso UpdatePanel

El UpdatePanel es una golosina para los desarrolladores. Es muy fácil de utilizar y da al usuario una magnífica impresión: mira, las páginas no pestañean todo el tiempo!

Sin embargo, al menos para nosotros, ha resultado una trampa. No he hecho un análisis profundo de toda la funcionalidad que provee, pero hemos encontrado muchísimos problemas:

  1. Al combinarlo con JavaScript.
  2. Al combinar varios UpdatePanel... las interacciones son difíciles de preveer y las consecuencias nefastas.

En honor a la verdad, no toda la culpa es del UpdatePanel. WebForms en sí mismo también ha influido bastante. Por lo tanto:

  1. Migremos a MVC!
  2. Si tienes que usar WebForms, no utilices el UpdatePanel sólo porque es fácil, sin haber estudiado las limitaciones que impondrá a la aplicación.

Wednesday, January 14, 2009

Buen código == Sentido común y cohesión == satisfacción

Si programamos como si estuviéramos creando una teoría llegaremos a un punto en la vida de nuestra aplicación en el que hacer cambios y mejoras se convertirá en el placer de descubrir que "sólo" tendremos que reutilizar lo que ya está hecho.

En una teoría todos los elementos, salvo los axiomas, se derivan unos de otros y es "fácil" crear nuevos teoremas a partir de los que ya se conocen mediante derivaciones lógicas.

Este punto no es fácil de alcanzar, requiere de una buena guía (léase arquitectura + convenciones) y sobre todo de una gran disciplina y esfuerzo por mantener la cohesión de lo que se genere.

Creo que en esto consiste "programar bien" y es lo que persiguen por diferentes vías las metodologías existentes.

En la analogía, que no pretende ser muy estricta, en nuestro programa crearemos nueva funcionalidad a partir de la existente, ya sea reutilizando o modificando. Mientras más fácil sea comprender lo que ya se ha hecho, y cómo funciona, más fácil será reutilizarlo y modificarlo para lograr nuestro objetivo.

Mantener la cohesión requiere aplicar las "buenas prácticas", en especial:
  • Asignar nombres explicativos absolutamente a TODOS los elementos (métodos, variables, clases) por muy insignificante que parezcan.
  • Aplicar SIEMPRE las reglas de nomenclatura que se decidan, de forma que cada nombre contenga la mayor cantidad de información posible para un lector.
  • Mantener la relación entre los nombres y la funcionalidad. Sí, aunque requiera renombrar un archivo en el control de versiones.

Muchas veces he visto como alguien (incluyéndome) crea un pedazo de código "rapidito" para resolver un problema, sin pensar a largo plazo. 2 horas después este pedazo es incomprensible para todo el mundo (a veces incluso para la misma persona que lo escribió), y por lo tanto, no reutilizable ni modificable.

También he visto como se hace una modificación de la funcionalidad sin adaptar los nombres de los elementos involucrados, con idénticas consecuencias.

Estos fragmentos de código actúan como aglutinantes y en poco tiempo habrá más código dependiente de este que tampoco será reutilizable ni modificable.

Lo mínimo que debe hacer un buen programador es mantener la cohesión al nivel que le corresponda:

  • Desarrollador: clases, funciones, propiedades, variables.
  • Arquitecto: todo

Desafortunadamente, las reglas de negocio que debemos implementar seguramente están entre las teorías con menos cohesión que existen. A veces incluso ni se pueden considerar teorías porque hay reglas que se contradicen! Pero ya eso no está en nuestras manos. Lo que podemos hacer es mantener el desorden al mínimo, localizado en la implementación de esas reglas.

Monday, January 12, 2009

Sin llegar al absurdo: entrega al cliente algo sobre lo que pueda opinar

La comunicación con el cliente es mucho más sencilla cuando ambas partes pueden referirse a algo tangible. Por lo tanto, creo que siempre que sea posible se debe hacer un despliegue temprano de la aplicación y fomentar la crítica del cliente.

http://feeds.jeffreypalermo.com/~r/jeffreypalermo/~3/501921276/

Esto tiene el incoveniente de que para el cliente siempre es difícil determinar la profundidad con la que debe probar una funcionalidad, pero si se gestiona bien y con tacto esto es mucho mejor que obtener la opinión del cliente cuando ya se ha avanzado mucho en el desarrollo.