Despues de algun tiempo en este complicado pero apasionante mundo tenencuentras todo tipo de cosas, desde obras de arte, hasta cosas tan descabelladas que realmente te preguntas que clase de bastardo escrinio dicho codigo...
Sin duda nos hemos encontrado algun dia con algo asi, asi que si sos programador te identificaras con algunas de los siguientes casos... Y si tenes uno propio agregalo...
# Comentarios que explican el “como” y no el “qué”.
Lo que me han metido hasta la saciedad este año en la cabeza es la costumbre de documentar correctamente los apartados o métodos adecuadamente explicando todo lo que en un futuro no podamos entender y procurando hacérselo comprender a otras personas. Hay programadores que más que creen que los comentarios se utilizan para poner el pseudocódigo, vamos prácticamente repiten la información que te da el propio código. El siguiente ejemplo es revelador:
r = n / 2; //Igualamos r a n dividido por 2
//Se repite mientras r – (n/r) sea mayor que t
while ( abs( r – (n/r) ) > t ) {
r = 0.5 * ( r + (n/r) ); //Igualamos r a la mitad de r + (n/r)
}
Las interrupciones.
Todos los desarrolladores sabemos cuando estás totalmente enfrascado en el código un momento de distracción puede eliminar todos los pensamientos que tenías en tu cabeza, con el consecuente problema de tener que volver a “conectarte” después de una interrupción. Las causas suelen ser llamadas, mensajes o Messenger en su defecto, jefes o compañeros con su aliento en tu nuca preguntándote por la resolución de un método o metiéndote caña con los plazos de entrega (menos si trabajas en Microsoft, parece ser) y otras de la misma índole.
Ampliación del ámbito.
Que casualmente se suele dar durante el desarrollo de la aplicación. Esto significa que en un principio te asignan un problema sencillo de unas “pocas líneas” y a medida que pasa el tiempo y la fecha de entrega se acerca aumenta considerablemente la dificultad del problema porque resulta que ahora los analizadores y el cliente deciden que sería mejor si… Como ejemplo nada mejor que el del post original:
Versión 1: Mostrar un mapa de geolocalización
Fácil, cojo un mapa de por ahí y unas pocas líneas de código y a otra cosa mariposa
Versión 2: Mostrar un mapa 3D de localización
Madre del verbo bendito, qué bien se lo pasan tocando las narices a uno, ahora hay que currarse más el
diseño y con suerte encontrarlo, cogerlo y adaptarlo de código ya existente
Versión 3: Mostrar un mapa 3D de localización, por el que el usuario pueda desplazarse volando
WTF!
Gestores que no entienden de programación.
Qué bien, el desarrollador el último otra vez, la incapacidad de los gestores muchas veces supone un problema terrible para el desarrollador, como no.
Documentación.
Además del código el programador debe crear documentación que suele incluir documentación para el usuario final y documentación delpropio programa en algunos casos.
# Aplicaciones, métodos o clases sin documentación.
Es bastante frustrante tener que implementar una API que tenga una documentación prácticamente nula dejándonos el método de “A ver qué pasa si ejecuto este método” como única solución.
Hardware.
Los errores de hardware son realmente complicados de detectar y conllevan el cabreo del usuario final, pensando éste que el principal problema está en que la aplicación está mal desarrollada.
Imprecisiones.
Irritante como lo que más es la imprecisión tanto en el nivel de usuario como en el de desarrollo y diseño, cosas que se deberían pulir realmente y que suelen venir desde fases anteriores que suelen ser más abstractas.
Otros programadores.
Choques de personalidad, problemas de comprensión, falta de habilidad en la comunicación, falta de iniciativa, apatía hacia el código o el proyecto…
Tu propio código 6 meses después.
Cuando seis meses después intentas reciclar tu propio código es cuando te preguntas si realmente eres tan malo documentando como los demás.
Al fin y al cabo todos somos parecidos y todos cometemos errores. Saludos desde Costa Rica y visiten mis otros post.