Angel "Java" Lopez

NET, Java, PHP y Desarrollo de Software

This Blog

Syndication

Search

Tags

Community

Email Notifications

Archives

.NET

ASP.NET

Windows Form

VB.NET

C#

Sitios

Blogs

Más allá de hablar de buenas prácticas

Esta semana pasada, Hari Hariri (@hhariri) escribió un interesante post:

Loved the show but I have toget back to the real world now

Hariri comenta sobre su experiencia en dos conferencias, en dos charlas que dio, para desarrolladores. Escribió:

As usual, to set the context, I asked a series of questions regarding unit tests:

“How many of you know what a Unit Test is” – 80% put up their hand.

“How many of you do Unit Testing?” – 10% put up their hand.

“How many of you think Unit Testing is valuable?” – 80% put up their hand

La primera charla fue enfrente de desarrolladores PHP. Pienso que los desarrolladores PHP todavía trabajan un poco diferente de los demás desarrolladores, pero esto en base a mis recuerdos de programación PHP intensiva. Puede ser que hoy tengan más herramientas a su alcance para su trabajo. Pero la segunda chara de Hari fue en frente de 200 personas interesados en arquitectura de software.

Recientemente, en una charla interna en una compañía de software, @MartinSalias hizo preguntas parecidas, y el resultado fue similar al de Hariri. No tomé notas, pero en una de mis charlas los resultados tenían el mismo bias: a una gran mayoría les gusta y algo conocen de mejores prácticas, disciplinas XP, etc… Pero pocos las implementan.

Entonces, ¿dónde está el problema? Hariri escribe:

“A is good. I like A. I should do A. But I won’t do A”.

People identify themselves with the issues we talk about. They see the value writing automated tests and complying with design principles adds. They get excited, yet they don’t do it. Why?

I usually ask this question too, and the typical responses are:

1. Tight Schedules.

2. Decrease in Productivity. Drag and Drop is more productive

3. Customers want deliverables. Tests are not deliverables

and my all time favorite

4. “I’m paid to write code, not tests”.

Bueno, hay muchas razones, cada desarrollador de software y su equipo pueden tener varias razones para no aplicar TDD, pruebas automáticas, revisión de código, programación de a pares, etc…

Tomemos un tópico, para ser más concretos y avanzar en el tema: TDD. ¿Por qué la gente no está usando más TDD en su trabajo diario? Mis razones candidatas:

- Conocen qué es TDD, pero nunca lo practicaron o practicaron poco, y tienen muchas dudas

- Si trabajan en un equipo, no todos los miembros del equipo están al tanto de lo que es TDD, y la persona que conoce algo no tiene la experiencia como para transmitirla a los demás.

(claro, también puede ser por la impresión de que lleva más tiempo (posición discutible) y que el “management” lo ve como un trabajo adicional sin valor)

¿Qué necesitan? Pienso que necesitan estos puntos:

- Conocer el “rationale”, el fundamento que sustenta a TDD (en general, se aprende en charlas, conferencias, libros…)

- Practicar TDD

- Tener un mentor para preguntar dudas, resolver problemas, revisar patrones

Cuando tuve que realmente comenzar a aprehender (más que aprender) TDD, el segundo punto lo resolví aplicándolo en mis proyectos personales. Y el tercer punto, lo encaré preguntando a otros programadores, usando foros web (poco), leyendo ejemplos, más libros, y principalmente, revisando código abierto; todavía sigo trabajando en los tres puntos. Pero veo que no todos los desarrolladores de software tienen el tiempo disponible para mejorar en sus habilidades, más allá del trabajo diario. Yo promuevo el “auto-aprendizaje”, pero la realidad es que no todos los desarrlladores tienen el tiempo (y la voluntad) de tomar ese camino. Y es un camino no exento de riesgos: al auto-aprender, podemos aprender mal algo sin tener una retroalimentación; sin tener un mentor, es dificultoso aprender temas que abarcan tantos puntos y detalles, como TDD.

Estoy trabajando en equipo en el Proyecto Hogwarts para solver esos puntos: darle a la gente el soporte para aprender TDD, IoC, principios SOLID, y más. No sólo con ejemplos, sino también con fundamentos. No sólo teoría, sino también práctica. No solo práctica, sino evaluación, soporte posterior, detección de puntos débiles, acciones correctivas. En el caso de este proyecto, el cliente final ya compró la idea de las mejores práctica: no tenemos que convencer a un “management” escéptico. Estamos todavía en una etapa temprana del proyecto: los primeros entregables estén en beta, distribuidos internamente. Siguiendo lo ágil, producimos algo y lo entregamos, para conseguir revisión, en vez de esperar a tener todo armado. Espero que cuando el proyecto gane más momento, más material y también la experiencia ganada en el proceso, será publicada y compartida con la comunidad.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Published Sun, Apr 4 2010 10:43 by lopez

Comments

# re: Más allá de hablar de buenas prácticas@ Monday, April 05, 2010 12:35 AM

yo no lo encuentro sorprendente, este "problema" es nuestra naturaleza humana, saber lo que es bueno para nosotros y simplemente no hacerlo por la razon que sea (hacer ejercicio, no fumar, comer saludable, etc, etc, etc)

asi de sencillo

salu2

Eber Irigoyen

# re: Más allá de hablar de buenas prácticas@ Monday, April 05, 2010 8:18 AM

Maestro, el anglish lo está matando...

"Estoy trabajando en equipo en el Proyecto Hogwarts para solver esos puntos"

¿Se refiere a solubilizarlos?  :D

Me encantó el post. *Ese* es el espíritu de Hogwarts, exactamente.

Martin Salias

# ALT.NET Hispano VAN sobre TDD@ Friday, April 16, 2010 4:39 AM

De nuevo, este sábado tendremos des-conferencia virtual, organizada por la gente de la comunidad ALT

Angel "Java" Lopez

Leave a Comment

(required) 
(required) 
(optional)
(required) 
If you can't read this number refresh your screen
Enter the numbers above: