10. Los comentarios explican el "qué", no el "porqué"

Los cursos de programación para principiantes enseñan a los estudiantes a comentar el código con frecuencia y desde el principio. Es innegable que en la etapa inicial del aprendizaje de la programación este método es bastante efectivo (incluso las líneas de código más simples parecen escritas en un idioma incomprensible). Sin embargo, muchos programadores, incluso después de haber pasado de ser unos novatos a convertirse en expertos en informática, continúan manteniendo este hábito.

r = n / 2; // 让 r 等于 n 除以 2  
 
// 当 r - (n/r) 大于 t 时进行循环  
while ( abs( r - (n/r) ) > t ) {  
    r = 0.5 * ( r + (n/r) ); // 设置 r 等于 r + (n/r) 的一半  
} 

¿Entiendes lo que significa el código de arriba?

Cuatro palabras: totalmente confundido.

El problema de lo anterior es que, aunque hay muchos comentarios, no explican por qué se escribió este código. A continuación, el mismo código se presenta con otro tipo de comentarios, y el efecto es muy diferente.

// 使用牛顿-Raphson算法求n的平方根近似值  
 
r = n / 2;  
while ( abs( r - (n/r) ) > t ) {  
    r = 0.5 * ( r + (n/r) );  
} 

¿Mucho mejor, verdad? Aunque todavía no entendemos completamente qué significa este código, al menos hemos simplificado el código y está mucho más despejado.

Escribir comentarios es para ayudar a los lectores a comprender el código. Aquí se asume que todos los que lean el código ya tienen un conocimiento básico de cómo funciona un bucle for. Lo que puede que no tengan claro es cómo logra funcionar tu código o por qué elegiste este camino para implementarlo.

9. Todo tipo de interrupciones

En la mayoría de los casos, la mente de un programador se parece más a un tren que a un Ferrari; necesita arrancar lentamente, es decir, tenemos que entrar en calor para ponernos en marcha. Pero una vez que nos entregamos por completo, podemos escribir de manera eficiente mucho código que merece admiración. Sin embargo, es un estado muy difícil de alcanzar, porque nuestra concentración se ve interrumpida constantemente por clientes y colegas.

8. Ampliación del alcance

Wikipedia define la ampliación del alcance (scope creep) como "cambios incontrolados dentro del alcance de un proyecto". La ampliación del alcance puede hacer que una solicitud relativamente simple se convierta en una tarea extremadamente compleja y que consume mucho tiempo. Utiliza requisitos aparentemente convenientes e inofensivos para expandir el alcance, destruyendo paso a paso el cronograma del proyecto:

• Versión 1: mostrar un mapa de la ubicación actual
• Versión 2: mostrar un mapa tridimensional de la ubicación actual
• Versión 3: mostrar un mapa tridimensional de la ubicación actual, con la precisión suficiente para usarse como navegación de vuelo

7. La gerencia no entiende de programación

Por supuesto, hay excepciones. Este punto solo refleja mi experiencia personal; cualquier parecido con la realidad es pura coincidencia.

Primero, admitamos que gestionar no es una tarea sencilla. Tus subordinados te van a odiar: sus frágiles corazones a veces también se lastiman. Y mantener unido y cohesionado a un gran grupo de personas es una tarea casi tan ardua como mover una montaña. Sin embargo, que la tarea sea difícil no significa que los gerentes puedan permitirse no tener un conocimiento básico de sus subordinados. Cuando la gerencia no logra comprender la filosofía del trabajo, los empleados experimentan ampliación del alcance, incumplimiento de plazos, frustración y desánimo, entre otras cosas. Esta es la causa raíz de muchas de las quejas y ansiedades habituales de los programadores en su trabajo diario.

6. Escribir documentación

Sí, es cierto que existen muchas herramientas de generación de documentación, pero mi experiencia me dice que estas herramientas solo sirven para generar documentación de API, para consulta de otros programadores. Si el software que desarrollas es utilizado por mucha gente en su vida diaria, más te vale escribir documentación que incluso un profano pueda entender (por ejemplo, cómo funciona la aplicación, guías de solución de problemas, etc.).

Bueno, a algunos programadores no les hace ninguna gracia hacer eso. Lo que la gente suele hacer es echar un vistazo rápido a proyectos de código abierto y luego ponerse a buscar documentación constantemente para obtener ayuda.

Puedo jurar que, en cualquier lugar, casi todos los programadores, cuando se les pide escribir documentación, dirán: "¿No puede encargarse otra persona?"

5. Programas sin documentación

