12 señales de que eres un mal programador

[[AzidRain]]

No se critica el uso de patrones o UML lo que se critica es que se piense que se deben utilizar para todo y en todo cuando sabemos que no es cierto. Un programa sencillo que realice cosas sencillas normalmente no necesitará patrones y mucho menos UML. A lo mejor un proyecto grande que durará varios meses y que involucrará a varias personas si lo incluirá. El UML normalmente lo maneja el arquitecto de software, no el programador directamente.

A cuantos no les ha pasado que hacen su UML muy bonito y detallado y al pasarlo al código hay cosas que simplemente no pueden hacerse tal como lo marca el diagrama o bien para hacerlo implica escribir más código. Finalmente yo creo que si no necesitas UML o patrones u OOP, no te compliques y simplemente haz que funcione. A fin de cuentas al cliente final le viene valiendo un soberano sorbete si lo hicieste con las patas o con las manos o con el librito de moda o con lo mejor de tu repertorio de OOP. Lo que quiere un cliente siempre será:

1.- Que el programa haga lo que te pidió.
2.- Que se lo entregues rápido.
3.- Que no le cueste mucho.

El punto 1 se resolverá de una o de otra manera, siempre llegarás a lo mismo. Pero el punto 3 depende directamente del punto 2. De manera que si te metes a patrones, UML y demás cosas sin analizar bien si de verdad lo necesitas utilizarás probablemente más tiempo que si no lo haces y por lo tanto tu costo se incrementará. Claro que igual y le cobras lo mismo trabajando más tiempo pero entonces estás depreciando tu trabajo.

Los clientes nunca entenderán nada que tenga que ver con hacer diseño previo a menos que efectivamente sea algo muy grande. No es lo mismo que te pidan un pequeño programa que genere un reporte de una BD a que hagas uno que realice toda la contabilidad.

Ah pero si eres dueño de una empresa mediana a grande con muchos empleados y varios clientes, entonces si que podrás darte el lujo de tardarte lo que quieras y usar patrones o UML hasta para pedir la comida. El costo del tiempo que utilices lo vas a prorratear entre todos los clientes que tienes, los cuales te dan trabajo constante. Así ni quien se queje...lo malo es que no todos hemos llegado (todavía) hasta ahí.

Bueno, mi humilde opinión nada más.

Yo en lo personal utilizo UML ( y solo algunos diagramas) cuando la idea es demasiado abstracta para entenderla como está. El propio Boosch menciona que no es necesario elaborar todos los diagramas en cada proyecto y que UML se adapta o es lo suficientemente flexible para usar lo que se necesite de acuerdo al proyecto. A veces hago solo un pequeño diagrama de casos de uso y con eso me sirve, a veces tengo que hacer uno de secuencias, etc.