Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Your code as a crime scene

922 views

Published on

Charla presentada en el Bilbostack 2016 (htp://www.bilbostack.com)

Published in: Engineering
  • Login to see the comments

Your code as a crime scene

  1. 1. A veces nuestro código parece una escena de un crimen: hay muertos, sangre, cosas rotas… Si nos fijamos bien podemos ver algún singleton o trazas de un framework de Javascript arcano.
  2. 2. Por mucho que nos guste dar la culpa a otros, generalmente el culpable es un tipo con estas pintas.
  3. 3. O sea, un programador. Es decir, nosotros. Si trabajamos en un entorno más enterprise, los culpables tendrán un aspecto como este…
  4. 4. 01/02/2016 7
  5. 5. Pero no os dejéis engañar por las caras de felicidad: son cupables.
  6. 6. Este tipo de código nos llevará semanas o meses después a situaciones como esta
  7. 7. Gritaremos a nuestro código, pero a quien estaremos gritando es a nuestro yo pasado.
  8. 8. YOUR CODE AS @vgaltes
  9. 9. Esta charla está basada en este libro de Adam Tronhill ( https://pragprog.com/book/atcrime/your- code-as-a-crime-scene). No dejéis de leer el libro porque es muy interesante.
  10. 10. Londres 1888. Jack the Ripper acaba de cometer su quinto asesinato. Al igual que las cuatro veces anteriores la policía no es capaz de encontrar al culpable.
  11. 11. Más de 125 años después, se sigue intentado saber quien fue Jack the Ripper. El profesor David Canter, utilizando Dragnet, un software desarrollado por The Center for Investigative Psychology, llegó a determinar el área donde probablemente vivía Jack the Ripper. Dragnet considera cada localización de un crimen como un centro de gravedad y combina los centros matemáticamente considerando sus distancias relativas.
  12. 12. Image from “Your code as crime scene” by Adam Tornhill
  13. 13. En los años 90 se descubrió un diario de James Maybrick, un “merchant” del algodón que decía ser Jack the Ripper. Curiosamente el señor Maybrick acostumbraba a alquilar una habitación en Middlesex Street, que está dentro del hotspot hallado con Dragnet.
  14. 14. ¿Como analizar los hotspots en nuestra base de código? Una primera opción sería ver qué archivos tienen más complejidad. Por ahora asumiremos que complejidad es igual a tamaño del fichero, que es una métrica muy fácil de calcular y bastante fiable.
  15. 15. Image from “Your code as crime scene” by Adam Tornhill
  16. 16. Pero que pasa si tengo un archivo muy complejo pero que hace tiempo que no toco? Es allí donde tengo que focalizar mis esfuerzos a día de hoy. Una métrica que puede ser más útil es añadir a la complejidad ya calculada la tasa de cambio del fichero. Parece razonable pensar que un archivo complejo que se cambia mucho puede ser una fuente de bugs.
  17. 17. Image from “Your code as crime scene” by Adam Tornhill
  18. 18. Un efecto colateral interesante de este estudio es que quizá pueda obtener información de donde está mi el dominio de mi aplicación.
  19. 19. Este es el proyecto que vamos a estudiar en parte de esta charla. (url) Es una aplicación web que tiene una parte importante de búsqueda.
  20. 20. 01/02/2016 27
  21. 21. 01/02/2016 28
  22. 22. Empecemos extrayendo unas estadísticas básicas.
  23. 23. SFA
  24. 24. Y ahora hagamos un análisis de los hotspots.
  25. 25. Utiliza los hostspots como guia: priorizar problemas de diseño realizar revisiones de código mejorar la comunicación
  26. 26. Otra manera senzilla de calcular la complejidad es analizar los espacios en blanco del código. A más espacios en blanco (tabulaciones) más complejidad tendrá nuestro código.
  27. 27. Whitespace analysis of complexity
  28. 28. En la imagen anterior se puede observar el resultado de un refactoring que se hizo a principios de enero. También se puede observar como se añadió a finales de marzo una nueva feature que causó que se incrementara la complejidad.
  29. 29. Whitespace analysis of complexity
  30. 30. Whitespace analysis of complexity
  31. 31. También podemos estudiar el máximo valor de esa complejidad a lo largo del tiempo.
  32. 32. Whitespace analysis of complexity
  33. 33. O la media.
  34. 34. Whitespace analysis of complexity
  35. 35. O la desviación estándar.
  36. 36. Whitespace analysis of complexity
  37. 37. En el 1979 se produjeron una serie de robos en varios pueblos de Delaware y Pennsylvania. La característica común de estos robos es que fueron realizados de manera muy “educada”.
  38. 38. Varios testigos identificaron al padre Pagano como el ladrón. El “pequeño” problema es que el padre Pagano no era el culpable. De entre todos los sospechosos, el padre pagano fue el único que era un clérigo. Antes de las ruedas de reconocimiento, la policía mencionó que el culpable podría ser un clérigo. Es decir, la policía influyo en la memoria de los testigos.
  39. 39. “police receive surprisingly little instruction on how to interview cooperative witnesses.”
  40. 40. La policía no trató la entrevistas de una forma cooperativa, comparándola con datos. Tenemos que tratar nuestro código también como algo cooperativo.
  41. 41. Podemos estudiar con que frecuencia diferentes archivos son comiteados a la vez. De esta manera podemos descubrir acoplamientos temporales difíciles de descubrir con otras herramientas.
  42. 42. Algunos de estos acoplamientos serán normales y correctos, pero podemos tener otros que puedan indicar un problema.
  43. 43. Temporal coupling
  44. 44. Siempre hemos escuchado que los tests son una red de seguridad de nuestro código.
  45. 45. Pero nuestros tests pueden no estar codificados de una manera correcta. Si estudiamos el acoplamiento del código con nuestros tests, podemos descubrir malas decisiones de implementación. Por ejemplo, podríamos descubrir que estamos modificando demasiado nuestros tests end-to-end, que deberían ser unos tests más estables.
  46. 46. Data from “Your code as crime scene” by Adam Tornhill
  47. 47. También podemos estudiar como evoluciona nuestro código y nuestros tests en función de los cambios que les hacemos. Cuando empezamos a dedicar más tiempo a nuestros tests que a nuestro código de producción seguramente es que hay algo que tengamos que mirar.
  48. 48. Track your modification patterns Image from “Your code as crime scene” by Adam Tornhill
  49. 49. La universidad de Glasgow hizo un estudio sobre la belleza del que concluyó que a la gente les gustaban más aquellas caras a las que se les habían quitado las diferencias individuales respecto la media. Por tanto podemos decir que la belleza es aquello que tiene consistencia y no tiene sorpresas.
  50. 50. Image from “Your code as crime scene” by Adam Tornhill
  51. 51. Si estamos codificando utilizando un patrón arquitectónico, podemos medir la belleza de nuestro código contra dicho patrón.
  52. 52. Nop-Commerce Data from “Your code as crime scene” by Adam Tornhill
  53. 53. A principios de los 90 Suecia tuvo su primer serial killer. Thomas Quick (encarcelado en una institución mental) empezó a confesar con todo lujo de detalles asesinatos no resueltos (sin cuerpo presente). El problema era que Thomas Quick no era culpable.
  54. 54. Cuando trabajamos nos enfrentamos a poderosos biases sociales que debemos entender para intentar evitarlos. Uno de ellos es process loss, que dice que un grupo nunca puede rendir al 100% de su capacidad. El echo de trabajar juntos tiene unos costes que debemos entender (coordinacion y motivacion).
  55. 55. En "The Emperor's New Clothes" Hans Christian Andersen cuenta que al Emperador le regalaron un cofre vacío diciéndole que allí había ropa que solo aquellos dignos de su confianza podían ver. El Emperador se las puso y caminó desnudo por toda la ciudad, pero nadie se atrevió a decirselo.
  56. 56. A este bias social se le llama Pluralistic Ignorance y sucede cuando en un equipo todo el mundo en privado piensa una cosa pero nadie se atreve a decirla en público.
  57. 57. Hay otros biases sociales como confundir una opinión muy repetida por la realidad, o el de magnificar una opinión minoritaria porque está en concordancia con las creencias del grupo. Hay que intentar luchar contra los biases sociales con preguntas y con datos.
  58. 58. ¿Qué le pasó a Thomas Quick? Fué drogado para hacer los interrogatorios. Los terapeutas explicaron a la policia las confesiones de Quick después de implantarle falsas memorias. La policia creyño a los terapeutas. Cuando Quick no decia una confesion muy clara, recibia ayuda de los interrogadores hasta conseguir una historia plausible.
  59. 59. Años después gente relacionada con la investigación confesó que no veían nada claros los métodos del interrogatorio, pero que en su momento no se atrevieron a decir nada.
  60. 60. Una manera de descubrir comportamientos de nuestro equipo es hacer una nube de palabras con los logs de nuestro repositorio de código.
  61. 61. Discover your team modus operandi
  62. 62. También podemos ver la cantidad de autores que tiene un archivo. Puede ser razonable pensar que cuantos más autores tenga un archivo, más probabilidades haya de que allí haya un bug.
  63. 63. Discover organizational metric in your codebase
  64. 64. Y también podemos evaluar los costes de comunicación dentro de un equipo mirando quien es el autor principal de los archivos. Si dos archivos muy relacionados tienen diferentes autores, tenemos que asegurarnos que haya una buena comunicación entre ambos.
  65. 65. Evaluate communication costs ApprenticeshipSearchController. Main Developer: Mark Gwilliam 69% ApprenticeshipSearchMediator. Main Developer: David Winchurch 88% SearchProvider. Vicenc Garcia 29%
  66. 66. SearchController Mark Gwilliam: 363, 14 David Winchurch: 108, 199 Krister Bone: 30, 117 Vicenc Garcia: 17, 18 Alan Gorton: 5, 30
  67. 67. SearchMediator David Winchurch: 549, 241 Mark Gwilliam: 16, 361 Vicenc Garcia: 38, 9 Alan Gorton: 17, 7 Krister Bone: 3,5
  68. 68. SearchProvider Vicenc Garcia: 180, 108 Christopher Monney: 151, 76 Krister Bone: 103, 44 David Winchurch: 99, 41 Alan Gorton: 49, 21 Mark Gwilliam: 33, 33
  69. 69. Finalmente, podemos hacer un mapa de los autores de cada archivo para encontrar posibles problemas de comunicación. Esta técnica nos puede servir, por ejemplo, para ver que archivos se quedan huérfanos si un miembro del equipo se va.
  70. 70. Knowledge map
  71. 71. Hay otras herrmientas para evaluar otros tipos de dependencias entre archivos o paquetes, librerías, etc.
  72. 72. 01/02/2016 85
  73. 73. Hemos visto técnicas que nos pueden ayudar a determinar problemas en nuestra base de código. Es importante hacer notar que estas técnicas no tienen la verdad absoluta, y que después de aplicar cada una de ellas es nuestra responsabilidad estudiar cada caso en concreto y evaluar si allí hay un problema o no.
  74. 74. Vicenç García Altés vicenc.garcia-altes@valtech.co.uk @vgaltes vgaltes.com

×