miércoles, 2 de noviembre de 2011

[13 de 97] Hacer commit y correr, es un crimen.


Post publicado originalmente entre Mayo del 2009 y Enero del 2011 en mi anterior blog.
Pertenece a una serie sobre arquitectura de software, replicaré los comentarios ya que, a mi parecer, son lo más importante de la serie.

Puedes encontrar el listado de esta primera entrega en este enlace.

El axioma de hoy (tomado del libro 97 things Every Software Architech Should Know) dice:
"Hacer commit y correr, es un crimen."
Niclas Nilsson.

Niclas es cofundador de la empresa factor10 y es editor en la comunidad de arquitectura en el sitio InfoQ.
Su blog es: http://niclasnilsson.se

[NT. El título original del axioma es: Commit-and-run is a crime.]
Aquí parte importante del axioma:

Crime Scene Do N...

---

It's late in the afternoon. The team is churning out the last pieces of the new feature set for the iteration, and you can almost feel the rhythm in the room. John is in a bit of a hurry though. He's late for a date, but he manages to finish up his code, compile, check-in and off he goes. A few minutes later, the red light turns on. The build is broken. John didn't have time to run the automated tests, so he made a commit-and-run and thereby left everybody else hanging. The situation is now changed and the rhythm is lost. Everybody now knows that if they do an update against the version control system, they will get the broken code onto their local machine as well, and since the team has a lot to integrate this afternoon to prepare for the upcoming demo, this is quite a disruption. John effectively put the team flow to a halt because now no integration can be done before someone takes the time to revert his changes.

This scenario is way too common. Commit-and-run is a crime because it kills flow. It's one of the most common ways for a developer to try to save time for himself, that ends up wasting other peoples time and it is downright disrespectful. Still, it happens everywhere. Why? Usually because it takes too long time to build the system properly or to run the tests.

This is where you, the architect, come into play. If you've put a lot of effort into creating a flexible architecture where people can perform, taught the developers agile practices like test-driven development and set up a continuous integration server, then you also want to nurture a culture where it's not alright to waste anybody else's time and flow in any way. [ ...... ]

Invest time in making the system fast to work with. It increases flow, lessens the reasons for working in silos and in the end makes it possible to develop faster. Mock things, create simulators, lessen dependencies, divide the system in smaller modules or do whatever you have to. Just make sure there's no reason to even think about doing a commit-and-run.

---

Sí, ¡¡¡ es un crimen !!! y quizá no en el sentido legal de la definición, pero sí en un sentido moral.

Me desviaré un poco del tema principal del axioma para comentar (y quizá externar algunas ideas a manera de terapia) algunas reflexiones que surgieron durante una plática con Javier Castañon durante la 8a reunión de las comunidades SpringHispano, JavaMéxico y Grails-MX.

La plática en general trataba sobre administración de proyectos y,  durante la charla, Javier mencionó tres puntos que considera primordiales para que se pueda gestionar adecuadamente un equipo de trabajo:
  •  Comunicación
  •  Transparencia
  •  Rendición de cuentas.
Seguramente lo que se comentó durante esa charla servirá para más reflexiones, pero, en esta ocasión, retomo solo ese comentario.

De los tres puntos mencionados, considero el primero el más importante; el tema de la transparencia me parece también importante, pero, quizá por razones de supervivencia, creo que a veces y sólo a veces es necesario quedarse con algo para uno mismo (Sun Tzu tiene la culpa de que piense así ) y sobre la rendición de cuentas no tengo mucho que decir... para nadie es secreto que considero altamente probable la existencia del  karma   ;)

La transparencia puede verse en este ejemplo justo en el momento que el build se rompe y le llega a Jhon y al líder del proyecto un e-mail indicando que su commit ha roto el build. La rendición de cuentas llegará el día en que se haga pública la lista de "quienes han roto mas veces el build"; pero, parece que el ejemplo del axioma podría bien servirnos como  ejemplo de qué es lo que ocurre cuando la comunicación falla (Jhon pudo haber avisado que tenia un compromiso y, haber hecho el commit y las pruebas con tiempo).

        Independientemente de las reflexiones que salgan del axioma, creo que situaciones como las que se comenta arriba ni siquiera alcanzan la primera agravante de ley (premeditación), y mucho menos llegan a las otras dos (alevosía y ventaja), cuando cada elemento del equipo tiene la conciencia, responsabilidad y compromiso; primero, con su trabajo y, si quiere, después con el equipo.


        A propósito de temas relacionados con  la administración de proyectos, hay un post (con todo y fe de errata) de José Manuel Beas llamado:  Liderar mediante el ejemplo. De lectura recomendable.

Ahora sí, retomando el axioma... Nilsson deja muy claro el porqué debemos considerarlo un crimen: "rompe el flujo de trabajo de todo un equipo" y miren que mis lapsus pesimista me hace pensar que ese efecto puede ser el menos complicado, quizá no sólo se altera el ritmo de trabajo, sino que  incluso pone en riesgo una fecha de entrega (sí, ya le metí drama al asunto XD ).

Nilsson  menciona que, probablemente el tiempo o la "ruta/mecanismo de ejecución" de esas pruebas hacen que el "sospechoso-en-potencia" decida, con el objetivo de ganarse unos minutos, omitirlas.

¿Qué hacemos entonces para evitar caer en estos escenarios que (perdón por la insistencia y el drama pero, como decimos en México: cada quien platica, según como le fue en la feria.) pueden tener efectos serios en todo el equipo del proyecto?

