¿Debo compartir mi horrible software?

Si deberías.

Primero, la mayoría del software científico es terrible. Me sorprendería mucho si el tuyo es peor que el promedio: el mero hecho de que conoces los patrones de diseño y la diferencia entre la recursividad y los bucles sugiere que es mejor.

En segundo lugar, es poco probable que tenga el incentivo o la motivación para mejorarlo a menos que, o hasta que, alguien más lo necesite (o usted en 6 meses). Abrirlo te da ese incentivo.

Potenciales ventajas: posibles nuevos colaboradores, corrección de errores, extensiones, publicaciones.

Desventajas potenciales: disipador de tiempo (mantener el código o solucionar problemas para otras personas), ser descubierto. Seré claro: no me tomo ninguno de estos inconvenientes muy en serio.

Lo limpiaría un poco y lo compartiría. He publicado mucho código a lo largo de los años, y tampoco he publicado código por las razones que das.

Revísalo y coméntalo, en cualquier nivel que puedas. Dejar en "intentos fallidos" y comentarlos como tal. Di por qué fallaron y qué intentaste. Esta es información MUY útil para las personas que vienen después de ti.

Cree un archivo README que diga que lo está lanzando a pedido con la esperanza de que ayude a alguien. Digamos que sabe que el código es feo, pero espera que sea útil de todos modos.

¡Demasiadas personas retienen las cosas porque no es perfecto!

¡Sí! Especialmente si su trabajo es, por ejemplo, sobre un algoritmo nuevo/mejorado que ha implementado, o si realiza un análisis de datos no estándar significativo, o básicamente cualquier cosa en la que reproducir sus resultados signifique volver a implementar su software.

Los artículos rara vez tienen espacio para dar más que un bosquejo. Sé que he pasado (= desperdiciado) demasiado tiempo tratando de implementar algoritmos de documentos que omitieron detalles críticos (pero no estrictamente relevantes para el documento).

¿Crees que tu código está desordenado? He visto (e intentado trabajar con) un código que me dio pesadillas:

• Cinco niveles de if Trueanidados, dispersos en lugares aleatorios a través del código.
• Cree una matriz de ceros, conviértala a grados, tome el coseno y vuelva a radianes. Luego, deseche el resultado.
• En un software bajo un fuerte desarrollo, la lista de "arquitecturas compatibles" es tan antigua (y ellos mismos lo dicen) que hoy en día sería difícil tener en sus manos una de estas computadoras.
• Funciones rotas o modificadas hace varias versiones, aún recomendadas en los documentos.
• Código que va de usar una entrada de formato estándar a algún formato propio. ¿Cómo generarlo? Nadie lo sabe realmente, y los desarrolladores dan una respuesta.
• Lanzamientos que ni siquiera compilan. (¿Incluso lo probaste?)
• Menús GUI a los que tiene que acceder en un orden específico. De lo contrario, obtiene una falla de segmentación y debe comenzar desde el principio.
• Rutas codificadas de forma rígida dispersas por el código. Por lo tanto, debe desplazarse a través de varios archivos para encontrar y cambiar todas las apariciones de /home/someguy/absurd_project/working/la suya.

Y, mi favorito personal, cierto programa de miles de líneas de código, solo usaba comentarios para eliminar fragmentos de código aleatorios, excepto uno:

Aquí perforamos las cartas.

Aún así, ni idea de lo que estaba haciendo.

Y esto solo deja fuera las cosas clásicas de buenas prácticas, como variables de una letra en todo el código, algoritmos no especificados en ninguna parte...

Si le preocupa la calidad de su código, probablemente signifique que le importa lo suficiente como para haberlo hecho mejor que el promedio. Si espera hasta que el código esté limpio, es posible que nunca salga y sus contribuciones científicas se pierdan parcialmente.

En mi opinión, las cosas importantes que te deben importar, en orden, son:

