Post on 12-Apr-2017
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.
Por mucho que nos guste dar la culpa a otros, generalmente el culpable es un tipo con estas pintas.
O sea, un programador. Es decir, nosotros.
Si trabajamos en un entorno más enterprise, los culpables tendrán un aspecto como este…
02/05/2023 7
Pero no os dejéis engañar por las caras de felicidad: son cupables.
Este tipo de código nos llevará semanas o meses después a situaciones como esta
Gritaremos a nuestro código, pero a quien estaremos gritando es a nuestro yo pasado.
YOUR CODE AS
@vgaltes
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.
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.
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.
Image from “Your code as crime scene” by Adam Tornhill
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.
¿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.
Image from “Your code as crime scene” by Adam Tornhill
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.
Image from “Your code as crime scene” by Adam Tornhill
Un efecto colateral interesante de este estudio es que quizá pueda obtener información de donde está mi el dominio de mi aplicación.
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.
02/05/2023 27
02/05/2023 28
Empecemos extrayendo unas estadísticas básicas.
SFA
Y ahora hagamos un análisis de los hotspots.
Utiliza los hostspots como guia:
priorizar problemas de diseñorealizar revisiones de códigomejorar la comunicación
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.
Whitespace analysis of complexity
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.
Whitespace analysis of complexity
Whitespace analysis of complexity
También podemos estudiar el máximo valor de esa complejidad a lo largo del tiempo.
Whitespace analysis of complexity
O la media.
Whitespace analysis of complexity
O la desviación estándar.
Whitespace analysis of complexity
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”.
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.
“police receive surprisingly little instruction on how tointerview cooperative witnesses.”
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.
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.
Algunos de estos acoplamientos serán normales y correctos, pero podemos tener otros que puedan indicar un problema.
Temporal coupling
Siempre hemos escuchado que los tests son una red de seguridad de nuestro código.
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.
Data from “Your code as crime scene” by Adam Tornhill
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.
Track your modification patterns
Image from “Your code as crime scene” by Adam Tornhill
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.
Image from “Your code as crime scene” by Adam Tornhill
Si estamos codificando utilizando un patrón arquitectónico, podemos medir la belleza de nuestro código contra dicho patrón.
Nop-Commerce
Data from “Your code as crime scene” by Adam Tornhill
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.
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).
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.
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.
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.
¿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.
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.
Una manera de descubrir comportamientos de nuestro equipo es hacer una nube de palabras con los logs de nuestro repositorio de código.
Discover your team modus operandi
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.
Discover organizational metric in your codebase
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.
Evaluate communication costs
ApprenticeshipSearchController. Main Developer: Mark Gwilliam 69%
ApprenticeshipSearchMediator. Main Developer: David Winchurch 88%
SearchProvider. Vicenc Garcia 29%
SearchController
Mark Gwilliam: 363, 14 David Winchurch: 108, 199 Krister Bone: 30, 117 Vicenc Garcia: 17, 18 Alan Gorton: 5, 30
SearchMediator
David Winchurch: 549, 241 Mark Gwilliam: 16, 361 Vicenc Garcia: 38, 9 Alan Gorton: 17, 7 Krister Bone: 3,5
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
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.
Knowledge map
Hay otras herrmientas para evaluar otros tipos de dependencias entre archivos o paquetes, librerías, etc.
02/05/2023 85
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.
Vicenç García Altésvicenc.garcia-altes@valtech.co.uk
@vgaltesvgaltes.com