12 señales de que eres un mal programador

[REHome]

«12 señales que pueden ayudarte a descubrir que eres un mal programador (y no lo sabes): el uso abusivo de patrones, usar UML por usarlo, pensar que cantidad de código equivale a productividad... Puede que no esté de acuerdo con todas, pero es una lectura interesante.

1. Java es todo lo que necesitas.
No ves la necesidad de usar ningún otro lenguaje, ¿por qué no se puede hacer todo con Java? No te importa ver código en Python o Ruby que logra en 10 lineas lo que llevaría varias hojas de código Java. Además, seguramente las nuevas características de la próxima versión del lenguaje lo arreglaran de todas formas. (Esto es aplicable a casi cualquier lenguaje, pero ocurre que entre la comunidad Java parece estar más extendida esta forma de pensar)

2. El término "enterprisey" (NT: se trata de un término sarcástico utilizado para designar productos complejos más allá de lo necesario) no te suena a broma.
"Enterprise" no es sólo una palabra, es una filosofía, una forma de vida, un camino a la iluminación. Cualquier cosa que pueda ser escrita, desplegada o actualizada con un trabajo mínimo es descartada como un juguete que no "escalará" para futuros usos. Mientras tanto la mayor parte del trabajo real en tu oficina se hace enviando hojas de cálculo en Excel mientras esperan a que termines de construir tu nueva visión corporativa.

3.Te opones férreamente a las funciones/métodos de más de 20 líneas de código.
(o 30 o 10 o cualquier otro número) Lo siento, algunas veces una función larga es justamente lo que necesitas. Normalmente las funciones cortas son más sencillas de entender, pero algunas veces se pueden expresar más fácilmente en una sola función más larga. El código no debería hacerse más complejo sólo para adecuarse a criterios arbitrarios.

4. "¡OH DIOS MÍO! ¡PATRONES!"
Los desarrolladores que buscan constantemente la forma de aplicar patrones a cualquier problema de código con el que se encuentran están añadiendo una complejidad innecesaria. Lejos de ser algo que busques, deberías sentirte mal cada vez que tienes que utilizar un patrón de diseño, significa que estás escribiendo código que hace las cosas más complicadas y que puede ser de dudosa utilidad. Pero, ¡ey!, tu código tiene patrones, bien por ti.

5. Los ciclos de CPU son un recurso precioso y tu estilo de programación y lenguaje reflejan esas creencias.
Hay montones de problemas en los que tienes que tener muy en cuenta el consumo de CPU (modelado/simulación, procesado de señales, kernels de sistemas operativos, etc), pero no es tu caso. Para la mayor parte de los desarrolladores de software sus principales problemas de rendimiento están relacionados con las bases de datos y la entrada/salida. El único efecto de optimizar tu código para mejorar el uso de CPU será disminuir en 2 milisegundos el tiempo necesario para la próxima consulta a la base de datos. Mientras tanto el desarrollo de la aplicación se hace más lento, no puedes hacer frente a los nuevos requerimientos y te encuentras con problemas serios de calidad. Pero al menos estás ahorrándote montones de ciclos de CPU… eventualmente.

6. Piensas que ninguna función/método debería tener más de un return.
Esta la he oído alguna que otra vez, y normalmente la razón que me dan es que el código es más sencillo de analizar. ¿Según quién? Yo encuentro más fácil de leer un código más simple, y normalmente el tener más de un return simplifica el código.

7. Tus usuarios son estúpidos. Realmente estúpidos.
Simplemente no puedes creer lo estúpidos que son, olvidándose constantemente de hacer las cosas más sencillas del mundo y cometiendo errores tontos al usar tu aplicación. Nunca has considerado que quizás es tu aplicación la que es estúpida porque eres incapaz de escribir software decente.

8. Te enorgulleces enormemente del gran volumen de código que escribes.
Ser productivo es bueno, desafortunadamente escribir montones de líneas de código no es lo mismo que ser productivo. Los usuarios nunca comentan "Guau, este programa puede ser difícil de usar y estar lleno de errores, pero al menos sé que hay un montón de código por debajo." En lugar de ser productivo, generar toneladas de mal código retrasa a los demás desarrolladores y en el futuro su mantenimiento constituirá una pesada carga.

9. Copiar y pegar es genial, te ayuda a escribir código desacoplado.
Defiendes tu uso del copy paste con extraños argumentos sobre desacoplar código y eliminar dependencias, mientras ignoras el aumento del tiempo de mantenimiento y los problemas de duplicación de errores. A esto se le llama "racionalizar tus acciones".