1. Formatos de entrada y salida. Use estándares cuando estén disponibles, hágalo simple cuando no lo esté. Facilite el uso de su programa como una caja negra.
2. comentado. Breves descripciones de las funciones, resumen rápido del algoritmo.
3. Legibilidad. Usando código idiomático, buenos nombres de variables...
4. Estructura. Esto es más fácil cuando sabes lo que quieres hacer, que generalmente no es el caso en el código de investigación. Solo si hay interés en la comunidad, puede considerar refactorizarlo.

Por lo tanto, publique su software cada vez que tenga 1 (2 y parte de 3 deben aparecer mientras lo escribe).

Estás preguntando si compartir software de baja calidad daría una mala impresión de ti. Creo que compartir software da una buena impresión.

1. Como científico informático, me gusta cuando los colegas ponen a disposición su código fuente. Me hace más probable profundizar en su trabajo, tal vez contactarlos, tal vez citarlos, porque hay un artefacto más con el que interactuar (no solo el papel, sino también el código).

2. Cuando un artículo informa un resultado que está "probado" por el código fuente, pero el código fuente no es público, a menudo me pregunto si el resultado es real. Mirar el código fuente (o simplemente la disponibilidad del código fuente, sin siquiera mirarlo) puede convencerme.

Así que compartir tu código fuente, horrible o no, siempre me daría una buena impresión de ti.

Ahora bien, si quieres impresionar aún más, te ayudaría...

... si reaccionas a problemas o solicitudes de extracción en un sitio como github, es decir, cuando veo que otros intentan contactarte y tú reaccionas.

... si su código contiene un archivo Léame que relaciona las afirmaciones de su artículo con el código fuente. De esta manera, cuando leo el documento y quiero saber más, puedo usar el archivo Léame para saltar al lugar apropiado en el código. Las frases típicas de dicho archivo Léame podrían ser: "El algoritmo de la Sección 3.2 del documento está en el archivo algoritmo/nueva versión/relacionado/segundo intento/foo.c" o "Para repetir la ejecución con el pequeño conjunto de datos descrito en la Sección 2 de el papel, ejecutar "hacer; hacer segundo_paso; foo_bar_2 conjuntos de datos/navidad.conjunto de datos. Esta ejecución toma alrededor de 2 días en mi computadora portátil".

También podría estar interesado en CRAPL (Licencia de programación académica y de investigación comunitaria) de Matthew Might, disponible en http://matt.might.net/articles/crapl/ . Contiene este término: "Usted acepta mantener al autor libre de vergüenza, vergüenza o ridículo por cualquier piratería, chapuza o acto de fe que se encuentre dentro del Programa". No me queda claro si esta "licencia" tiene algún efecto legal, pero la intención es clara: libera tu feo código y no pienses mal del feo código de los demás.

Relacionado tangencialmente, abordaré cómo compartir el software dadas sus inquietudes (no debe compartir el software para el que ya tiene una respuesta).

Poner los intentos fallidos en el control de versiones significa que nadie los verá nunca. La forma en que manejo esto es poner cada intento en un método y cada intento fallido en un método separado:

def main():
    get_foobar(x, y)


def get_foobar():
    return x**y


def get_foobar_legacy_1():
    """
    This attempt did not work for values > 100
    """
    return x + y


def get_foobar_legacy_2():
    """
    This attempt did not work on Wednesdays in September
    """
    return x - y

Según los comentarios a continuación, puede ser una buena idea colocar estos métodos en una clase FailedAttempts o BadIdeas separada. Esto tiene el agradable efecto de compartimentar las diversas etapas del proceso según la necesidad real. Encuentro que los programadores de computadoras a menudo saben cuándo dividir la lógica en un método y cuándo no, pero los científicos informáticos a menudo no la tienen. Este enfoque ayuda a los informáticos a dividirse en un método cuando sea necesario.

Por supuesto, debe compartir el código fuente.

