Code Retreat Debriefing

[Rogelio Zarate]

Una vez pasada la emoción del evento:

¿Con qué se quedan?

¿Qué aprendieron?

[Alan Maciel]

Entre otras cosas esto es lo que me llevo yo.

Siempre el enfoque a hacer las cosas bien

1. Prueba luego codigo
   
2. Clases y variables deben tener nombres descriptivos
   
3. DRY
   
4. Codigo compacto (menos de 7 lineas)
   

Bonus 

5. Siempre usa Ruby

[Sinue Garcia]

mmm pues yo con pair programming , me gusta el nivel de concentración que puedes llegar a tener cuando 2 personas trabajan sobre lo mismo , sobre todo porque evitas distracciones como twitter fb etc, cuando alguien mas esta ahí contigo así que creo que si aumenta la productividad por ese lado.

y pues animos de implementar CI en todos mis proyectos ..

Saludos

-- 

Sinue Garcia

Sent with Sparrow

[Carlos Alejandro Pedroza Rivera]

Pues vaya que si dejo bastantes cosas para mi:
la experiencia del pair programming
la facilidad de programacion que te da ruby
el cambiar tu forma de pensar para el trabajo al aplicar TDD y BDD
...
y mi camiseta de Bajio on Rails y muchos stickers!!!!

El lunes, 16 de julio de 2012 12:48:18 UTC-5, cobi_it escribió:

[Carlos Moisés Castro Jiménez]

• Nunca había hecho Pair programming se cumple la regla dos cabezas piensan mejor que una. Herramientas para trabajar PP como Tmux.
• Diseño correcto de aplicaciones/ TDD y BDD. Una de las cosas que me llamo la atención es que la gente de Crowd en sus proyectos no tienen el miedo de incluir en la estimación del proyecto las pruebas. Muchas veces no se incluye en lo costo de proyecto por no salirse del costo del mercado y perder el jale.
• Herramientas de integración continua. /Pruebas
• Pensar simple /ruby ayuda mucho a esto / 
• DRY

[cobi_it]

Yo me quedo con:

-  Pair programming, estar dos compartiendo el teclado ayuda a la concentración y si aceptas ideas nuevas y propones, puedes seguir avanzando el problema.

   Tambien tener a dos programadores escribiendo la misma linea de código es caro, ¿O no?

-  Shift de Master/Padawan (Perdón por lo nerd): Nos tocaron compañeros mas experimentados y valia la pena proponer y aprender. También nos tocaron compañeros menos   

   experimentados, tambien valió mucho la pena escuchar y aprender guiando.

-  Darme cuenta que si te encierras en un solo stack (Lenguaje, editor, ambiente, etc.) esto condiciona tu manera de resolver el problema. Las herramienta se convierten en 

   restricciones. Personalmente creo que Ruby es mejor lenguaje para estos ejercicios, pero lo mismo daba .Net o Haskell o Smalltalk.

-  TDD/BDD, me sigue causando ruido. Cuando es TDD y cuando BDD?

   Enterarme por Edwin que el ratio linea de código/lineas de prueba es de 1/1.8 me hace pensar en el costo de esto, y como dice Carlos, considerando el mercado ratonero, 

   multiplicar el costo por 3 espantara a la  mayoría. 

   Es hora de cambiar de clientes.

   Aún no tengo certeza que escribir las pruebas produzca un mejor código, o mas rapido. Me queda claro que si mejor mantenible.

-  Pruebas de solo código, eso me gusto, sin suite o gemas especiales.

-  Primera vez que escucho lo de los bloques en ruby de menos de 8? lineas.

Saludos,

  

On Monday, July 16, 2012 12:48:18 PM UTC-5, cobi_it wrote:

[ismael...@gmail.com]

Saludos y de hecho que bueno que lo mencionas en si yo no vi que se hiciera BDD se menciono que es lo que hacen en Crowd, y es algo distinto a TDD

TDD.- Es basicamente es: escribir una prueba sobre un requerimiento - verificar que esta falla - escribir lo basico para hacerla pasar -  si hay muchas pruebas ver si todo bien o alguna fallo - escribir una refactorización del código - y de hay en ciclo por llamarlo de alguna forma.

BDD.- esta relacionado al llamado User Storie, que basicamente es el comportamiento de lo que una aplicación debe realizar, ejemplo:

Dado que un usuario ingresa al formulario de mi super sitio.

y llena todos los datos.

Cuando le da aceptar

Entonces debe recibir un mensaje de felicidades

y se le debe enviar un email de bienvenida

Basado en esto se programa lo necesario, yo diria que es tener el panorama completo.

Y si claro las metodologias creo que es algo que debe de quedar como punto de referencia en este Code Retreat y de hay bueno tratar de mejorar lo que hacemos.

Otro punto importante para mi es el hecho de entender como estamos como programadores y bueno tratar de tomar este punto para de hay mejorar.

Ahora bien eso de menos de 8 Lineas a mi gusto va más en la refactorización que no va en una primera instancia y es una regla para mejorar la forma que escribimos código y viene tambien el principio de hacer todo más modular.

Bueno les mando un saludo a todos y gracias por participar y creo que no debe de quedar hay para mi lo más importante es reforzar la comunidad y tratar tanto mejorar como individuos como sociedad de Desarrollo que somos.

--