Hace 16 años | Por Zootropo a mundogeek.net
Publicado hace 16 años por Zootropo a mundogeek.net

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 volumen de código equivale a productividad, ... Puede que no esté de acuerdo con todas, pero es una lectura interesante.

Comentarios

D

Algunos puntos son muy discutibles. Además, si haces todo lo contrario a lo descrito, serás igual de mal programador. En la moderación está la virtud.

q

De acuerdo con #1. Me hace bastante gracia el tono evangelizador y de conocedor de la verdad absoluta del post:

"Piensas que ninguna función/método debería tener más de un return."
Sí bueno y quien ha escrito esto se ha lucido al considerar que una función es lo mismo que un método. Supongo que para él un procedimiento es también otro sinónimo... Y sí, una función sólo debe devolver un valor, sino sería un procedimiento aunque según el lenguaje no puedas hacer esa distinción y tú mismo tienes que tener en cuenta esta diferencia.

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

Según él diseñar es ponerse a programar. Supongo que a él le parecerá estúpido alguien que se tira una semana con lápiz y papel antes de ponerse a programar por ejemplo...

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

Sí claro, sólo hay que preocuparse de la base de datos... Como si no fuera habitual usar arrays inmensos en lugar de listas enlazadas con el desaprovechamiento e impacto que esto tiene en muchas aplicaciones no tan extraordinarias, o hacer búsquedas para encontrar la relación entre dos objetos en ejecución en lugar de tenerlos ligados desde el principio... Se me ocurren bastantes otros ejemplos. No digo que haya que programar pensando en el rendimiento y la eficiencia desde el principio, más bien se aconseja lo contrario... Pero llegará el momento que tendrás que mirar esas cosas y no sólo en las llamadas a la base de datos o la entrada/salida como sugiere el post.

D

No estoy de acuerdo:
3. Me opongo a los métodos de más de... 300 líneas
4. Patrones, siempre hay que aplicar al menos uno: KISS
5. Los ciclos de CPU son importantes, si usas for anidados aprende a usar break
7. Tus usuarios son estúpidos, es ley de vida... tenlo en cuenta al programar
9. Copiar y pegar es bueno, la primera vez que lo haces (la segunda ya no)
11. UML es el diseño, el código es sólo lo que importa

Zootropo

#1 Por supuesto

Zootropo

¿Un negativo por decir por supuesto?

Alguno debería volver a mirar (o mirar por primera vez) para qué sirven los negativos en los comentarios

D

#4 ni caso, hay mucho aburrido por aquí

(P.D: Yo no he sido pese a tener karma 12 )

Zootropo

#6 Si, lo se, JackDaniels, pero nunca dejan de sorprenderme. Soy así de inocentón.

Lo mismo no saben que los votos negativos injustos se penalizan
http://blog.meneame.net/2007/04/25/penalizacion-de-votos-negativos-a-comentarios/

De todas formas, volviendo al tema, creo que hay que entender que el autor, cuando hablaba del UML y los patrones, se refería a que es malo usarlos en exceso, y no simplemente usarlos. Lo contrario sería tan absurdo que no lo considero.

Es malo crear 20 diagramas para un Hola Mundo, y es malo tener el libro del Gang of Four al lado y pasarse las horas buscando qué patrón podría casar minimamente con el problema, por el simple hecho de tener patrones, que es algo cool.

D

De como autodeclararse mal programador.