Académicamente hablando, un resultado basado en software que utiliza un código que no está fácilmente disponible no es muy valioso, ya que, ¿cómo podrían otras personas verificar sus afirmaciones, si es necesario? ¿Esperas que programen por su cuenta para este propósito? Compartir solo binarios es mucho menos valioso y, a menudo, genera pesadillas para las personas que intentan ejecutarlos.

Creo que deberías compartirlo. En primer lugar, debe hacer una limpieza básica. (p. ej.: no hay código anterior que ya no se use; no hay código en el comentario; forma válida de comentar, etc.) Además, si pone algo de "cosa por hacer" en el código, los demás pueden ver que se le acabó el tiempo y pueden ver tus intenciones (por ejemplo: todo: esto debería cambiarse a enum) También creo que deberías compartir la parte más importante de tus algoritmos. Cuando comparto un código, nunca comparto partes sin importancia. Todos pueden manejar la lectura/escritura de archivos, la comunicación entre subprocesos, la interfaz gráfica de usuario, etc. Pero no comparta código ilegible. No tendría sentido. Así que creo que el camino medio es el mejor muchas veces. :-)

Habla con algunos de los profesores de tu departamento de informática. Vea si alguno de ellos está buscando un proyecto en el que los estudiantes puedan limpiar el código desordenado para hacerlo más presentable.

Para los estudiantes que revisan el código, esta puede ser una buena experiencia de aprendizaje. ¿Qué sucede cuando los codificadores programan con una mentalidad de resultados primero o una mentalidad de solo resultados? Llegan a ver eso de primera mano. También pueden aplicar algunas de las mejores prácticas sobre las que han estado aprendiendo. Y pueden estar motivados para hacer un trabajo especialmente bueno sabiendo que otros profesionales ya están interesados ​​en ver el código.

Un profesor podría incluso convertir esto en un concurso, donde los equipos de estudiantes intentan revisar el software y el mejor resultado se comparte con el resto del mundo.

Si sus esfuerzos de refactorización fracasan, no estarás más atrasado de lo que estabas. Si ese es el caso, los descargos de responsabilidad son una cosa maravillosa. Simplemente comparta el código, pero agregue una advertencia: "No es bonito. Cuando escribí esto, estaba tratando de hacer mi investigación, no pensé que alguna vez saldría de mi laboratorio de computación. Pero de nada para echar un vistazo si realmente quieres".

En las otras respuestas se han mencionado muchos puntos a favor de publicar el código, y estoy completamente de acuerdo con ellos. Por lo tanto, como se ha discutido la conveniencia básica de publicar el código, me gustaría complementar esto con una lista de verificación de puntos adicionales que deben considerarse. Es probable que muchos de estos problemas aparezcan en prácticamente todo el software académico, por lo que incluso si no puede responder "Esto no se aplica a mi proyecto". a todos ellos, al menos debería poder responder "Esto es una preocupación, pero podemos solucionar este problema para..." antes de publicar su código:

• ¿Tienes permiso para publicar el código?
  • ¿Puede garantizar que solo usó fragmentos de código que puede redistribuir? ¿O posiblemente usó código de fuentes no abiertas que puede usar para su propio software interno, pero que no puede publicar? ¿Puede garantizar que todo el código que usó se puede publicar en un paquete completo? La compatibilidad de licencias no es un tema trivial.
  • ¿Puedes siquiera averiguarlo de forma fiable? ¿Subcontrató alguna parte de su trabajo de codificación o integró código no publicado de otro lugar? Por ejemplo, ¿supervisó a algún estudiante durante sus tesis de graduación o empleó a algún estudiante asistente de investigación, cuyo trabajo se basó en su investigación y, por lo tanto, su código se agregó a su base de código? ¿Algún compañero de trabajo contribuyó con código a su base de código? ¿Recibieron algo de su código de los estudiantes? ¿Todas estas personas involucradas prestaron la debida atención a los problemas de licencias (si es que tenían el conocimiento para emitir un juicio educado sobre estas cuestiones de licencias)? ¿Se puede determinar aún dónde se originaron las partes del código? ¿Las personas que contribuyeron con cada parte aún lo saben? ¿Están todavía "dentro del rango de contacto" para ti?
  • ¿Se desarrolló el código durante el tiempo de trabajo con fondos de terceros? Si es así, ¿los términos del contrato de financiación permiten publicar el código o incluyen algún requisito de que el software creado dentro del proyecto financiado debe compartirse exclusivamente con los socios del proyecto?