10. Piensas que la gestión de errores consiste en capturar todas las excepciones, registrarlas, y continuar como si nada.
Eso no es gestionar errores, eso es ignorar errores y es el equivalente semántico al "on error next" de VB. Sólo porque hayas registrado el error en algún sitio no significa que lo estés tratando. Tratar errores es algo duro. Si no sabes qué hacer exactamente cuando te encuentras con un cierto error, simplemente deja que la excepción se propague y que un nivel más alto del código lo trate.

11. Modelas todo tu código en UML antes de escribirlo.
El modelado entusiasta de UML se lleva a cabo normalmente por aquellos que no escriben demasiado código, sino que se consideran arquitectos de software. Las herramientas de modelado atraen más a aquellos que piensan que el código se puede escribir en una sala de conferencias manipulando pequeños gráficos. Los gráficos no son el diseño, y nunca serán el diseño, para eso está el código.

12. Tu código borra datos importantes.
Escribiste un cierto código que se supone que debe sobrescribir los archivos de la aplicación con otros nuevos, pero se vuelve loco y borra todos los datos del usuario.


Fuente:
http://mundogeek.net/archivos/2007/1...l-programador/

[[AzidRain]]

Empezado por REHome

El modelado entusiasta de UML se lleva a cabo normalmente por aquellos que no escriben demasiado código, sino que se consideran arquitectos de software. Las herramientas de modelado atraen más a aquellos que piensan que el código se puede escribir en una sala de conferencias manipulando pequeños gráficos. Los gráficos no son el diseño, y nunca serán el diseño, para eso está el código.

Esa es una verdadera joya, la cual ya había descubierto por mi mismo...jejeje cuanta razón hay en eso

[droguerman]

pienso que la 11 está algo salida, un buen modelamiento ayuda bastante si vas a diseñar componentes o librerías de código mejor aun si lo documentas con UML

[[Al González]]

Empezado por droguerman

...un buen modelamiento ayuda bastante si vas a diseñar componentes o librerías...

13. Le llamas "librerías" a las bibliotecas.

Aclaro que no es personal Droguerman, es para motivar conciencia en todos los desarrolladores que emplean mal ese término.

Saludos.

Al González.

[Julián]

¿que son los patrones?
¿que es el UML?

¿como coño he podio hacer tantos programas sin saber que son esas cosas?
¿como es posible que mis clientes esten satisfechos?

Un saludo!

[Casimiro Notevi]

Empezado por Julián

¿que son los patrones?

Son esos tipos que en lugar de empleados tienen trabajadores... y en lugar de dirigir y organizar sólo saben ordenar y mandar.
También son los encargados de pagar, aunque pagan poco.

Empezado por Julián

¿que es el UML?

Es un sindicato de "hombres duros" e independientes: Unión de Machos Libres...

Empezado por Julián

¿como coño he podio hacer tantos programas sin saber que son esas cosas?

Eso digo yo, ¿qué tendrá que ver el patrón y el sindicato con la programación?

Empezado por Julián

¿como es posible que mis clientes esten satisfechos?

Eso tú sabrás, pillín

p.d. Tanto tiempo sin verte por aquí.

[adfa]

Pues como todo punto de vista son discutibles muchas aseveraciones.

1.Java es todo lo que necesitas.
Conozco varios de esos, aca estoy de acuerdo, a cada perro con su collar.
Hay lenguajes mejores para algunas tareas que otros. Aunque tambien depende del framework que tengas hecho con anteriores trabajos, porque en cualquier lenguaje puede ser algo sencillo si ya tienes la utilidades desarrolladas.

3.Te opones férreamente a las funciones/métodos de más de 20 líneas de código.
El código corto es generalmente más facil de enteder, pero estoy de acuerdo no hay porque ser dogmático en esto, siempre es mejor ver que complica más.

4. "¡OH DIOS MÍO! ¡PATRONES!"
Un patrón puede ser algo muy útil, sobre todo los básicos como singletons, etc.
No creo que todo deba llevarse a ellos, pero ojo son una buena herramienta.
Como todo en la vida, hay una cantidad que siempre es buena.

5. Los ciclos de CPU son un recurso precioso y tu estilo de programación y lenguaje reflejan esas creencias.
Depende de que desarrolles, o en que lugar.

6. Piensas que ninguna función/método debería tener más de un return.
No creo que algunos return compliquen, pero si son muchos...

7. Tus usuarios son estúpidos. Realmente estúpidos.
Bueno, hay muchos usuarios que si lo son, me han tocado algunos que ni siquiera saben cuales son las flechas de desplazamiento del cursor, ni el retroceso y apenas saben que es el "enter".
Pero voy a quebrar una lanza por los usuarios, que levante la mano quien a nunca a dicho: "no este control no lo voy a hacer porque no esto no va a pasar".
Como todo en esta vida, nada es blanco o negro si no un gran gama de grises.

