Historias de developers

by Alberto de Vega Luna

Completitud:

Si un componente del sistema no está representado en los resultados, el programador puede no ser consciente de su impacto en el sistema como un todo.

Rap...

los profilers lentos con frecuencia no se pueden aplicar en entornos realistas, ya que pueden provocar datos erróneos.

Carácter general:

deben evitar ser usados exclusivamente para técni...

flexibilidad, portabilidad, transparencia, rápid...

Tipos de pr...

Profiler sobre un “punto ...

definir eventos simples e ind...

Profiler sobre el contexto:

obtención de un conjunto de eventos, es decir, una composición de los mismos ordenados.

Datos en una herramienta profiler

los datos se recogen en tiempo de ejecución.

las referencias obtenidas requieren algún tipo de tratamiento posterior con el fin de revelar datos interesantes relacionados con el rendimiento

funciones de granularidad donde se permite al desarrollador detectar fácilmente el foco del problema de rendimiento.

los datos representados se clasifican como exacto...

los primeros cuentan toda la historia, es decir, no faltan ele...

los datos estadísticos no son 100% exactos, y para que sean útiles se espera que sean una representación real...

sub-tipos de datos estadísticos:

datos que son inexactos debido a la incertidumbre inherente a ciertas medidas.

Y la inexactitud debida a-generalmente- el resultado del examen de métodos de profilers, y las limitaciones inherentes a su resolución.

Técnicas de profiling

preliminar código de arranque, fácilmente incorporado a través de mecanismos como LD_PRELOAD

Instrumentación a nivel de código fuente

Instrumentación en tiempo de compilación:

Instrumentación binaria “offline”:

Instrumentación binaria “online”:

Caso práctico Debugging

cualquier desarrollador durante el proceso de codificación realiza tareas de debugging antes de entregar el código.

Las herramientas de debugging junto a los tests unitarios sirven para realizar la primera comprobación de que el código implementado realiza exactamente lo que se espera de él.

Consejo 1: Cuando las cosas parece que sólo van a peor, cálmate y piensa en solucionarlo, no haces nada con ponerte nervioso.

Consejo 2: Aunque las pistas te lleven a un lugar y normalmente sean correctas, verifica el resto de posibilidades, porque las sorpresas existen.

Consejo 3: El primer paso para solucionarlo es encontrar el problema. Por muy compleja que sea la solución saber cuál es tu necesidad es lo único que te va a ayudar a solucionarlo.

Caso práctico Profiling

Con éste tipo de herramientas extraemos información de código muerto, qué código es el más utilizado, en qué parte del código es dónde nuestra aplicación “pierde” más tiempo, etcétera.

tampoco debemos obsesionarnos con el rendimiento. Si estamos haciendo una aplicación que va a tener 2 usuarios concurrentes con una media de 3 peticiones/minuto no es lo mismo que si estamos desarrollando una aplicación que debe responder 100.000 peticiones/segundo.

Consejo 1: Es muy importante conocer los requisitos de rendimiento. Si no los tenemos, pidámoslos o estimémoslos. El cliente debe conocer cuáles son esos números de antemano.

Antes de entrar a producción realizamos varias sesiones de profiling para comprobar cuál era el rendimiento de nuestra aplicación.

Realizábamos varias pruebas con diferentes implementaciones, con una única conexión a base de datos, con varias queries, con una única comunicación externa a una caché, con la caché vacía y que se fuera llenando lentamente, pre cargando la caché con anterioridad, etc.

Consejo 2: Realiza el mayor número de pruebas posible con diferentes pruebas e implementaciones. Te ayudará a encontrar la mejor solución.

retocar las queries a la base de datos para conseguir un mayor rendimiento

Conocer técnicas de debugging y profiling es necesario para cualquier desarrollador independientemente del tipo de software que se desee desarrollar.

La estimación es la raíz de muchos de los fracasos en los proyectos de desarrollo software.

Estimar proviene del latín aestimāre y significa calcular el valor aproximado de algo o tener una opinión sobre algo o alguien.

Calcular,

Aproximado,

Opinión

consiste en calcular un valor y una desviación de un hito para poder gestionar la mejor consecución de éste. Y cuando hablamos de gestionar, es en términos de encontrar la mejor manera de llegar a un fin y no en términos de forzar que la estimación se convierta en una realidad a costa de otros valores y principios.

su clon es-timar, que por desgracia es muy común encontrar en la ingeniería software.

Consiste en dejar de lado el valor estadístico usado para gestionar un proyecto, sus recursos y su calidad y marcar compromisos ambiguos con clientes o usarlo como elemento de presión a los equipos de desarrollo. El uso fraudulento de la palabra suele detectarse claramente viendo el origen de su valor. Cuando este valor no es calculado por las personas que realmente van a realizar un trabajo sino por las personas intermedias o receptoras de este tiene efectos nocivos en la motivación de las personas y en la calidad del trabajo que se está realizando y solo reporta beneficios a muy corto plazo.