archivo

Archivos diarios: mayo 10, 2012

El enfoque de planifico todo el proyecto, realizo todo el análisis y después diseño, construyo e implanto está todavía presente en una gran cantidad de personas de nuestra industria.

Muchos desarrolladores recién llegados ven el proceso de desarrollo con ese enfoque, sin embargo el problema no son ellos, tienen todavía mucho tiempo para cambiar, sino personas que se dedican a esto desde hace mucho tiempo y que, como suele pasar en las organizaciones, con el paso de los años han alcanzado responsabilidades directivas.

Quien se ha criado en metodologías clásicas, quien ha trabajado durante muchos años con ellas le resulta muy complicado cambiar sobre todo si se está alejado ya del día a día de los proyectos de desarrollo de software. Con el paso del tiempo todo se idealiza, algo que además si no tiene mucho espíritu crítico te puede llevar a pensar que realmente no fueron tan mal todos esos proyectos en los que trabajaste y que utilizaron enfoques clásicos.

Por otro lado, en el área usuaria o funcional, el enfoque de los proyectos en los que trabajan que serán en su mayoría no software también será, por regla general, de tipo totalista, es decir, contrato un trabajo, lo ejecutas de una vez y adiós.

La aplicación de enfoques ágiles se encuentra con esta resistencia, personas que no terminan de entender por qué aplicas esa estrategia, personas que se sienten más cómodas trabajando sobre una planificación general, independientemente de que la misma nunca se cumpla o que el producto final se parezca bien poco a las expectativas que se tenían sobre el mismo.

Para que proyectos con este enfoque puedan llevarse a cabo es fundamental que todas las partes implicadas en él entiendan, comprendan y compartan que esta forma de entender el desarrollo de software es la que mejor se adapta a su incertidumbre inherente y por tanto, es la que de forma más probable te llevará al cumplimiento de los objetivos.

En general, apliques la metodología que apliques es fundamental que todas las partes remen en la misma dirección, de lo contrario a las resistencias que te vas a encontrar en el propio proceso de desarrollo tendrás que sumarle que estaréis solos tu equipo y tú para poder vencerlas y que las otras partes, por regla general, lo que harán será sumar más resistencia.

Kent Beck, describe todo esto de la siguiente manera: “El software es inherentemente poco fiable y los clientes están condicionados a aceptarlo. Los desarrolladores están condicionados a aceptarlo. Los testers están condicionados a aceptarlo”.

Si el código es complicado de entender es mejor invertir esfuerzo en hacerlo inteligible (refactorizar) que en hacer comentarios que generalmente ayudarán poco al que lo lee y que después tocará probablemente mantener cuando se toque esa sección del código.

No se trata de prohibir los comentarios sino de elegir muy bien dónde se ponen y por qué se ponen.

¿Cuántas veces nos encontramos con comentarios que describen en lenguaje natural lo que hace el código?, ¿es eso útil?, ¿no sería más útil explicar por qué se ha elegido esa solución que describirla paso a paso?, ¿es necesario explicar siempre por qué?.

Si no se sigue una política adecuada en los comentarios es más probable que perjudiquen mucho más que sirvan de ayuda, no solo ya porque afecten a la legibilidad del código, no solo porque sea necesario mantenerlos sino porque además pueden dar pistas falsas al desarrollador en el caso precisamente de que no se hayan mantenido y ya no sean congruentes con el código o bien en el caso de que su contenido no sea correcto.