version control - que - ¿Fomentando buenas prácticas de desarrollo para programadores no profesionales?
cuáles son las buenas prácticas de programación (15)
¿Alguien tiene alguna sugerencia sobre cómo persuadir a las personas cuyo trabajo principal no es programar que beneficie a su comunidad para que sean más abiertos con las herramientas que han construido?
Rendirse. En serio, esto es como enseñar a un cerdo a cantar. (Puedo decir esto porque solía ser físico, así que sé cómo son).
El problema real es que sus colegas son recompensados por la producción científica medida en publicaciones, no en software. Es lo suficientemente difícil en ciencias de la computación para ser reconocido por construir software; En las otras ciencias, es casi imposible.
No puede vender buenas prácticas de desarrollo a sus amigos de biología porque "es bueno para usted". Van a preguntar "¿Debo invertir esfuerzo en aprender sobre buenas prácticas de software, o debo invertir el mismo esfuerzo para publicar otro artículo de biología?" No contestar.
En mi abundante tiempo libre, colaboro con varios científicos (en su mayoría biólogos) que desarrollan software, bases de datos y otras herramientas relacionadas con el trabajo que realizan.
En general, estos proyectos se construyen de forma única, se utilizan en la empresa y, finalmente, alguien decide "oh, esto podría ser útil para otras personas", por lo que lanzan un binario o una interfaz de PHP en él y lo colocan en el web. Sin embargo, normalmente no se les puede molestar en hacer que su código fuente o volcados de sus bases de datos estén disponibles para otros desarrolladores, por lo que en la práctica, estos proyectos generalmente mueren cuando el proyecto para el cual se escribió el código llega a su fin o pierde su financiamiento. Unos meses (o años) más tarde, otro laboratorio necesita el mismo tipo de herramienta, tienen que repetir el trabajo que hizo el primer laboratorio, ese proyecto finalmente muere, formando espuma, enjuagando, repitiendo.
¿Alguien tiene alguna sugerencia sobre cómo persuadir a las personas cuyo trabajo principal no es programar que beneficie a su comunidad para que sean más abiertos con las herramientas que han construido?
De manera similar, cualquier consejo sobre cómo comunicar la idea de que el control de versiones, el seguimiento de errores, la refactorización, las pruebas automatizadas, la integración continua y otras prácticas comunes que los desarrolladores profesionales dan por sentado son buenas ideas en las que vale la pena dedicar tiempo.
Desafortunadamente, muchos científicos parecen tener la opinión de que la programación es un mal aburrido, necesario para el trabajo y que su investigación es mucho más importante, sin darse cuenta de que en estos días, el desarrollo de software es parte de la investigación científica, y si la comunidad Un todo era elevar el nivel de los estándares de desarrollo, todos se beneficiarían.
¿Alguna vez has estado en una situación como esta? ¿Qué te funcionó?
Chris
Estoy de acuerdo con usted hasta cierto punto, pero en mi experiencia, lo que termina sucediendo es que en su afán de publicar terminan con demasiados códigos y métodos de "yo también", que realmente no contribuyen a la calidad de la ciencia. Si se pensara un poco más sobre el código de fuente abierta y alentara a otros a contribuir (sin que necesariamente se eliminen publicaciones), todos se beneficiarían.
Definitivamente de acuerdo en que una separación entre los programadores científicos y los ingenieros de software es algo bueno, especialmente para aplicaciones de producción. Pero incluso para la programación científica, la calidad de mi código habría sido mucho mejor si hubiera seguido las buenas prácticas en ese momento.
Dibujar paralelos con las estadísticas. Las estadísticas son una parte crucial de la investigación científica, y en la que el único consejo sensato es: aprender a hacerlo correctamente o pedirle a un experto que lo haga por usted. Las estadísticas mal hechas pueden socavar completamente un documento, al igual que un código mal escrito puede minar completamente una base de datos pública o un recurso web.
PD: este blog es muy bueno, pero hacer que lo lean será una lucha cuesta arriba: Programación para científicos
En efecto, lo que les está pidiendo que hagan es convertirse en desarrolladores profesionales (con su abundante tiempo libre), además de su profesión elegida. Su renuencia es comprensible.
En mi experiencia, la mejor manera de hacer que la gente programe de manera limpia es mostrar un buen ejemplo cuando trabajas con ellos. por ejemplo: "Nunca paso días sin esperanza depurando mi código porque lo primero que codifico son las pruebas unitarias automatizadas que detectarán problemas cuando sean pequeños y fácilmente detectables" o: "Soy muy malo en rastrear versiones de las cosas, pero a veces mi nuevo código rompe lo que funcionaba antes. Así que uso svn / git / dropbox para hacer un seguimiento de las cosas para mí "
En mi experiencia, ese tipo de afirmación puede aumentar el interés de los "biólogos que aprendieron a escribir". Y si necesita colaborar en un proyecto más grande, deje en claro que tiene más experiencia y que todo irá mejor si las cosas se hacen a su manera.
En cuanto a la publicación del código, la práctica actual es realmente frustrante. Me gustaría ver una nueva revista como Source Code for Biology and Medecine, donde el código se revisa por pares y se puede publicar, pero no tiene costos de publicación (o es muy bajo). De hecho, poner el código en Sourceforge u otros no es "científicamente valioso" porque no aparece en la lista de su publicación, y la mayoría del código no es lo suficientemente revolucionario como para justificar el pago de $ 1,000 por la publicación en el Código fuente para biología y medicina o PLoS One ...
En realidad, pedirle a cualquier equipo de proyecto ocupado que incluya en su calendario el tiempo para hacer que su software sea adecuado para ser adoptado por otro equipo es extremadamente difícil en mi experiencia.
Hacer un trabajo extra para el bien público es una gran pregunta.
He visto un patrón común de "cosecha" después de que el proyecto está completo, lo que refleja que la codificación inmediata para la reutilización tiende a perderse en la urgencia del día.
La única avenida en la que puedo pensar es si la reutilización es dentro de una organización con un presupuesto para un "cazador recolector", alguien cuya razón de estar allí es TI.
Es posible que gane más dinero para cosas como las pruebas unitarias porque tienen un reembolso inmediato para el desarrollo.
No es exactamente simple, pero la demostración con el ejemplo probablemente llevaría el punto a casa de manera más efectiva: encuentre una tarea que el investigador necesita hacer, encuentre a alguien que se haya tomado el tiempo para poner una herramienta con una fuente disponible, y señale cuánto tiempo pasará el investigador. podría ahorrar como resultado debido a tener esa herramienta disponible, y luego señalar que podrían devolverle a la comunidad de la misma manera.
No persuadiría tanto como racionalizaría el proceso. Documéntelo de forma clara, haga tutoriales en video y reúna algún tipo de cadena de herramientas que haga que sea ridículamente fácil configurar los repositorios de origen sin necesidad de que se conviertan en expertos en algo que no es su campo principal.
Para ser el defensor del diablo, ¿es correcto enseñar a los científicos a ser buenos ingenieros de software? El software en investigación suele ser muy específico para el propósito, a veces hasta el punto en el que una parte del código debe ejecutarse con éxito solo una vez en un único conjunto de datos. Los resultados se incorporan a una publicación y se cumple el objetivo. Y existe un alto riesgo de que su técnica o algoritmo sea reemplazado por uno mejor en el corto plazo. Por lo tanto, existe un riesgo real de que se desperdicie el esfuerzo dedicado a producir un código brillante.
Cuando se siente frustrado al atravesar un pantano de código perl mal formado, piense que el código que está viendo es uno de los pocos supervivientes. Se han escrito montañas de dicho código, se han usado varias veces y luego se han descartado para nunca volver a ver la luz del día.
Supongo que solo estoy diciendo que hay un lugar importante en la investigación para el código de prototipo único maloliente y maloliente. Hay buenas razones por las que existe tal código. Puede que no sea bonito, pero si hace el trabajo, ¿a quién le importa? Siempre podemos contratar a un ingeniero de software para escribir la versión lista para producción más tarde, si resulta que está justificada, y dejar que nuestros científicos sigan adelante.
Permítanme comenzar con esto diciendo que soy bioinformático, así que veo las cosas de las que habla todo el tiempo. Hay algo de cierto en el hecho de que muchas de estas personas son biólogos convertidos en codificadores que simplemente no están expuestos a las mejores prácticas.
Dicho esto, el problema principal no es que estas personas no conozcan las buenas prácticas o no les importe. El problema es que no hay ningún incentivo para que pasen más tiempo aprendiendo ingeniería de software, o para limpiar su código y lanzarlo.
En un entorno de investigación académica, su reputación (y, por lo tanto, sus futuras perspectivas de empleo) depende casi totalmente de la cantidad y la calidad de las publicaciones a las que haya contribuido. Las publicaciones sobre métodos o nuevos algoritmos no reciben tanto respeto como las que informan sobre nuevos hallazgos biológicos. Entonces, después de hacer un análisis rápido de un conjunto de datos, tengo pocos incentivos para pasar mucho tiempo limpiando mi código y liberándolo, cuando podría pasar al siguiente conjunto de datos y hacer más descubrimientos biológicos.
También señalaré que la disponibilidad de fondos para el desarrollo computacional es un orden de magnitud menor que la disponible para hacer la biología. En un clima donde solo el 10% de las subvenciones presentadas reciben financiamiento, los científicos no pueden darse el lujo de dedicar tiempo a limpiar y publicar su código, al hacerlo no les ayuda a mantener su laboratorio financiado.
Entonces, hay un problema en pocas palabras. Como bioinformático, creo que es perverso y, a menudo, frustrante.
Dicho esto, hay esperanza para el futuro. En particular, con la secuenciación de segunda y tercera generación, la biología se está moviendo hacia el ámbito del descubrimiento de alto rendimiento, donde la minería de datos y las tuberías computacionales sólidas se convierten en parte integral del éxito de la ciencia. A medida que eso suceda, verá más y más fondos para proyectos computacionales, y más y más ingeniería de software ocurrirá.
Podría hacer que usen un sistema de gestión de contenido, como Joomla. De esa manera solo empujan contenido y no codifican.
Por un lado, ¿podríamos dejar de enseñar a los biólogos Perl? Enseñar prácticamente a los programadores no profesionales un lenguaje de solo escritura garantiza prácticamente un código descartable que no se puede mantener. Python llena el mismo nicho, es tan fácil de aprender (incluso se usa para enseñar a los niños a programar) y es mucho más fácil de leer.
Tal vez encuadrarlo en términos de responsabilidad académica / intelectual ayudaría, hasta cierto punto, compartir su fuente es, en muchos sentidos, como citar correctamente sus fuentes o detallar su metodología de investigación. Se pueden presentar argumentos similares para algunos de los comportamientos de "desarrollador de software profesional" que le gustaría fomentar, aunque creo que liberar el código es probablemente más fácil de vender por estos motivos que otras cosas que podrían requerir mucho más trabajo.
Tome un programador realmente bueno que ya conozca las mejores prácticas, pídale a sus científicos que le enseñen lo que necesitan y lo que hacen, eventualmente el programador tendrá un conocimiento mínimo del dominio (sospecho que toma entre 1 y 3 años dependiendo del dominio) Lo que piden los científicos.
Los desarrolladores siempre aprenden otro dominio de competencia, porque la mayoría de sus programas no son para desarrolladores, por lo que necesitan saber qué hace el "cliente".
Carpintería de software suena como un partido para su solicitud:
Visión de conjunto
Muchos científicos e ingenieros pasan gran parte de sus vidas programando, pero solo unos pocos han aprendido cómo hacerlo bien. Como resultado, pasan su tiempo luchando con el software, en lugar de investigar, pero no tienen idea de cuán confiables o eficientes son sus programas.
Este curso es una introducción intensiva a las prácticas básicas de desarrollo de software para científicos e ingenieros que pueden reducir el tiempo que pasan programando en un 20-25%. Todo el material es de código abierto: puede ser utilizado libremente por cualquier persona con fines educativos o comerciales, y se alienta activamente a los grupos de investigación en el mundo académico y la industria a adaptarlo a sus necesidades.