diciembre 2005 »
lunmarmiéjueviesábdom
   
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
XML

Blog::Navigation

Bookmarks::Blogroll

Bookmarks::Articulos

Blog::Referers

Las visitas de hoy a la página: 153

Powered by Roller Weblogger.
« Previous day (dic 17, 2005) | Main | Next day (dic 19, 2005) »
20051218 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.
Copyright (C) 2003, Angel Retamar Arias