Cita referencias de mejores prácticas de software

Actualmente estoy escribiendo mi tesis doctoral. Pasé una fracción significativa de mi doctorado limpiando y extendiendo el código científico existente, aplicando las mejores prácticas de ingeniería de software que no se usaban anteriormente, y me gustaría escribir sobre esto en mi tesis. En lugar de simplemente decir "Agregué pruebas unitarias", quiero poder escribir algo como esto:

J. Doe inventó las pruebas unitarias en 1975 [ 23 ] . Un estudio reciente de Bloggs et al [ 24 ] mostró que las pruebas unitarias reducen la incidencia de errores de software en un 73% ... Se agregaron 234 pruebas unitarias separadas a la base del código, administradas por el marco xUnit creado por Timpkins et al$^{[23]}$$^{[24]}$$^{[25]}$

Estoy buscando referencias académicas citables (preferiblemente artículos en revistas revisadas por pares donde pueda obtener DOI, BibTeX, etc.) a las mejores prácticas de ingeniería de software ampliamente aceptadas, específicamente:

• pruebas unitarias
• control de versiones
• modularización / separación de preocupaciones
• Perfiles de rendimiento / optimización basada en información de perfiles
• seguimiento de errores / problemas

Estoy buscando información tanto sobre la invención inicial como sobre evaluaciones posteriores de efectividad. Si hay un artículo de revisión que enumera todas estas cosas en un solo lugar, mucho mejor.

El libro Code Complete, segunda edición de Steve McConnell tiene una extensa bibliografía que discute estos temas desde el punto de vista de los desarrolladores de software más que de los científicos computacionales. El libro está comenzando a estar un poco anticuado, ya que se acerca a una década de antigüedad, por lo que no cubre metodologías de prueba más recientes como el desarrollo basado en el comportamiento. Sin embargo, es lo más parecido a un artículo de revisión exhaustivo sobre la construcción de software que conozco. También puede buscar artículos en el software IEEE.

En el lado de la ciencia computacional, creo que el mejor artículo es probablemente la versión PLoS de la preimpresión de arXiv que DavidKetcheson citó en "Las mejores prácticas para la computación científica". Digo que esto proviene de una formación en ingeniería, donde menos personas citan referencias de arXiv o preimpresiones de arXiv y, por lo tanto, citan un "artículo de revista real" (dejando de lado, por supuesto, todos los temas sobre publicación científica que se están debatiendo en este momento ) se ve más favorablemente (y tengo la impresión de que esos autores decidieron publicarlo en una revista).

Los autores del artículo PLoS que DavidKetcheson y yo citamos son parte de una organización llamada Carpintería de software que realiza (generalmente 2 días) "campos de entrenamiento" para enseñar a los científicos sobre algunas de las mejores prácticas para el desarrollo de software y habilidades informáticas útiles para los científicos (no solo científicos computacionales). El sitio web de Software Carpentry tiene una extensa bibliografía relacionada con el desarrollo de software en ciencias. Si estás interesado en estos temas, te animo a que te comuniques con ellos; siempre están buscando más defensores de las mejores prácticas en el desarrollo de software para hacer voluntariado en diversas capacidades. ( Descargo de responsabilidad : soy voluntario en Carpintería de software).

Otra justificación común para participar en las mejores prácticas de desarrollo de software es la reproducibilidad. Victoria Stodden ha seleccionado una larga lista de referencias de investigación reproducibles que pueden ser de interés, dependiendo de lo que quiera decir.

No tengo referencias para el origen de cada una de estas ideas / prácticas. Pero aquí hay algunas referencias relevantes muy recientes:

• ¿Qué hace que las bibliotecas de software computacional de código abierto sean exitosas?
• Mejores prácticas para la computación científica

En mi humilde opinión, tendría mucho cuidado al citar las "mejores prácticas" en el contexto de enfoques científicamente probados. La mayoría de las prácticas se derivan de "lo que parece funcionar para un conjunto de proyectos por alguien percibido como gurú involucrado en esos proyectos", en lugar de derivar de pruebas rigurosas de diferentes enfoques. Hay demasiadas variables y factores humanos en la ingeniería de software para indicar que hay una lista de "mejores prácticas" (por ejemplo, una práctica que funciona en un proyecto fallará por completo en otro).

Lo abordaría indicando lo que su proyecto necesitaba, por qué lo necesita y agregar referencias a los métodos utilizados y por qué los usó.

También me inclinaría por informar resultados cuantificables en lugar de referencias para expresar su punto. Por ejemplo, si su unidad prueba 100 errores descubiertos, 10 de los cuales son lo suficientemente graves como para poner en duda el resultado publicado anteriormente. Esta es una declaración mucho más poderosa para tener en tu doctorado que una declaración de que conoces el origen de las pruebas unitarias.

editar: (error tipográfico fijo) - Respondiendo lo siguiente - A menudo doy a criar niños como una analogía con proyectos de software. Existen muchos métodos y formas comprobadas de criarlos, tratando de criar a sus hijos con un método porque funciona para el promedio o una submuestra examinada, funcionará siempre que su hijo sea el mismo que el examinado. Es mejor conocer muchos métodos y aplicar los que funcionan en su instancia. Sí, se pueden probar las pruebas unitarias, pero aplicarlo solo en base a eso podría significar que su proyecto llega tarde al mercado y, por lo tanto, falla su objetivo (si ese es el objetivo). Estoy diciendo que aplicar un método para obtener un resultado y dar el resultado de ese resultado, en mi opinión, es mejor en una tesis, que enumerar las cosas que probaste en base a otros proyectos, a menos que, por supuesto, el tema de la tesis sea medir metodologías :)