Bueno, nunca he dicho que los programadores seamos personas que dicen una cosa y hacen otra. A los programadores se les pide a menudo que utilicen bibliotecas y aplicaciones de terceros en sus proyectos. Eso hace que necesitemos documentación. Pero como dije en el punto anterior, los programadores odian escribir documentación. ¡Vaya contradicción y dilema!

Cuando necesitamos usar una biblioteca de terceros y no sabemos para qué sirve al menos la mitad de la API, no hay nada más desesperante que eso. ¿Sabes cuál es la diferencia entre las funciones poorlyNamedFunctionA() y poorlyButSimilarlyNamedFunctionB()? ¿Necesito hacer una prueba de null antes de acceder a PropertyX? Si falta documentación, calculo que tendré que averiguarlo mediante mis propias pruebas y mensajes de error. ¡Oh, Dios mío!

4. El hardware (y que siempre te tomen por el reparador de computadoras)

Cualquier programador al que llamen para depurar un extraño problema de caída en un servidor de base de datos, o para resolver que una unidad RAID no funcione correctamente, y que al final resulte que la causa es el hardware, sufrirá muchísimo, orz. Por cierto, no sé de dónde surge el malentendido de que la gente cree que los programadores, por estar todo el día manos a la obra con computadoras, seguramente saben repararlas. Bueno, algunos programadores sí saben (¿quizás fue una habilidad que practicaron en la universidad para conquistar chicas?). Pero puedo apostar lo que sea a que la mayoría no sabe, o no le importa en lo más mínimo cómo funciona el programa una vez que se compila a código máquina.

¿Qué nos importa? Nos importa que lo que hacemos cumpla con los requisitos, para poder concentrarnos en resolver tareas de nivel superior.

3. Ambigüedad

"Ay, mi sitio web está fallando", "la función tal no funciona bien". Este tipo de peticiones sin un objetivo claro son las más dolorosas. Me sorprende especialmente que, cuando pedimos a los no programadores que reproduzcan el problema, se enfaden muchísimo. ¿Acaso no saben que con un simple "la computadora se estropeó, arréglala rápido" no podemos ponernos a trabajar? Necesitamos más información.

El funcionamiento del software, en la mayoría de los casos, sigue un rastro. Y nos gusta esa forma. Por favor, complácenos: ayúdanos a identificar en qué paso se produce el problema, en lugar de limitarte a decir "arréglalo".

2. Llevarse bien con otros programadores

Los programadores a menudo no se llevan bien con otros programadores. No pongan cara de sorpresa; en el fondo ya lo admiten, queridos programadores. Podría enumerar diez ejemplos relacionados con este tema sin pensarlo dos veces, e incluso podría escribir otro blog aparte, así que en este artículo solo enumeraré algunas razones comunes por las que resulta difícil llevarse bien con los colegas:

Mal carácter y actitud poco amistosa.

No saber cuándo discutir la arquitectura del sistema y cuándo ponerse a trabajar.

No lograr comunicarse de manera efectiva, usando jerga técnica que se presta a malentendidos.

No manejar bien los propios asuntos.

Falta de interés en el repositorio de código y en el proyecto.

Y esto no es lo peor. Todavía queda un "asesino de programadores" de peso pesado: el No.1 viene más adelante...

1. Volver a ver tu propio código después de 6 meses

No estornudes, he encontrado un bug.

¿Te ha pasado alguna vez mirar hacia atrás al código que escribiste tiempo atrás y no poder evitar golpearte el pecho y patear el suelo? ¿Lamentándote de lo estúpido que fuiste entonces por escribir semejante basura? ¡A borrar, a borrar, a borrarlo todo!

Bueno, puedes alegrarte: esto no solo te pasa a ti.

Nuestro mundo de la programación cambia constantemente. Lo que hoy es la mejor tecnología, mañana puede quedar obsoleto. Nunca podremos escribir un código perfecto, porque el listón de la evaluación no deja de elevarse con el progreso de los tiempos. Por muy perfecto que nos parezca el código que escribamos ahora, es muy probable que en poco tiempo se convierta en objeto de burla.

Esto provoca una frustración inevitable, porque aunque hoy nos esforcemos al máximo por aprender las herramientas de desarrollo, los diseños, los frameworks y las metodologías más novedosos y excelentes, siempre vamos un paso por detrás de las últimas tendencias tecnológicas. Para mí, esto es lo más frustrante de ser programador, sin lugar a dudas, por eso lo he puesto en el No.1. Lo único que podemos hacer es mantenernos actualizando nuestras habilidades, aunque a veces siento que soy como un escultor de arena: construir, derribar y volver a empezar, jeje.