Nilsson lo tienen claro; tener una "cultura de pruebas" puede ser el inicio de la solución; a mi parecer: ya no pensemos siquiera en  automatizadas, el sólo hecho de comenzar a crear la conciencia de que debemos probar adecuadamente nuestro código antes de hacer commit puede ser un excelente inicio.

En estos momentos, con las facilidades que nos dan algunas herramientas de integración creo que tenemos solucionado parte del problema.

Resumiendo:

El problema.
1. Hacer commit (sin hacer las debidas pruebas) es un crimen ya que mata el flujo(de trabajo de todo el equipo).... y en casos un tanto desafortunados puede generar efectos secundarios más complejos.

Parte de la solución:
2. Crear una cultura de pruebas y un  ambiente de desarrollo/construcción/despliegue (recomiendo este interesante post de Julio Cesár Pérez Arques sobre un ecosistema de software)  que permita que el desarrollo y proceso de build sea ágil y seguro.

El objetivo:
3. Asegurarnos que; del lado del proceso de desarrollo/construcción/despliegue del producto no exista nada que permita o incentive ese apócrifo pensamiento: "Haz commit y salte corriendo".

¿Se nos ha pasado algo?

Bueno, dejemos.... una vez más que Dilbert nos haga iniciar bien la semana.

evil1

Saludos a todos!!!

RuGI
Isaac Ruiz Guerra.


Comentarios:

¡Esta estuvo en verdad buena...! ¡Tirar la piedra y esconder la mano...! Clásico: si sale bien, todos se cuelgan, la idea fue mía, etc. De salir mal, pues él y sólo él tuvo la culpa... porque ya no podemos tan fácilmente "echar la bolita", pues se sabe quién envió el error. A veces lo obvio es lo menos evidente... y porque "jale" en mi Firefox no significa que va a funcionar en todos los demás, por poner un ejemplo. La responsabilidad va más allá de lo que dicen los de soporte de M$: "el problema es suyo, porque aquí sí funciona". Muy buen post. Por recordar que también se debe tener en cuenta lo básico.

Enviado por Miguel Zúñiga González (miguel~1.mx) en agosto 23, 2009 a las 09:59 PM CDT #
---
Para los que no tengan el libro, les recomiendo este link:

http://97-things.near-time.net/wiki/97-things-every-software-architect-should-know-the-book

Enviado por Yamil Bendek en agosto 24, 2009 a las 12:04 PM CDT #
---
Creo que esta máxima (y alguna otra que aparezca) se puede resumir en una de las indicaciones del programador pragmático: se responsable de tu código.
Parece sencillo, pero he descubierto que en la práctica es lo más dificil de hacer entender a los programadores. Si realmente te sientes responsable de tu código:

Nunca jamás das excusas, propones soluciones. Una excusa NO SIRVE PARA NADA en un proyecto de desarrollo, todos los humanos nos equivocamos, y debemos estar preparados para subsanar nuestras equivocaciones. De la misma forma que yo no voy a colgar a nadie de los meñiques por un "hit-and-run" de estos, que el programador esté media hora dándome excusas, en lugar de arreglando el estropicio, NO ME SIRVE DE NADA.

A primera vista suena fuerte ("no me des excusas"), pero no se trata de que seamos perfectos, sino que las excusas te las guardas para tu novia el día que llegas a las 8 de la mañana un poco perjudicado. Una excusa no compila.

Procuras sentirte orgulloso de tu codigo. En el fichero va tu nombre (el código no debe ser anónimo) o por lo menos en el commit; asi que nada de que "ya se que es horrible pero funciona". Si es horrible pero funciona, por lo menos pon un TODO o un XXX, y arréglalo en cuanto tengas media hora.

Como sabes que no eres perfecto, te impones unos cuantos mecanismos de seguridad. De la misma forma que no subiríamos a un tejado sin casco ni arnés, por muy buen equilibrio que tengamos, la creación de tests, assertions y/o comprobación de precondiciones deben de surgir del propio programador. Y basta ya de "NO TENGO TIEMPO PARA HACER TESTS" (¿Y tiempo para debuggear tus cagadas ya tienes, no?)
Una de las cosas de las que más sorprendido estoy es de la increíble RESISTENCIA de la gente a hacer bien su trabajo. A todo el mundo se le llena la boca diciendo que no tiene tiempo para hacer tests, que su forma de trabajo en la empresa X es infernal...etc.

Pues bien, he comprobado que cuando quieres hacer bien las cosas, y tienes tiempo para hacerlas bien, la gente se resiste a hacerlas bien. Sólo se consigue a base de tozudez e insistencia.
(Este año me ha pasado una cosa increíble: la gente me discute algo diciendo que tengo la razón :-D. "Ya se que tienes la razón con lo de testear, pero... " ¿como que "pero"?)
Salu2

PD: En cuanto me lo permitan, quiero poner un "extreme feedback device", estoy entre un tux o el conejito ese que hay por ahí. No hay nada como que un pingüino o un conejito te saque los colores ;-)

Enviado por ibon en agosto 28, 2009 a las 07:34 AM CDT #
---
jeje, la verdad yo tenía pensado poner un duke algo molesto o en último caso, aumentar el número de remitentes en el e-mail de aviso :P

Un saludo!!!!


Enviado por RuGI en septiembre 06, 2009 a las 02:59 PM CDT #

----------------------------------------
Créditos:
La imagen es de: aivilophotography
http://www.flickr.com/photos/aivilophotography/4235147323/
Dilbert es una marca registrada de Scott Adams.
----------------------------------------

No hay comentarios:

Publicar un comentario