12 se�ales de que eres un mal programador

Visto en Digg. 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.