Ya vamos para dos meses en Accenture, sí, esa firma grande de IT Consulting donde trabajo. Algunas frases y palabras que he escuchado y me han quedado sonando en el transcurso de estos casi dos meses (dentro y fuera de la empresa).

  • Escalar
  • Reunión
  • Te Cuadra?
  • “Eres débil” - De Benito a cualquiera que no quiera seguir tomando.
  • Parametrico
  • Harina de Pescado
  • “de que”.
  • “…Que te cagas”
  • Interfaz
  • un audio
  • Modulo, Componente y Rutina
  • “La metodología” - ver artículo de Joel Spolsky cortesía de Federico.
  • Control de Cambios
  • Funcional
  • Técnico
  • Le Garage
  • La Guayaba
  • Hamacas
  • “Va invitar” o el imperativo: “Invite pues”.
  • Nos Impacta?
  • “Como vamos con el cronograma?”
  • You know mi hermano!
  • Yoda - Nick de Andrés
  • “En que anda?”

Creo que ya ha sido suficiente :P. En el trabajo estamos haciendo Big Design Up Front (BDUF) y no es el de Joel Spolsky, es realmente un BDUF para hacer un desarrollo en cascada (que no me gusta nada). Por tal motivo, ahora no estoy tocando nada de código sino “analizando” y diseñando. Lo malo (o lo bueno) es que creo que soy yo también el que le va tocar implementar el sistema, osea yo mismo me puedo echar cuchillo.

Como es de esperar, en “la metodología” de la empresa implica hacer un sin número de documentos, yo la llamo una metodología orientada a los deriverables :P. En todo caso, me ha tocado desarrollar muchos diagramas de clase, cosa en la cual ya tenía algo de experiencia, pero que siempre había usado como un sketch al mejor estilo Fowleriano.

En este caso no podía hacer esto, y para poder definir el comportamiento del aplicativo, una vista estática como lo es el diagrama de clase, sencillamente no es suficiente. Inclusive, para definir adecuadamente la vista estática, no es suficiente tener una idea de como van a interactuar la clases. Entonces, pensé en un diagrama de secuencia para los casos de uso principales podría ser de ayuda. Efectivamente, esto no solo me ayudó a refinar el diagrama de clase, sino que también me permitió a ser mucho más concreto y preciso en el mismo. Eso me gustó mucho y ahora recomendaré que, luego de haber definido las principales clases y relaciones entre las mismas, escribir un diagrama de secuencia para los casos de uso más importantes. Sin embargo, y quiero ser muy enfático en esto, el diagrama de clases, luego de hacer los de secuencia no estaba completo. Le faltaban (y aun le faltan) cosas. Debo decir que para mi gusto, el diagrama está lo suficientemente concreto para poder escribir código. Lo anterior solo me confirma lo que dice el mismo Fowler en el libro al que hago referencia arriba: lograr un diseño completo desde el principio, sino imposible, es muy , pero muy difícil. Pero bueno, no soy yo el que pone las reglas del juego y me tocará tratar de hacer lo mejor posible cada fase (y pues iterar por mi cuenta cuando sea necesario).

Otra practica que me pareció interesante (y que personalmente nunca había hecho) fue la de escribir pequeñas CRC para mi, con esto vislumbré que clases debían dividirse (por el principio de única responsabilidad) y con que otras clases tenían relación.

Volviendo a lo de BDUF (porque no sé para que dije todo el rollo anterior, creo que quería desahogarme), encontré un artículo muy interesante sobre la tragedia del Challeger y los diseños top-down (que es básicamente BDUF) y como se relaciona con el desarrollo de software actual:

Richard Feynman, the Challenger Disaster, and Software Engineering

Bueno, creo que es todo lo que quiero comentar por ahora. Como parroquial, comento que el gran día ha llegado y me gradúo mañana a las 3 de la tarde en el teatro metropolitano de la hermosa ciudad de Medellín. Muchas gracias a todos los que escribieron con frases de apoyo y felicitación.

Tagged: