Los 7 pecados capitales de los desarrolladores

Se necesita mucha capacitación y práctica para ser un desarrollador destacado. Pero si no se tiene la disciplina adecuada, incluso los mejores programadores corren el riesgo de sacar lo peor de si mismos. Algunos malos hábitos también son tan insidiosos que se reiteran una y otra vez, incluso entre los desarrolladores más experimentados.

Hablo nada menos de los siete pecados capitales del desarrollo de software. Sepa cómo la lujuria, la gula, la avaricia, la pereza, la ira, la envidia y la soberbia pueden mandar al infierno a su proyecto de programación. 
 
Lujuria
Los modernos lenguajes de programación tienden a agregar características conforme maduran. Se acumula capa tras capa de abstracción, con nuevas palabras clave y estructuras diseñadas para ayudar a la legibilidad y reutilización del código – siempre y cuando usted se tome el tiempo de aprender cómo usarlas correctamente. 
Al mismo tiempo, la disciplina de programar ha cambiado con el tiempo. Actualmente usted tiene tomos enormes de patrones de diseño que tiene que estudiar minuciosamente, y muy poco tiempo para que alguien venga con una metodología de desarrollo que jure que lo transformará en un dios entre los programadores. 
Pero lo que se ve bien en papel no siempre funciona en la práctica, y sólo porque usted puede hacer algo no quiere decir que deba hacerlo. Como lo dice el gurú de la programación Joel Spolsky, “Poner a trabajar lo que se está desarrollando es vital; entregarlo es importante. Su producto debe estar en mano de los usuarios”. Los programadores que idolatran a sus herramientas inevitablemente pierden de vista esto, e incluso el más simple de los proyectos termina atascado en el infierno del desarrollo. Resístase a sus impulsos más viles y apéguese a lo que funciona.
 
Gula
Nada es más gratificante que entregar software. Una vez que usted tiene un producto funcional allá afuera, la tentación de comenzar a planificar la siguiente versión es muy fuerte. ¿Qué nuevas características debe tener? ¿Qué no nos dio tiempo de implementar en la primera?
 Es fácil olvidar que el código rara vez deja todo bien a la primera. Así, conforme se acumulan características con rondas sucesivas de desarrollo, los programadores tienden a agravar los problemas del pasado, lo que se deriva en una base de código abotagada y frágil que es demasiado complicado mantener de forma eficiente. 
 En lugar de atragantarse con plato tras plato de nuevas características, conténgase. Evalúe la calidad y cómo mantener su código actual. Haga a la reescritura del código un componente de su presupuesto en cada nueva ronda de desarrollo. Los clientes pueden ver sólo las nuevas características de cada versión, pero en el largo plazo, le agradecerán por hacer a un lado lo innecesario. 
 
Avaricia
Excesivo deseo de riqueza y poder; ¿de qué otra manera podría explicarse los motivos de los programadores de competir con sus colegas? Comienza cuando otros equipos quedan fuera de las listas de correo electrónico, para pasar a juntas a puerta cerrada. De lo siguiente que usted se entera es que un equipo ha escrito una librería que reimplementa más de la mitad de la funcionalidad que ya había codificado otro equipo.
 
Pocas veces los equipos de programación reinventan la rueda de la malicia, pero al carecer de objetivos definidos con claridad, pueden asumir fácilmente responsabilidades mucho más amplias de las que son estrictamente necesarias. El resultado es una base de código redundante y difícil de manejar, para decir que nada del presupuesto se perdió por los esfuerzos duplicados. Una de las principales prioridades de administrar un proyecto de desarrollo debe ser asegurar que una mano sepa lo que está haciendo la otra, y que todos los equipos están trabajando hacia un objetivo común. “A todos por igual” debe ser su lema.
 
Pereza
La lista de errores de programación básica es larga, pero el pecado de no poder validar las aportaciones (input) es tan pernicioso que merece una consideración especial. Es tan desconcertante que este error aparentemente de principiantes siga apareciendo en el código escrito por programadores experimentados. Y muchas vulnerabilidades, como los ataques de inyección de SQL, pueden rastrearse directamente al código que opera en la aportación que hace un usuario sin validarlo para su formateo correcto.
 
Los modernos lenguajes de programación ofrecen muchas herramientas para ayudar a los codificadores a evitar que esto suceda, pero tienen que usarse adecuadamente.

Recuerde, una forma Web que utiliza JavaScript para validar sus aportaciones puede evadirse fácilmente al deshabilitar JavaScript en el navegador o al no usar un navegador para acceder. La validación de las aportaciones debe ser respaldada por el núcleo de su aplicación, no salpicada en la UI. No es nada más que pereza. 
 
Ira
¿Qué acto puede ser más hostil para sus programadores que no poder comentar su código? Lo sé, lo sé: el código bien escrito es por sí mismo su mejor documentación. Bueno, ¿qué cree? Esos métodos que usted escribió a las dos de la mañana el martes pasado no eran exactamente código bien escrito.
 
Para los programadores es fácil olvidar que el código que escribieron hoy pueda vivir mucho después de que hayan dejado el trabajo. En los programadores que los reemplazan cae la nada envidiable tarea de averiguar lo que cada fragmento de código significa realmente. Así que tenga piedad, y deje algunos indicios.
 
Pero recuerde, los comentarios ilegibles o comentar demasiado puede ser tan malo como no comentar nada. Comentarios como “esto no sirve” o “jamás toque esto” no ayudan mucho. Tampoco ayudan los comentarios redundantes que explican operaciones sencillas, como las inicializaciones de variables. El código mismo es su mejor documentación de lo que hace; los comentarios deben estar ahí para explicar por qué. 
 
Envidia
Es difícil creer que aún hay proyectos de software en 2011 que existen como un árbol de directorios en un servidor de archivos, celosamente guardados por un “mantenedor maestro”. Hay duplicados de este árbol esparcidos por la oficina en las estaciones de los desarrolladores, cada uno diferente al otro –aunque nadie sabe exactamente qué tanto.
 
Tal vez usted tiene razones para no implementar un control de versiones de sus proyectos. Tal vez todo comenzó bien pero se salió de sus manos. No obstante los sistemas de control de versiones poderosos y efectivos ya están disponibles actualmente sin costo. Los proveedores de servicio incluso están dispuestos a hospedar código para proyectos distribuidos por un costo mínimo. No hay razón de por qué usted no deba hacer de iniciar un repositorio de código uno de los primeros pasos de cualquier proyecto, incluso de uno pequeño – a menos, digamos, que no pueda soportar ver que alguien más haga cambios al código que no sea usted mismo. 
 
Soberbia
A menudo usted está tentado a darse una palmadita en la espalda por un trabajo de programación bien hecho. Pero ¿cómo sabe que está bien hecho? ¿Cuáles son sus métricas?
A menos que usted haya validado su código con casos de prueba específicos, no tiene idea si funciona como se planea y si está totalmente libre de defectos. Pero una gran cantidad de desarrolladores no logran producir pruebas de unidades para su código. Afirman que el tiempo invertido en probar es tiempo que no se invierte en implementar funcionalidades. 
¿Qué puedo decir, excepto que la soberbia precede a la caída? Para cuando el código defectuoso llegue a las manos de los clientes, será demasiado tarde para corregir el error. Cuanto más planee la prueba de unidades antes de distribuir el código, más control de daños puede evitarse después.