mariochavez

mariochavez

Publicado
Junio 14, 2013

Próximos Eventos

Blog

MagmaConf 2013: Keynote día 3: Bryan Liles

How versus why…

image alt

Bryan en su keynote menciona que los desarrolladores no nos enfocamos tanto en el porqué, nuestro enfoque siempre está en el como. No nos damos cuenta que lo importante es el porqué, por ejemplo: el porqué usas un editor en particular, porqué no haces pruebas o porque haces pruebas; usamos y tomamos muchas decisiones en el como, pero es raro que lo hagamos en el porqué.

La gente que escribe pruebas, entiende que el código de producción existe para que pase las pruebas, aunque pensemos que no nos pagan por escribir pruebas, pero si realmente ese es el motivo del porqué escribimos las pruebas primero.

Escribimos pruebas, porque probablemente no vamos a ser la última persona que vea nuestro código o quizás nosotros mismo tengamos que regresar a nuestro código en 6 meses; escribimos pruebas porque nos interesamos por nosotros, por nuestros nuestros compañeros de trabajo, por nuestros clientes y porque queremos que las cosas funcionen.

En Ruby todos conocemos el concepto de convención sobre configuración, la cual nos invita a poner los archivos de cierta forma y simplemente funciona, ese es el como. La pregunta es porqué esto funciona tan bien en el mundo de Ruby y no tanto en otros ambientes. El porqué se debe a que si conocemos la estructura de un proyecto de Rails, cualquier persona puede llegar más tarde y entender como funciona y se organiza nuestro proyecto.

Los desarrolladores de Rails sabemos el como hacer que el ruteador de Rails funcione, pero el porqué existe, se debe a que como desarrolladores nos llevaría mucho tiempo a nosotros el hablar directamente con el protocolo de http, el ruteador de Rails nos proporciona una buena abstracción que nos permite olvidarnos un poco de los detalles de http.

El patrón de la arquitectura orientada a servicios (SOA) hoy en día es un patrón bien conocido en donde casi todos los desarrolladores entienden el como realizar una implementación, pero una vez más el porqué es lo importante, y en este caso proviene de que entendemos que no todos vamos a trabajar con el mismo código fuente; además de que abstraemos y segregamos funcionalidad en sistemas complejos.

En la misma línea de ejemplos del como contra el porqué, Bryan comenta que muchos desarrolladores usan Macs, en este caso el porqué tiene que ver en que obtenemos el poder de Linux sin la estupidez de Windows.

Todos los que estamos aquí somos desarrolladores web - menciona Bryan - y todos sabemos como trabajar con el protocolo HTTP y como funciona, pero lo que no todos sabemos es el porqué, el estándar RFC 2616 documenta el porqué.

Un tema reciente es el como atraer más mujeres en el desarrollo de software, pero la pregunta correcta aquí es ¿porqué no hay mas mujeres en área de desarrollo?, quizás a ellas no les guste trabajar en ésta área, o no les guste ir a las conferencias/reuniones.

Entonces como hemos visto entre el como y el porqué, el más importante para nosotros en el desarrollo de software debería ser el porqué.

¿Quieres ser un mejor desarrollador? - que no es lo mismo a ser un buen programador - entonces tienes que programar como Indiana Jones, te tiene que gustar buscar y encontrar cosas nuevas, enfrentar retos en los que parece que no podrás salir victorioso.

No hay algo como código malo, pero si hay proyectos que pueden ir mal, en estos casos lo importante es encontrar el porqué el proyecto esta mal. No existe código malo, es solo código que alguien escribió y nunca entendió el porqué.

El saber el como no es más importante que saber el porqué. El entender el porqué te ayuda a construir confianza en lo haces, confianza en tus compañeros de trabajo, confianza en el código que produces y confianza en tu trabajo de parte de tus clientes.

Este es un buen momento para ser desarrollador de Rails, es un buen momento para ser un desarrollador web; entender el como es bueno, pero es mucho mejor entender el porqué.