9. Copiar y pegar es genial, te ayuda a escribir código desacoplado.
Lo de desacoplado me parece que no tiene nada que ver. Copiar y pegar tiene sus cosas buenas y malas. A veces no nos acordamos de como usar algo y lo copiamos, eso si hay que extremar las precauciones porque siempre nos olvidamos de cambiar algo

10. Piensas que la gestión de errores consiste en capturar todas las excepciones, registrarlas, y continuar como si nada.
Este este todo un tema....

11. Modelas todo tu código en UML antes de escribirlo.
Por supuesto que no modelo todo en UML, pero es una estupenda herramienta. Sirve para aclarte ideas, te ahorra escribir código, dejar documentadas cosas que luego olvidaras si escribieras el código a las carreras.
Nunca se me ocurriría criticar el uso de UML, en grandes empresas sobre de todo puede ser sumamente necesario.
Aunque como dije antes en cosas chicas no lo use.

Saludos

[radaalvaro]

Compañeros.

Los "patrones" son utilizados para el diseño de aplicaciones, ya que se sabe que son una SOLUCIÓN EFICIENTE a un PROBLEMA COMÚN; por eso su existencia. El uso excesivo de ellos, quizas no sea muy eficiente, pero en aplicaciones grandes, es muy útil.

UML, de UML, yo creo que no se puede hablar mal, Cualquier Sistema de Información grande, debería estar documentado (no es solo tener lineas de comentario dentro del código fuente) y UML es una herramienta potente que nos ayuda a hacer esta tarea, además que nos que ayuda a minimizar la cantidad de PARCHES en un futuro (Minimizar, no desaparecer), y hacer un software ROBUSTO.

Sin ánimo de ofender a nadie, ni crear polémica, es solo mi opinión.

Saludos.

[[Delphius]]

Hola a todos,
Uno dicen que cuando algo el calzado le anda, que lo use. Lamento decirlo pero aquí hay puntos que me "calzan":

4. "¡OH DIOS MÍO! ¡PATRONES!"
Los desarrolladores que buscan constantemente la forma de aplicar patrones a cualquier problema de código con el que se encuentran están añadiendo una complejidad innecesaria. Lejos de ser algo que busques, deberías sentirte mal cada vez que tienes que utilizar un patrón de diseño, significa que estás escribiendo código que hace las cosas más complicadas y que puede ser de dudosa utilidad. Pero, ¡ey!, tu código tiene patrones, bien por ti.

¡Si vamos a generalizar, generalizemos!

Los patrones nacieron de mentes entusiastas y genias con el afán de que el desarrollo sea menos caótico.
A ver yo me pregunto... ¿y es que acaso si tengo un problema con una calculadora me voy a poner a buscarle la quinta o la octava pata al problema empleando patrones, aun incluso si el sistema no amerita llevar un diseño orientado a objetos?
Dejemos algo en claro: a problemas simples, soluciones simples. A problemas grandes soluciones grandes. Ver una generalización tan absurda es una falta de respeto hacia las ilustres mentes quen han hecho su aporte.
Por poner un ejemplo: ¿Si no llevo un empleo de los correctos usos de los adecuados patrones para un sistema como el que estoy desarrollando para mi tesis (que ya no hace falta nombrarlo por aqui) me ahorro dolores de cabeza?

11. Modelas todo tu código en UML antes de escribirlo.
El modelado entusiasta de UML se lleva a cabo normalmente por aquellos que no escriben demasiado código, sino que se consideran arquitectos de software. Las herramientas de modelado atraen más a aquellos que piensan que el código se puede escribir en una sala de conferencias manipulando pequeños gráficos. Los gráficos no son el diseño, y nunca serán el diseño, para eso está el código.

Otra vez, la absurda generalización. La misma situación: problemas chicos, soluciones simples... problemas grandes, UML.
¿Desde cuando un elemento gráfico o un lenguaje visual no es parte del diseño? ¿O sea que con leerme el código me basta para asimilar la idea o comprensión de un sistema?
¿O sea que el código es diseñar?

Quien usa UML y Patrones no lo emplea y lo obedece como si fuera la biblia, pero es que tampoco debemos despretigiar su uso. Por algo han sido concebidos ¿no?

Yo defiendo y soy partidiario de UML y de los Patrones, pero esto no quiere decir que sea de una mente cuadrada (fuera comparación con mi apellido) como para imponer su uso. Ya lo he dicho: UML y Patrones se usan cuando las circunstancias lo ameritan... ¿Pero que lo use en las mayorías de las ocasiones me hace ser un mal programador?

Yo de entrada no me considero programador, como la mayoría de los que aqui han intervenido lo saben, pero vamos...
¿No crees que ha sido un poco absurda la generalización de dichos puntos? Independientemente de si eres Analista, Ingeniero, Tester, Programador, Fulanito, Menganito... Sea quien seas (dentro de la amplia rama de la informática y del desarrollo de software) Considero que esos puntos (como los otros) no son suficientes como para calificar a uno como malo o bueno.

Disculpen que lo diga... pero el autor de ese texto, no sabe lo que ha dicho. Y no tiene ni idea.

Saludos,
PD: ¿No sería oportuno que esto esté en la sección debates? Digo... tiene mayor sentido allí que en Noticias.

[[Delphius]]

Hola de nuevo,
Es posible que a más de uno no le sea de agrado el comentario que hice anteriormente. Mis más sinceras disculpas, pero es que considero que tales palabras frente a UML y a los Patrones, son una falta de respeto a quienes se han tomado el tiempo para investigar, estudiar y forjar dichos conceptos e ideas.

UML y Patrones si se usan en forma adecuada no proporcionan ninguna desventaja alguna.

Es posible que debía haber tenido mayor sentido de humor, como dice uno de los comentarios del sitio a que remite REHome, pero es que ante tal sentido de expresión no vale el sentido de humor.

Saludos,

[Ñuño Martínez]

¿Qué es "desacoplar código"? En serio, no tengo ni idea de lo que es.

Y ya que estamos: Soy un programador excelente porque no caigo en ninguno de esos doce puntos. ¡Bien por mi!

[[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.

[[Al González]]

Y como dice Ian Marteens, «todavía hay quienes piensan que la programación puede mecanizarse».

Algunas cosas sí pueden / deben encuadrarse en diagramas. Pero ni tanto que queme al santo, ni tanto que no lo alumbre.

Más vale proyecto en mano que UML volando.

El que buena cobija se arrima, le cae un árbol encima.

Perdón, me entró un ataque de refranes.

Lo que sí me pareció muy interesante fue la ponencia de ayer sobre UML en Delphi, aunque me hubise gustado ver un caso más práctico.

Un abrazo con el santo encimado en el árbol y envuelto en una cobija.

Al González.

[[Delphius]]

Empezado por 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.

Es muy cierto lo que dices AzidRain, pero hay maneras de decir las cosas, y a mi "calzó" la manera en que lo dijo. Me parece una absurda generalización, si el autor original del tema hubiera redactado con otras palabras sus pensamientos yo no me hubiera puesto agreviso-defensivo con su punto de vista.

Y yo también aplico UML, no todo... sólo lo que considero que me aporta valor y refresca la idea, o intensión del problema. Lo que si llevo siempre, y podría considerarse como mi biblia, es hacer casos de uso. Me ayuda muchísimo.

Saludos,
PD: ¿Podría algún moderador que se pase por aqui mover este hilo a debates? Considero que es allí donde el tema es adecuado.

[xander]

He de confesar que despues de ver esta conversación he caido en la cuenta que entonces no soy un programador malo, soy MALISIMO!!!

En mi equipo de trabajo tenemos ya un buen rato implementando Xtreme Programming, y hasta ahora no hemos necesitado otro lenguaje que no sea Delphi, Como sabrán los entendidos del tema , la programación extrema se basa en iteraciones en el desarrollo, donde la idea es ir avanzando y mejorando el código en cada iteración, pues bien siempre estamos viendo la manera de mejorar lo que se escribió en su momento, implementando patrones de diseño, refactorizando procedimientos largos y con esto al mismo tiempo haciendo self-documenting con la nomenclatura de los procedimientos.

Para nosotros los usuarios son verdaderamente estúpidos, pero si los dejas hacer una estupidez ya es culpa de uno, así que una preocupancia en la que enfatizamos es en hacer Programas APP (osease A Prueba de Pendejos), eso es una máxima que nos ha ahorrado muchos problemas.

Vaya que quien ha escrito estas sandeces es un tipo que no tiene ni p*t@ idea... deberían colgarlo de los aguacates hasta que pida clemencia y se retracte.

[Ñuño Martínez]

Empezado por xander

Para nosotros los usuarios son verdaderamente estúpidos, pero si los dejas hacer una estupidez ya es culpa de uno, así que una preocupancia en la que enfatizamos es en hacer Programas APP (osease A Prueba de Pendejos), eso es una máxima que nos ha ahorrado muchos problemas.

Axioma del programador número 1138:

"Cada vez que un programador termina un programa a prueba de tontos, la naturaleza crea una nueva especie de tonto"

No he podido resistirme...

[MAXIUM]

5. Los ciclos de CPU son un recurso precioso y tu estilo de programación y lenguaje reflejan esas creencias.

7. Tus usuarios son estúpidos. Realmente estúpidos.

5. Cuando trabajaba en un 386 encontraba todo tan rápido, hasta que me compre un 486. En todo caso uno nunca se conforma con la velocidad y al poco tiempo el cerebro termina acostumbrando a la frecuencia y encuentra todo lento, sobre todo los usuarios.

7. Sí, lo son...