skip to main |
skip to sidebar
Este post fue escrito por Kevin William Pang en Agosto del 2008, al ver su contenido me identifique en cada una de sus palabras y me vi obligado a pedirle su autorización para compartir este top 10 en español. La versión en ingles esta aquí
10. Comentarios que explican el "como" y no el "porque"Los niveles introductorios de programación siempre recomiendan a los estudiantes que deben poner comentarios a su código constantemente. La idea es la de tener tantos comentarios como se puedan en vez de no tener ninguno. Desafortunadamente algunos programadores se toman muy a pecho este precepto y comentan cada linea de código, es por eso que muchas veces encontraras este tipo de lineas de código. 
Se entiende que es lo que hace el código? Si bien hay muchas lineas de comentarios describiendo lo que el código hace, no hay ninguna que diga por que lo hace. Consideremos la misma porción de código con un enfoque de comentarios diferente: 
Mucho mejor! De todas formas no tenemos un entendimiento exacto del propósito del codigo pero ya tenemos un punto de partida para entenderlo. Los comentarios se suponen que están para ayudar al lector a entender el código, no la sintaxis. Esta bien asumir que el lector tiene un entendimiento básico de como funciona un loop, no hay necesidad de escribir un comentario como "iterar la lista de clientes". Con lo que el lector no estará familiarizado es por que tu código funciona de la forma en la que lo escribiste. Muy pocos programadores pueden ir de 0 a codificar en un parpadeo. En general, el programador tiende a ser mas como una locomotora que como un Ferrari; es posible que nos tome un tiempo comenzar a codificar, pero, una vez que empezamos podemos realizar una gran cantidad de trabajo. Lastimosamente es difícil entrar en tal concentración cuando tu tren de pensamientos se ve descarrilado constantemente por clientes, administradores y compañeros. Simplemente hay demasiada información que mantener en mente mientras trabajamos en una tarea como para poder dejarla, atender otro asunto y luego volver en el punto que habíamos dejado sin perder el ritmo. Las interrupciones matan nuestra concentración y retomarla es una tarea que consume tiempo, frustranrte y lo pero de todo es que produce errores.
8. El monstruo del alcance[El Síndrome del lavadero o Arrastramiento del alcance (Scope creep en inglés) en gestión de proyectos se refiere a aquellos cambios no controlados en el alcance de un proyecto. Este fenómeno puede ocurrir cuando el alcance de un proyecto no se define, documenta, o controla correctamente. Típicamente, el aumento del alcance consiste en productos nuevos o nuevas características de productos ya aprobados que hacen que el equipo de proyecto se desvíe de su propósito original. Debido a su tendencia a centrarse en solamente una dimensión de un proyecto, el arrastramiento del alcance puede también dar lugar a que el equipo de proyecto exceda su presupuesto y cronograma originales. Mientras el alcance de un proyecto crece, más tareas se deben terminar con el mismo coste y cronograma que la cantidad original de tareas del proyecto.] El arrastramiento del alcance puede tornar un requerimiento simple en un monstruo complejo y horrible que consume nuestro tiempo. Es solo necesario un par de "teclazos" por parte del ingeniero de requerimientos para que esto suceda: - Versión 1: Mostrar un mapa con la ubicación
- Versión 2: Mostrar un mapa 3D de la ubicación
- Versión 3: Mostrar un mapa 3D de la ubicación por el cual el usuario pueda navegar
Lo que habría sido una tarea de 30 minutos se ha convertido en un sistema complejo que puede llegar a tomar cientos de horas hombre. Aun peor, la mayormente los arrastres de alcance ocurren durante el desarrollo, lo que requiere de re-trabajo, refactoring y muchas veces botar código que ya se había escrito días antes.
7. La administración no entiende de programaciónLa administración/gestión no es un trabajo facil. La gente es dificil; Mantener a un gran grupo de programadores contentos y unidos es una tarea titanica. Sin embargo, eso no quiere decir que la administración deba mantenerse fuera de un entendimiento básico del trabajo que se esta realizando. Cuando la administración no puede entender el desarrollo encarado es muy probable que se arrastren los alcances y fechas limites poco realistas. y, en general, frustración en ambos lados de la mesa. Esta es una queja común entre los programadores. Esta es una queja común entre programadores y también la fuente de muchos miedos 
6. Documentar nuestras aplicacionesSi, existen aplicaciones que generan la documentación del código que escribimos, esa documentación es buena para otros programadores. Si trabajamos con una aplicación que sera utilizada por gente normal va a ser necesario escribir una documentación que una persona promedio pueda entender (por ejemplo, como funciona la aplicación, manual de usuario, etc.). No es difícil ver que esta tarea es una carga muy pesada para los programadores. Fíjense en todos los programas Open Source que hay disponibles, cual es el común denominador en las tareas que mas ayuda solicitan? Documentación. Creo podre hablar en nombre de todos los programadores cuando digo "Puede alguien mas hacerlo?"
5. Aplicaciones sin documentaciónNunca se dijo que no somo hipócritas. Lo programadores están siempre solicitando librerías de 3ros para integrar en su trabajo. Y para poder hacer eso "necesitamos documentación". Des afortunadamente, como mencionamos en el punto 6 programadores odian escribir documentación. No, la ironía no se ha perdido. No hay tarea mas frustrante que tratar de usar una librería de 3ros cuando no tenemos la menor idea de que es lo que hace la mitad de la función que queremos usar. Cual es la diferencia entre funcionPobrementeNombrada() y funcionParecidaPobrementeNombrada()? Necesito verificar nulos antes de usar la PropiedadX? Seguramente sera con prueba y error... Cualquier programador que alguna vez fue llamado para depurar un error extraño en la base de datos o por que el controlador RAID no funciona correctamente sabe que los problemas de hardware son dolorosos. Parece haber una mala concepción que si un programador trabaja con computadoras, seguramente sabemos como arreglarlas. Esta bien, esto puede ser cierto para algunos programadores, pero reconozco que la gran mayoría de nosotros no nos importa una vez que el assembly ya esta compilado. Nos concentramos en las tareas de alto nivel de tal forma que las cosas funcionen como deberían en ese estrato. "El sitio web no funciona". "La funcionalidad X no funciona correctamente". los requerimientos ambiguos son dificiles de concretar. Va a ser siempre una sorpresa para mi como la gente ajena a la programación se exaspera al tratar de explicar como reproducir un problema a un programador. Pareciera que no entienden que "esta roto, no funciona, arregla lo" no es suficiente información para solucionar el problema. El software es (mayormente) determinístico. Y nos gusta de esa manera. Dennos el gusto al hacernos saber que paso del proceso esta mal en lugar de pedirnos que "lo arreglemos". Los programadores no siempre se llevan bien entre ellos. Impactante, pero cierto. Este podría ser fácilmente el #1 así que solo nombrare algunas de las situaciones mas comunes que molestan a sus colegas de programación: - Ser gruñón al punto de ser hostil
- No entender que hay un tiempo para discutir la arquitectura del sistema y tiempo para hacer las cosas.
- Imposibilidad de comunicarse efectivamente y confundir la terminología
- Apatía hacia el código base y el proyecto
Y como broche de oro la molestia mas grande para un programador
1. Código propio después de 6 mesesAlguna vez volteaste a ver algún código viejo tuyo con cara de dolor? pero que estupidez! como pudiste? quémalo... quémalo con fuego...! Buenas noticias, no estas solo. La verdad es, el mundo de la programación es un mundo en constante cambio. Lo que consideramos buenas practicas hoy puede ser obsoleto mañana. Simplemente no es posible escribir un código perfecto por que los estándares que se usan para juzgar el código están en constante evolución. Es difícil aceptar que to código, por muy lindo que sea hoy, probablemente sea ridiculizado en un futuro. Es algo frustrante ya que no importa cuanta investigación hagamos con las ultimas herramientas y tecnología, diseños, frameworks y buenas practicas siempre vamos a ver que falta algo mas. Para mi, esta es la cosa mas molesta para un programador. La fragilidad de lo que hacemos es necesaria para impulsar a las mejoras, pero no puedo dejar de sentirme como uno de esos monjes que pintan con arena. Bien, ahí están. Top 10 de cosas que molestan a los programadores. Si ves que falta alguno por favor envía tus comentarios.
_513.png){kind=small}