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

2. 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.

4. Por mucho que nos guste dar la culpa a
otros, generalmente el culpable es un tipo
con estas pintas.

6. O sea, un programador. Es decir,
nosotros.
Si trabajamos en un entorno más
enterprise, los culpables tendrán un
aspecto como este…

7. 01/02/2016 7

8. Pero no os dejéis engañar por las caras
de felicidad: son cupables.

9. Este tipo de código nos llevará semanas o
meses después a situaciones como esta

11. Gritaremos a nuestro código, pero a quien
estaremos gritando es a nuestro yo
pasado.

12. YOUR CODE AS
@vgaltes

13. 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.

15. 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.

17. 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.

18. Image from “Your code as crime scene” by Adam Tornhill

19. 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.

20. ¿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.

21. Image from “Your code as crime scene” by Adam Tornhill

22. 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.

23. Image from “Your code as crime scene” by Adam Tornhill

25. Un efecto colateral interesante de este
estudio es que quizá pueda obtener
información de donde está mi el dominio
de mi aplicación.

26. 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.

27. 01/02/2016 27

28. 01/02/2016 28

29. Empecemos extrayendo unas estadísticas
básicas.

30. SFA

32. Y ahora hagamos un análisis de los
hotspots.

34. Utiliza los hostspots como guia:
priorizar problemas de diseño
realizar revisiones de código
mejorar la comunicación

35. 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.

36. Whitespace analysis of complexity

37. 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.

38. Whitespace analysis of complexity

39. Whitespace analysis of complexity

40. También podemos estudiar el máximo
valor de esa complejidad a lo largo del
tiempo.

41. Whitespace analysis of complexity

42. O la media.

43. Whitespace analysis of complexity

44. O la desviación estándar.

45. Whitespace analysis of complexity

46. 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”.

47. 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.

48. “police receive surprisingly little instruction on how to
interview cooperative witnesses.”

49. 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.

50. 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.

51. Algunos de estos acoplamientos serán
normales y correctos, pero podemos
tener otros que puedan indicar un
problema.

52. Temporal coupling

54. Siempre hemos escuchado que los tests
son una red de seguridad de nuestro
código.

56. 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.

57. Data from “Your code as crime scene” by Adam Tornhill

58. 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.

59. Track your modification patterns
Image from “Your code as crime scene” by Adam Tornhill

60. 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.

61. Image from “Your code as crime scene” by Adam Tornhill

62. Si estamos codificando utilizando un
patrón arquitectónico, podemos medir la
belleza de nuestro código contra dicho
patrón.

63. Nop-Commerce
Data from “Your code as crime scene” by Adam Tornhill

64. 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.

66. 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).

67. 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.

69. 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.

70. 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.

71. ¿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.

72. 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.

73. Una manera de descubrir
comportamientos de nuestro equipo es
hacer una nube de palabras con los logs
de nuestro repositorio de código.

74. Discover your team modus operandi

75. 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.

76. Discover organizational metric in your codebase

77. 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.

78. Evaluate communication costs
ApprenticeshipSearchController. Main
Developer: Mark Gwilliam 69%
ApprenticeshipSearchMediator. Main
Developer: David Winchurch 88%
SearchProvider. Vicenc Garcia 29%

79. SearchController
Mark Gwilliam: 363, 14
David Winchurch: 108, 199
Krister Bone: 30, 117
Vicenc Garcia: 17, 18
Alan Gorton: 5, 30

80. SearchMediator
David Winchurch: 549, 241
Mark Gwilliam: 16, 361
Vicenc Garcia: 38, 9
Alan Gorton: 17, 7
Krister Bone: 3,5

81. 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

82. 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.

83. Knowledge map

84. Hay otras herrmientas para evaluar otros
tipos de dependencias entre archivos o
paquetes, librerías, etc.

85. 01/02/2016 85

86. 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.

90. Vicenç García Altés
vicenc.garcia-altes@valtech.co.uk
@vgaltes
vgaltes.com