El cuento de los tres desarrolladores…

Eransé que se eran tres desarrolladores. Los tres tenían que sincronizar sus hilos, habían oido hablar de las terribles historias sobre problemas de corrupción de memoria, condiciones de carrera, y demás ‘lobos’ capaces de devorar cualquier aplicación cuando se ponía en producción. Menos más que existían los objetos de sincronización pensaron y se pusieron a trabajar.

El primero de los desarrolladores pregunto a su buscador favorito como sincronizar una porción de código en .Net y rápidamente encontró el siguiente código:

lock (typeof(Object))
{
   . . .

Lo pegó en su programa y luego se fue a tomar unas cervecitas con sus colegas.

El segundo de los desarrolladores escribió el mismo código en su proyecto y se fue a tomar unas cervecitas con sus colegas. Una pena que no les gustase más el framework que la cerveza, como al bueno de Unai. Si no hubiesen sabido que su código no era lo suficientemente sólido…

Pero un día, cuando más tranquilos estaban estos desarrolladores, la aplicación se puso en producción y el ventilador del procesador sopló y sopló y sopló… y un interbloqueo apareció. Menos más que un cazador de bugs, Pablo Alvarez, pasaba por allí y milagrosamente salvo a los desarrolladores de ser devorados por el malvado deadlock

No lejos de allí, el tercero de los desarrolladores, un desarrollador responsable, pensó: ‘Quiero que mi aplicación sea sólida, ¿que puedo hacer?’ y llego a la conclusión de que era una buena idea construir su aplicación ‘con sólidos ladrillos’ y activo el análisis estático de código de Visual Studio. A pesar de haber copiado el mismo código ‘de paja’ que había encontrado en su buscador favorito, el análisis de código detecto el error:

 image

El desarrollador aprendió por que era una pésima idea hacer aplicaciones ‘de paja’ que estableciesen locks sobre objetos con identidad débil, corrigió su código y cuando el ventilador sopló y sopló y sopló y la aplicación aguanto.

Moraleja: Más vale prevenir que curar… Si en el casó del DOT que explicaba el amigo Pablo, hubiesen activado el analizador estático de código (FxCop para los amigos), Pablo no hubiese podido contar su apasionante sesión de depuración, pero la aplicación hubiese funcionado a la primera… Una vez más se cumple la máxima de que el coste de un bug aumenta exponencialmente respecto a cuanto tarda en detectarse. Coste de usar FxCop: cero, coste de que una aplicación en producción se caiga cada cierto tiempo… mejor ni pensarlo. ¡Menos mal que el Debugging and Optimization Team de Plain Concepts sale baratito! 🙂

Si alguien duda de la eficacia del análisis de código, solo puedo decir que es la segunda ocasión en la que publico como esta herramienta puede salvar el culo de un desarrollador

¡Un saludo!

24 comentarios sobre “El cuento de los tres desarrolladores…”

  1. Espectacular tio xDDDDDDD

    Me he reido de lo lindo, y lo mejor es que tienes más razón que un santo; si en muchos de nuestros clientes se usara mas FxCop me aburriria un monton más!

    Lo dicho tio, genial… ¡un 10!

    Un abrazote!

  2. En fin, cuando tienes razón hay que dártela aunque también echo de menos una regla que diga que no hagas un lock de typeof aunque no sea por un tema de Marshall-By-Bleed por la mala práctica en cuanto a orientación a objetos…

    Saludos
    Unai

  3. Muy bueno – y UTIL. No solo este post sino tambien el de Pablo y Unai.
    Un apunte:
    os habeis fijado en que System.Threading.Monitor.Enter recibe como parametro un objeto y no un tipo …

  4. @Devjoker: si te das cuenta al lock también le pasas un objeto… pero de tipo RuntimeType cuando haces el typeof o el GetType, y ese es el problema! pero no deja de ser un objeto 🙂

  5. @Capitan Pir: A la espera de que Rodri te recomiende algo mejor, que para eso es su post XD yo te recomiendo encarecidisimamente el libro de Joe Duffy de Programacion Concurrente. Como diría Luis Guerrero, «canela en rama» 🙂

  6. Si – por supuesto -, me refiero a que la firma del método «invita» a poner una instancia de un objeto y no una llamada a GetType() o typeof.
    Algo sí:
    class LockTest
    {
    private Object locker = new Object();

    internal void DoLock()
    {
    System.Threading.Monitor.Enter(locker);
    Console.WriteLine(«Prueba»);
    System.Threading.Monitor.Exit(locker);
    }

    }
    pd:unos cracks!

  7. Bueno, bueno, un poco de piedad, mirad a que hora publiqué el post hombre… que estaba un poco dormido… 🙂

    Ya he corregido las faltas que he encontrado…

    Lo que más me ha gustado es el que firma ‘ortografia al poder’ sin tilde en ¡ortografía!.

    ¡Un saludo!

  8. Si, nos encanta la cerveza =)

    Siendo sinceros tenemos claro que sin nosotros miles de trabajadores de las fabricas de mahou estarian en el paro, sus familias les repudiarian y sus hijos se verian obligados a adoptar la prostitucion como unico medio de subsistencia

    estamos orgullosos de contribuir con nuestro esfuerzo a la economia de todas esas familias

    un saludo 😉

    Polloman

  9. Y el mundo quedó a salvo una vez más de las incompetencias y poco saber hacer de ese grupo de desarrolladores borrachos que, después de meses y meses trabajando sin descanso alguno y sacrificando muchos de ellos sus propias vidas, vieron como realmente la respuesta estaba en un par de líneas de código…Todo solucionado!. Endiosemos a nuestros maestros filósofos que con su gran sabiduría nos hacen ver lo tontos que somos.

  10. Hay que tomarse las cosas con humor y restarle importancia. Lo importante es comunicar y aprender y este post lo consigue (y a mi entender de manera divertida e ingeniosa)

    Además es un ejemplo brutal de lo que indica Rodrigo con los costes de los bugs en función de cuando son detectados. Pese a que a muchos nos gustaría tener la sabiduría de Unai o Pablo (y veo bien lo comentado por ellos), prefiero en este caso enterarme a través de FxCop e irme a tomar unas cervezas con los gurus, y que estos me cuenten la teoría sin mayor presión que la de la propia cerveza 😉

    Buen post.

  11. @Programador de bajo nivel:

    Mi intención no era ofender a nadie con este post… pido disculpas si ha sido así.

    Yo también he sido y en muchas facetas soy un ‘Programador de bajo nivel’. Pero no hay que asumir eso como algo inamovible. No es tampoco una cuestión de ser más tonto o más listo. Es una cuestión de tratar de mejorar día a día y sobre todo de no olvidar las buenas prácticas.

    Si un desarrollador no sabe que existe FxCop, pues que le vamos a hacer. Espero que lea este post y lo empieze a usar. Ese era mi afán al escribirlo. Si un desarrollador sabe que existe FxCop y no lo usa merece arder en una hoguera de bits, por que conscientemente se está exponiendo a errores gordos y complejos por simple dejadez.

    Sobre lo de trabajar ‘meses y meses sacrificando sus propias vidas’ solo puedo decir que se sacrifica mucho menos la vida si las cosas se hacen bien y pensando desde el principio.

    No me merecen ningún respeto ni admiración los desarrolladores que pasan 14 horas al día en su silla haciendo código de mierda. Es más creo que son remoras para nuestra profesión. Admiro al que trabajando 8 horas al día y hace código excelente a una velocidad excelente… y haberlos haílos. Y sobre todo admiro al desarrollador que no para de pensar en como desarrollar mejor y de manera más eficiente.

    La manera más efectiva de hacer las cosas, es hacerlas bien a la primera.

    ¡Un saludo!

  12. yo diria que «Programador de bajo nivel» se refiere mas a la abundancia de proyectos en los que tu no decides si algo debe programarse bien o mal… te plantan algo que ha empezado alguien y te dicen diaria o semanalmente esto tiene que estar hecho mañana o en 3 dias o cuando sea, quizas eso sea fisicamente imposible, de hecho puedes decir que no es posible terminar en ese tiempo porque hay cosas mal desde la base y deberian cambiarse lo antes posible pero te siguen exigiendo esos plazos y presionandote…

    Haces mas extras intentando terminar el trabajo a tiempo tienes un plazo que seria imposible cumplir con tus 8 horas diarias asi que echas horas para acabarlo y duermes mas bien poco

    Entonces te ponen en la sutuacion de que o dejas de dormir o eso no lo va a arreglar nadie… porque por supuesto el resto de desarrolladores estan exactamente igual de puteados que tu y ya puedes ser dios programando que no puedes alargar los dias para que de tiempo a corregir lo que esta mal de base y para discutir sobre la manera correcta de hacer las cosas nuevas…

    Supongo que hay un punto en el que como los jefes deciden y a ti nadie te hace caso prefieres pasar del tema, hacer las cosas a su manera y cuando se den cuenta de que las cosas no estan bien hechas pues nada que llamen a los de plain concepts para que les arreglen el marron

    Un saludo

    POLLOMAN

  13. @POLLOMAN:

    Lo siento, no puedo estar de acuerdo contigo; no en este caso. Entiendo que a todos nos aprietan con plazos, y que los programadores que, como tu dices, no tienen voz ni voto, muchas veces veran como sus jefes les mandan programar ‘mal’. Hasta ahi te doy la razon.

    Pero, una pregunta, ¿crees que la diferencia entre escribir un lock(syncObject) o lock(this.GetType()) sería determinante para llegar a ese plazo? ¿Crees que liberar todas las referencias a objetos en memoria cuando acabas con ellos lo es? ¿Que me dices de pasar a producción DLLs en modo Debug? y tantisimas cosas que he visto solo en estas ultimas semanas…

    Mira, en mi trabajo veo muchas cagadas, y me gusta porque mis clientes entienden que no se trata de buscar culpables, sino de mejorar las practicas a todos los niveles; gestion del proyecto, arquitectura, código. Pero creeme que muchas de las cagadas que veo son a nivel de código, y chico… ahi no podemos echar la culpa a los managers; somos dueños de nuestro código.. del mimo que pongamos en nuestro trabajo dependerá la calidad del mismo.

    Repito, POLLOMAN, que entiendo tus quejas, y yo mismo las sufro. Todos tenemos plazos, yo también siento ese látigo encima… pero chico, no podemos echarle la culpa a esto de todos nuestros fallos. De muchos, seguro que si… pero hagamos todos el ejercicio de tratar de aprender siempre un poquillo más y ser mejores profesionales cada día.

    Creo que el objetivo de Rodri con este post es precisamente enseñar como, gracias a esta herramienta, podemos ir aprendiendo de nuestros fallos. Me gustaría que todos nos quedaramos con ese trasfondo, con esa idea final; si queremos aprender, podemos… tenemos herramientas y documentacion que nos permiten hacer las cosas mal una vez, y aprender de ello.

    @Rodri: Perdona por robarte el post con este ladrillo xD

  14. En mi post intentaba aclarar lo que yo pienso que quiere decir «Programador de bajo nivel» con lo de sacrificar nuestras vidas y responder a lo que escribe rodrigo sin tener en cuenta todas las posibles circunstancias.

    —–Rodrigo escribio—–
    Sobre lo de trabajar ‘meses y meses sacrificando sus propias vidas’ solo puedo decir que se sacrifica mucho menos la vida si las cosas se hacen bien y pensando desde el principio.

    No me merecen ningún respeto ni admiración los desarrolladores que pasan 14 horas al día en su silla haciendo código de mierda. Es más creo que son remoras para nuestra profesión. Admiro al que trabajando 8 horas al día y hace código excelente a una velocidad excelente… y haberlos haílos. Y sobre todo admiro al desarrollador que no para de pensar en como desarrollar mejor y de manera más eficiente.
    ———-

    en este caso concreto yo tampoco creo que eso sea determinante para los plazos, pero si puede serlo el tener que utilizar algo que se desconoce y por esos plazos hacer las cosas a la carrera sin informarse todo lo bien que uno podria de cual es su correcta utilizacion y de los posibles problemas que puede ocasionar en ese momento o mas adelante

    no creo que quien escribiera ese codigo supiera de la existencia de esa herramienta, para la proxima vez pues eso que se ahorra todo el mundo

    pero bueno… para terminar solo decir que mantengo mi opinion para otros casos mas complejos en los que si tienes una tarea costosa un tiempo ridiculo y existe una manera que puedes tardar mas dejando todo bien y otra que entras en plazos como te piden o simplemente en lugar de 4 horas de mas esa tarde echas 1 y es una chapuza… al principio dices, voy a hacerlo bien… pero despues de 2 meses echando horas lo piensas y te das cuenta de que has estado haciendo el tonto, empiezas a cambiar tu forma de actuar(mientras dure ese proyecto que no hay que coger malas costumbres) y nada… asi tienes la posibilidad de ver el sol alguna tarde cuando sales de currar que tampoco hace daño

    menudo tocho me ha salido…

  15. @Polloman

    Pablo a interpretado exactamente lo que yo quiero decir, tanto con el post con los comentarios.

    También entiendo perfectamente tu pustura. Pero la clave la da Pablo. Nosotros somos los dueños de nuestro código. No podemos aceptar hacer chapuzas, aceptar hacer chapuzas se paga y se paga en los plazos. En el desarrollo de software la excelencia es una acelerador no algo que alarga los proyectos.

    Yo en mi carrera profesional nunca he aceptado hacer chapuzas (y aun así alguna he hecho), es cierto que en ocasiones esto me a granjeado enemigos a corto plazo, pero de verdad, creo que a medio plazo, no pasar por el haro de la chapuza a sido una excelente decisión.

    Evidentemente, también existe el peligro de preciosismo, pero yo hablo en esta ocasión de no olvidar y tratar de conocer las buenas prácticas… la diferencia de esfuerzo entre escribir buen código y mal código la pone el desarrollador, no el jefe de proyecto. Eso sí, un jefe de proyecto responsable, se asegura de que en su proyecto se usen las mejores prácticas de ingeniería del software… claro que para eso, el jefe de proyecto las tiene que conocer…

    @Pablete: mamón ya te vi a dar yo con el látigo ejejejejej…

    ¡Gracias por los comentarios!

  16. Rodri ho!!! no te piques, que el látigo va por la presión y la prisa que suelen tener nuestros clientes xDD

    Tu hoy tienes puesta la chapela de arquitecto (que no hay quien te la quite!), pero recuerda que yo ultimamente solo vivo y respiro DOT, y ya sabes como son nuestros ultimos escenarios: o van a producción mañana mismo, o ya están en producción con un sistema que se cae, y se vuelve a caer. A ese látigo es al que me refiero; aqui nadie se libra de las prisas.

    (uffff… creo que esta vez me he librado y me he buscado una buena excusa para lo del latigo XDD)

  17. @Pablo: Jajjaja… ya hombre ya!!!! que solo era bromear un poco… ya se la presión que se tiene con los temas del DOT que siempre son para ayer y con el cliente encima tuyo…!!!

  18. Mi carrera es mas corta que las vuestras con diferencia pero en mi corta experiencia lo que saco en claro es que hay que adaptarse al proyecto concreto y a tener una vida a la vez… si la vida no te permite hacer bien tu trabajo hay que ser profesional y corregirlo. Lo mismo a la inversa si el trabajo no te permite vivir hay que buscarle una solucion, muchas veces a un jefe no le importa la complejidad de las cosas solo los resultados y lo rapido del desarrollo.

    En una aplicacion que tiene que entrar en produccion o que está en produccion solo les importa que funcione correctamente lo mas rapido posible no que el codigo sea el mas optimo

    Pero bueno, que nos estamos desviando del tema principal… eso es ya cada uno con sus cosas y sus prioridades

    Probaré el FxCop a ver que tal =P

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *