Desarrollo enmarcado

La mayor técnica de desarrollo en equipo que se usa en las empresas (no por su efectividad si no por su simplicidad) es empezar a echar líneas de código a ver lo que sale.

Si las cosas se piensan mejor, se pueden pensar una serie de directrices que deben seguir los programadores ya que “la traducción” del negocio a líneas de código se hace con una relación más o menos mecánica.

Por ejemplo, si se tiene que hacer una aplicación que guarde informes que siempre tienen tres partes bien diferenciadas entonces:

•        A ver lo que sale: Se hace la división de alto nivel del trabajo que el responsable considere oportuno (tu las ventanas, tu guardar en base de datos, tu la ventana de informe de gasto que tiene una lógica mas compleja, etc…) y cada programador se pone a la tarea. Las fronteras van a apareciendo a medida que se desarrolla y se resuelven como se puede
•         Enmarcado: Se considera todo el problema sin dividirlo y se define una base que al crecer puede dar una solución al problema. Primero se desarrolla un CORE que crea un informe base que es común y es muy configurable para poder dotar a cada informe de su forma definitiva. Cada programador parte de ese CORE para implementar su tarea.

Mucho ojo con el desarrollo enmarcado ya que conceptualmente todo es muy bonito pero los problemas de verdad (los que hacen perder tiempo o pueden tumbar una idea) aparecen siempre a bajo nivel. Se debe tener una CORE maduro antes de empezar a programar y uno de los programadores que participaron en el CORE debe de hacer uno de los informes. Esto último es importante ya que por muy bien que se piense el marco de trabajo cuando se divida el trabajo (dentro del marco) empezaran a aparecer problemas y habrá que ajustar el marco. También es importante elegir el (o los) informe que tiene que hacer el programador del CORE, tiene que ser lo mas representativo posible.