• ¿Tiene suficientes recursos (tiempo y otros) para dedicar el esfuerzo a limpiar el código y sus comentarios de manera que siga siendo significativo, pero no proporcione ninguna información que no deba hacerse pública?
  • ¿Tiene algún comentario que revele quién trabajó en el código? ¿Se les permitió oficialmente a las personas que contribuyeron con el código trabajar en la investigación respectiva, según su financiación? (Los desarrolladores de software son muy conscientes de que el trabajo en equipo y la reutilización de componentes son aspectos centrales del desarrollo de software. Lamentablemente, las agencias de financiación suelen desconocer esto y suponen que si el desarrollador A recibe fondos del proyecto X y el desarrollador B recibe fondos del proyecto Y, A trabaja exclusivamente en X y B trabaja exclusivamente en Y, y revelar que, wlog, A pasó solo media hora haciendo algo que terminó en el proyecto Y podría tener graves consecuencias, como reclamar partes de los fondos).
  • ¿Algo en los datos publicados revela alguna información sobre las particularidades de cómo se hizo el trabajo que no debe hacerse público?Esto es especialmente importante si todo el historial de confirmaciones en un VCS se va a hacer público (o, en la práctica, significa que el historial de confirmaciones nunca debe publicarse), pero también puede desempeñar un papel en otras situaciones. Por ejemplo: ¿Se realizó algún trabajo en el código fuera de los horarios de trabajo asignados oficialmente (por ejemplo, durante los fines de semana)? ¿Los tiempos de trabajo revelan que trabajó más del límite legal de su país por horas de trabajo por día? ¿Los horarios de trabajo revelan que no cumplió con los descansos legalmente requeridos? ¿Los tiempos de trabajo delatan que las personas asignadas a otros proyectos hicieron aportes? ¿Los horarios de trabajo proporcionan alguna razón para desconfiar de cualquiera de las afirmaciones que hizo sobre sus horarios de trabajo (por ejemplo, en informes de éxito de proyectos que requerían una asignación detallada de tiempos de trabajo a paquetes de trabajo predefinidos con ciertas asignaciones máximas)? ¿Algo revela que trabajó en situaciones en las que no debería haber estado trabajando (por ejemplo, durante una reunión de proyecto)? ¿Hay algo que delate que usted trabajó en lugares donde no debería haber trabajado (por ejemplo, desde su casa, cuando su contrato no le permite trabajar desde casa, por ejemplo, por complicaciones relacionadas con el seguro)?
  • ¿Hay alguna información secreta en el código , como contraseñas, nombres de cuentas de usuario o direcciones URL que no deben ser conocidas públicamente (porque los servidores no están diseñados para manejar grandes cantidades de usuarios más allá de una pequeña cantidad de personas seleccionadas a las que se les dio la URL para la configuración de prueba personalmente)?
• ¿Alguien más puede usar el código?
  • ¿Se ejecutará el código o requiere grandes esfuerzos de configuración? ¿Puede dedicar el esfuerzo requerido para explicar qué configuración es necesaria?
  • ¿Se puede compilar el código? ¿Ha utilizado compiladores no oficiales modificados o personalizados que no son de acceso público? Si es así, ¿el código agrega algo más allá de lo que ya se puede proporcionar como un algoritmo de pseudocódigo en sus documentos?
  • ¿El código requiere algún recurso externo? ¿El código solo será útil si puede acceder a servidores, bibliotecas o conjuntos de datos que no puede publicar junto con el código por un motivo u otro? ¿Se puede proporcionar al menos una descripción de estos recursos, o sus interfaces están sujetas a algún tipo de NDA?
  • ¿El código realiza cambios irreversibles en los sistemas en los que se ejecuta? Por ejemplo, ¿cambia automáticamente alguna configuración del sistema (como sobrescribir la ruta de búsqueda del sistema)? ¿Realiza algún acceso de bajo nivel a los componentes de hardware que podrían, en ciertas constelaciones (que usted evita internamente en sus configuraciones de prueba) causar daños permanentes a los componentes? ¿Puede advertir de forma fiable a los usuarios del código de tales posibles efectos secundarios no deseados?

Por supuesto. La única forma de mejorar en la escritura de un buen software es obtener comentarios (de todo tipo). Si tienes miedo a la retroalimentación, no llegarás muy lejos. Los tres conceptos básicos para escribir un gran software son práctica, práctica y práctica.

Pasemos ahora a la pregunta de si dañaría su carrera si la gente descubriera que sus habilidades de escritura de software no son de primera categoría. Creo que no, al contrario, te respetarían por tu integridad académica. Y estaría deseando colaborar con usted.

Puede enviarlo a GitHub e intentar mantener un proyecto en caso de que otras personas interesadas en su proyecto puedan acceder fácilmente a su código y tal vez puedan ayudarlo a mejorar su código.

Si deberías. Después de todo, el código fuente del kernel de Linux es un desastre y eso no ha impedido que muchos desarrolladores profesionales lo estudien y contribuyan con parches y adiciones. Recuerde también que el kernel de Linux es la base del sistema operativo que ejecuta las supercomputadoras más rápidas y poderosas y la mayoría de los dispositivos del mundo. PD: Linus Torvalds, el tipo que inventó el kernel de Linux, tiene una carrera muy rentable y exitosa que no se ha visto afectada negativamente ni perjudicada de ninguna manera por el hecho de que el código fuente del kernel de Linux es desordenado.

Una razón por la que nadie ha mencionado por qué debería compartir su código es que puede encontrar a alguien que esté interesado en colaborar con usted, pero que esté preparado para dedicar más tiempo a limpiar el código y hacer que funcione en diferentes sistemas, etc. en hacer el desarrollo innovador que ha hecho.

Mucha gente encuentra este tipo de trabajo muy satisfactorio y si su código es realmente útil para ellos, estarán felices de hacerlo. En cualquier caso, puede encontrar que recibir comentarios de personas que han intentado usarlo, pero que necesitan algún tipo de ayuda, es una buena motivación para hacerlo más fácil de mantener/más fácil de usar y comprender.

Compártelo si quieres, no lo compartas si no quieres. Sé que esto suena sarcástico, pero creo que hoy en día hay demasiada presión para "compartir todo" y la gente intentará hacerte sentir culpable por no compartir, pero en realidad no tienes la obligación de compartir nada.

Definitivamente deberías compartir tu código.

Para ordenar las cosas, haga regiones de las mismas partes del código como hacer una región de un intento fallido y explique por qué falló. Además, si desarrolla en Visual Studio, instale la extensión “CodeMaid” desde Extension Manager y limpie su solución completa. Eliminará espacios y también eliminará referencias no utilizadas haciendo que la mayoría de las cosas se vean mejor.

Si desarrolla en C#, comparta su código conmigo. También puedo ayudarte a arreglar las cosas :)

Publique un descargo de responsabilidad de que el código se proporciona "tal cual" sin promesas de soporte, etc. Y luego comparta el código.

Caso de estudio: Convertir una nube de puntos aislados en una superficie impermeable es un problema práctico extremadamente importante, utilizado en todas partes, desde la robótica hasta la visión por computadora y el procesamiento de datos de sensores 3D como Microsoft Kinect.

La reconstrucción de la superficie de Poisson tiene 7 años y hace tiempo que dejó de ser el estado del arte para resolver este problema. Pero todo el mundo todavía lo usa hasta el día de hoy. ¿Por qué? Porque el autor publicó el código y desde entonces se ha incorporado a un montón de bibliotecas populares de procesamiento de geometría. El documento ahora tiene más de mil citas.

Sí. Debería publicar su código, probablemente bajo la licencia CRAPL. El objetivo es construir un futuro mejor, y su pésimo código ayudará a las personas a lograrlo. Una advertencia es que debe documentar cómo operar con éxito el código lo suficientemente bien como para que alguien tenga una oportunidad decente de reproducir los resultados publicados.

Y, no se preocupe, una parte del código de investigación en el que trabajé fue desarrollado por 5 posdoctorados de capacidad de programación indiferente para una serie de proyectos en el transcurso de aproximadamente 8 años.

La lista de variables globales (solo los nombres) tenía aproximadamente 4 páginas.

Aproximadamente un tercio de ellos se utilizaron para establecer un comportamiento predeterminado para cambiar la funcionalidad que funcionaba en un momento dado. Otro 20% eran estructuras de datos paralelas, lo que significa que almacenaban aproximadamente los mismos datos y, por lo tanto, funciones en el código extraídas de las estructuras de datos más o menos al azar. Sí. A veces no estaban sincronizados. Y a veces necesitaba estar desincronizado.

Había aproximadamente 50 versiones no documentadas, almacenadas en partes aleatorias del servidor del grupo, cada una de las cuales tenía al menos un propósito específico, y solo un administrador mantuvo esos propósitos específicos en su cabeza. Era más común que no tener personas que usaran la versión 'incorrecta' para un propósito determinado.

El uso de procedimientos recursivos increíblemente complejos para, por ejemplo, escribir un archivo, era estándar. En serio: unas pocas miles de líneas para guardar los resultados de la imagen.

Ah, y los restos de un intento fallido de resolver una fuga de memoria (en realidad, una figura invisible) sin crear nunca una nueva variable.

Ah, y la base de datos, esa hermosa base de datos. Aproximadamente la mitad de los datos no se pudieron utilizar debido a (a) errores en el diseño de la base de datos (b) errores en la entrada de datos (en programas automáticos). El código para recuperar archivos de la base de datos tenía varios cientos de líneas de lógica... La base de datos en sí también era lo suficientemente amable como para contener muchas copias de los mismos datos, muchas de ellas con enlaces rotos entre tablas. Restricciones? No. Vi a un estadístico pasar de la inquietud al miedo, a las lágrimas y renunciar al mes de haberle confiado la base de datos...

Había entre 0 y 1 formas de operar el software y obtener resultados correctos en un instante dado...

Y sí, hubo gotos.

Ah, y en un esfuerzo por garantizar un funcionamiento opaco y no determinista, se realizó una serie de cálculos llamando a los botones de la GUI con devoluciones de llamada asociadas.

Aproximadamente el 90 % de cualquier función determinada no era, de manera bastante confiable, relevante para el resultado o para la depuración del resultado; estaba compuesta, más bien, de proyectos a corto plazo insertados y luego nunca eliminados. En serio, escribí una versión completa de características que realmente funcionó y que tenía 1/10 del tamaño... Las fracciones significativas eran funciones insertadas copiadas y pegadas, muchas de las cuales diferían entre sí.

Y, no Virginia, no hay documentación. O nombres de variables descriptivos.

Ah, y las bibliotecas no documentadas, con errores, dlls y asociadas, generadas usando un código que ya no existía.

Todo escrito en Matlab. En términos de prácticas de codificación de Matlab, asuma que el uso abundante de eval sería lo más destacado de su día.

En serio, tu código no es tan malo.

Dicho esto, si ha hecho algo realmente útil, podría mejorar su carrera lanzar una versión limpia para que otras personas usen y citen su biblioteca. Si acaba de hacer algo, entonces la reproducción es probablemente lo más lejos que le recomendamos que vaya.