| diciembre 2005 » |
| lun | mar | mié | jue | vie | sáb | dom |
|---|
| | | | 1 | 2 | 3 | 4 |
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | | 16 | 17 | |
| 20 | | 22 | 23 | | 25 |
26 | 27 | 28 | 29 | 30 | 31 | |
| | | | | | | |
| Hoy |
Blog::Navigation
Bookmarks::Blogroll
Bookmarks::Articulos
Blog::Referers
Las visitas de hoy a la página: 153

domingo diciembre 18, 2005
El primer punto negro, obvio Como adelantaba en mi primer post, estas primeras entradas del blog
pienso dedicarlas a exponer lo que yo llamo "puntos negros" en el
desarrollo de aplicaciones. Estos puntos son lugares o prácticas que
tienen un buen porcentaje de probabilidades de convertirse en marrones
para los programadores (lo que yo, "cariñosamente" llamo chollos).
El "Punto Negro" de hoy, por ser el primero va a ser el mas obvio de todos: "El diseño de la lógica de negocio".
Habitualmente, las aplicaciones empresariales se centran especialmente
en la capa de datos y la de presentación, mientras que la lógica de
negocio suele limitarse a recibir datos de la capa de vista y pasarlos
a la capa de acceso a datos, dedicandose, si acaso, al control
transaccional o a pequeñas operaciones (generalmente conversiones o
formateos de datos).
Este hecho hace que habitualmente el diseño de aplicaciones en tres
capas se "relaje" (por no decir que, literalmente se pase de él) y se
empiecen a hacer llamadas a los componentes de acceso a datos desde la
vista o que se utilicen objetos de la vista en los componentes de
datos.
Si no se es muy (muy mucho) escrupuloso con la arquitectura, se corre
un grave peligro de que caiga un marrón gordo. ¿Por qué? Porque siempre
(siempre siempre) el cliente va a querer algún cambio en la aplicación
y ese día, aparecerá el analista y dirá que el cliente ha pedido tal y
cual cambio, y que el susodicho cambio es una pijada y que solamente
tienes que cambiar aquí y allí tres cosas y listo... Y una m****a (¿en
este blog se puede decir mierda?)!!!. Como la aplicación no tenga un
diseño cristalino (de claro, no de frágil), hacer retoques puede ser,
sin lugar a dudas, el marrón mas gordo que un programador se puede
comer.
Una recomedación para evitar enmarronarse con este "punto negro" es
evitar como a la peste las "ñapas" (N del T: utilizar malas
prácticas de programación para quitarse de enmedio el trabajo lo antes
posible). Siempre el trabajo tiene que estar hecho "para ayer", así que
poner como escusa que hay poco tiempo no vale.