Tabla de enlaces
Resumen e I. Introducción
II. Trabajo relacionado
A. Sobre la existencia de la habilidad de programación de pares
B. Sobre los elementos de la habilidad de programación de pares
Iii. Método de investigación
A. Objetivo de investigación y recopilación de datos
B. Enfoque de investigación cualitativa
C. Nuestras nociones de “bueno” y “malo”
IV. Resultados
A. Dos elementos de la habilidad de programación de pares
B. antipatrón: perderse en las malas hierbas
C. contra el patrón: perder al compañero
D. contra el patrón: ahogando al compañero
E. Hacer lo correcto y F. Otros elementos de la habilidad de programación de pares
V. Discusión
VI. Resumen y trabajo futuro
Vii. Disponibilidad de datos y referencias
B. antipatrón: perderse en las malas hierbas
Dos desarrolladores pueden tener más concepts sobre qué buscar y cómo proceder que un solo desarrollador. Pero los pares arriesgan Perderse en las malas hierbas Cuando saltan sobre muchos de ellos con muy poca consideración. Tales pares pueden lograr Quedarse juntos En eso, ambos piensan en todas estas nuevas concepts juntos, pero corren el riesgo de pensar demasiado en detalles irrelevantes, perder el rastro de lo que es importante y, por lo tanto, reducen sus Conveniencia.
Ejemplo 1: Sesión DA2 (09: 00–19: 00). Es la primera semana del desarrollador D4 en la compañía, y él y D3 tienen la tarea de implementar una nueva característica. D3 quiere explicar el estado objetivo mostrando una función related y ya existente. Mientras D3 se desplaza a través del código fuente, D4 lo interrumpe repetidamente con preguntas no relacionadas con su tarea, y D3 siempre hace todo lo posible para proporcionar toda la información que pueda (sigue el extracto altamente comprimido):
D3: “En principio, debe haber una barra de herramientas aquí arriba […] Te mostraré cómo se veía en el viejo calendario. [starts navigating in the source code]”
D4: “[reading from screen] ¿Para qué son estas cosas de navegación? ¿Son estas acciones? ¿Dónde se muestran?
D3: “[stops navigating] Hay un, ¿cómo se llama de nuevo? [starts searching through package tree …]”
D4: “[later: reading from screen, chuckling] Licensekey? “
D3: “[stops searching] Verás eso con más frecuencia por aquí […] Veamos dónde se usa [starts fulltext search …]”
Dado que D4 es nuevo en la compañía, proporcionándole información sobre la base del código podría Sea algo bueno, incluso si no es pertinente para la tarea precise. Sin embargo, ninguno De los matters laterales en realidad condujeron a D4 a comprender algo que no sabía (no se muestra arriba), por lo que caracterizamos esto como un caso de un par que tiene problemas (como se outline en la Sección III-C). En cambio, el tema principal (es decir, la explicación del estado objetivo a D4) se ve interrumpido por doce (!) Cambios de tema abruptos (solo dos de los cuales se muestran arriba). Terminar un intercambio con un tiempo neto de 30 segundos toma la pareja unos diez minutos, y podría haber sido aún peor, ya que D3 se perdió casi después de cinco minutos y solo encontró el camino de regreso porque se mostró una Stacktrace en la pantalla:
D3: “Okay. Ahora, ¿dónde estábamos? [looks around, sees stacktrace on lower display corner] Ah, la excepción, correcto “.
Autores:
(1) Franz Zieris, Institut Fur Informatik, Freie Universitat, Berlín Berlín, Alemania ([email protected]);
(2) Lutz Prechelt, Institut Fur Informatik. Freie Universitat Berlín, Berlín, Alemania ([email protected]).
