Habilidades en Datos Bioinformáticos

Capítulo 1. Cómo aprender bioinformática

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: [e-mail]

Ahora mismo, en laboratorios de todo el mundo, las máquinas están secuenciando los genomas de la vida en la Tierra. Incluso con la rápida disminución de los costes y los enormes avances tecnológicos en la secuenciación del genoma, sólo estamos viendo un atisbo de la información biológica contenida en cada célula, tejido, organismo y ecosistema. Sin embargo, la pizca de información biológica total que estamos reuniendo equivale a montañas de datos con los que los biólogos necesitan trabajar. En ningún otro momento de la historia de la humanidad nuestra capacidad para comprender las complejidades de la vida ha dependido tanto de nuestras habilidades para trabajar con datos y analizarlos.

Este libro trata sobre el aprendizaje de la bioinformática mediante el desarrollo de habilidades de datos. En este capítulo veremos qué son las habilidades con los datos y por qué aprender habilidades con los datos es la mejor forma de aprender bioinformática. También veremos qué implica una investigación robusta y reproducible.

¿Por qué Bioinformática? Los crecientes datos de la biología

Los bioinformáticos se ocupan de obtener conocimientos biológicos a partir de grandes cantidades de datos con habilidades y herramientas especializadas. Al principio de la historia de la biología, los conjuntos de datos eran pequeños y manejables. La mayoría de los biólogos podían analizar sus propios datos tras realizar un curso de estadística, utilizando Microsoft Excel en un ordenador personal de sobremesa. Sin embargo, todo esto está cambiando rápidamente. Los grandes conjuntos de datos de secuenciación están muy extendidos, y sólo serán más comunes en el futuro. Para analizar estos datos se necesitan herramientas diferentes, nuevas habilidades y muchos ordenadores con grandes cantidades de memoria, capacidad de procesamiento y espacio en disco.

En un periodo de tiempo relativamente corto, los costes de la secuenciación se redujeron drásticamente, lo que permitió a los investigadores utilizar los datos de la secuenciación para ayudar a responder importantes preguntas biológicas. La primera secuenciación era de bajo rendimiento y costosa. Los esfuerzos de secuenciación del genoma completo eran caros (el genoma humano costó unos 2.700 millones de dólares) y sólo eran posibles mediante grandes esfuerzos de colaboración. Desde la publicación del genoma humano, los costes de secuenciación han disminuido exponencialmente hasta aproximadamente 2008, como se muestra en la Figura 1-1. Con la introducción de las tecnologías de secuenciación de nueva generación, el coste de secuenciar un megabase de ADN disminuyó aún más rápidamente. En este momento crucial, una tecnología que sólo era asequible para los grandes esfuerzos de secuenciación colaborativa (o para investigadores individuales con bolsillos muy llenos) pasó a ser asequible para los investigadores de toda la biología. Es probable que estés leyendo este libro para aprender a trabajar con datos de secuenciación que hace menos de 10 años habrían sido demasiado caros de generar.

Figura 1-1. Caída de los costes de secuenciación (obsérvese que el eje y está en una escala logarítmica); la brusca caída en torno a 2008 se debió a la introducción de los datos de secuenciación de nueva generación. (figura reproducida y datos descargados de los NIH)

¿Cuál fue la consecuencia de este descenso de los costes de secuenciación debido a estas nuevas tecnologías? Como habrás adivinado, montones y montones de datos. Las bases de datos biológicos se han hinchado de datos tras un crecimiento exponencial. Mientras que antes bastaban pequeñas bases de datos compartidas entre colaboradores, ahora hay petabytes de datos útiles en servidores de todo el mundo. Los conocimientos clave sobre cuestiones biológicas se almacenan no sólo en los datos experimentales sin analizar que reposan en tu disco duro, sino también girando alrededor de un disco en un centro de datos a miles de kilómetros de distancia.

El crecimiento de las bases de datos biológicas es tan asombroso como la caída de los costes de secuenciación. Como ejemplo, consideremos el Archivo de Lecturas de Secuencias (anteriormente conocido como Archivo de Lecturas Cortas ), un repositorio de los datos de secuenciación en bruto de los experimentos de secuenciación. Desde 2010, ha experimentado un crecimiento notable; véase la Figura 1-2.

Para poner en contexto este increíble crecimiento de los datos de secuenciación, considera la Ley de Moore. Gordon Moore (cofundador de Intel) observó que el número de transistores en los chips informáticos se duplica aproximadamente cada dos años. Más transistores por chip se traduce en velocidades más rápidas en los procesadores informáticos y más memoria de acceso aleatorio en los ordenadores, lo que da lugar a ordenadores más potentes. Este extraordinario ritmo de mejora tecnológica -la duplicación del rendimiento cada dos años- es probablemente el crecimiento más rápido de la tecnología que la humanidad haya visto jamás. Sin embargo, desde 2011, la cantidad de datos de secuenciación almacenados en el Archivo de Lectura Corta ha superado incluso este increíble crecimiento, habiéndose duplicado cada año.

Para complicar aún más las cosas, continuamente se crean nuevas herramientas para analizar datos biológicos, y sus algoritmos subyacentes avanzan. Una revisión de 2012 enumeraba más de 70 mapeadores de hilos cortos (Fonseca et al., 2012; véasehttp://bit.ly/hts-mappers). Del mismo modo, nuestro enfoque del ensamblaje del genoma ha cambiado considerablemente en los últimos cinco años, ya que los métodos para ensamblar secuencias largas (como los algoritmos de solapamiento-disposición-consenso) se abandonaron con la aparición de las lecturas cortas de secuenciación de alto rendimiento. Ahora, los avances en la química de la secuenciación están dando lugar a longitudes de lectura de secuenciación más largas y nuevos algoritmos están sustituyendo a otros que sólo tenían unos pocos años.

Por desgracia, esta abundancia y rápido desarrollo de herramientas bioinformáticas tiene graves inconvenientes. A menudo, las herramientas bioinformáticas no se evalúan adecuadamente, o si lo están, sólo se evalúan en un organismo. Esto dificulta a los nuevos biólogos encontrar y elegir la mejor herramienta para analizar sus datos. Para complicar aún más las cosas, algunos programas bioinformáticos no se desarrollan activamente, por lo que pierden relevancia o acarrean errores que podrían afectar negativamente a los resultados. Todo esto dificulta la elección de un programa bioinformático adecuado en tu propia investigación. Y lo que es más importante, es imprescindible evaluar críticamente los resultados de los programas bioinformáticos ejecutados con tus propios datos. Veremos ejemplos de cómo los conocimientos sobre datos pueden ayudarnos a evaluar el resultado de los programas a lo largo de la Parte II.

Figura 1-2. Crecimiento exponencial del Archivo de Lecturas Cortas; las bases de acceso abierto son envíos del SRA disponibles para el público (figura reproducida y datos descargados de los NIH).

Aprender habilidades de datos para aprender bioinformática

Con la naturaleza de los datos biológicos cambiando tan rápidamente, ¿cómo se supone que vas a aprender bioinformática? Con todas las herramientas que existen y las que se crean continuamente, ¿cómo se supone que un biólogo debe saber si un programa funcionará adecuadamente con los datos de su organismo?

La solución es abordar la bioinformática como lo hace un bioinformático: probar cosas y evaluar los resultados. De este modo, la bioinformática consiste simplemente en tener las habilidades necesarias para experimentar con datos utilizando un ordenador y comprender sus resultados. La parte experimental es fácil; esto resulta natural para la mayoría de los científicos. El factor limitante para la mayoría de los biólogos es tener las habilidades necesarias para experimentar libremente y trabajar con grandes datos en un ordenador. El objetivo de este libro es enseñarte las habilidades bioinformáticas de datos necesarias para que puedas experimentar con datos en un ordenador con la misma facilidad con la que realizarías experimentos en el laboratorio.

Por desgracia, muchas de las herramientas informáticas habituales del biólogo no pueden adaptarse al tamaño y la complejidad de los datos biológicos modernos. Los formatos de datos complejos, la interconexión de numerosos programas y la evaluación del software y los datos dificultan el trabajo con grandes conjuntos de datos bioinformáticos. Aprender los conocimientos básicos sobre datos bioinformáticos te dará la base para aprender, aplicar y evaluar cualquier programa bioinformático o método de análisis. Dentro de 10 años, puede que los bioinformáticos sólo utilicemos algunos de los programas de software bioinformático actuales. Pero lo más seguro es que utilicemos las habilidades de datos y la experimentación para evaluar los datos y métodos del futuro.

¿Qué son las habilidades de datos? Son el conjunto de habilidades informáticas que te dan la capacidad de improvisar rápidamente una forma de ver conjuntos de datos complejos, utilizando un conjunto bien conocido de herramientas. Una buena analogía es lo que los músicos de jazz llaman tener "chuletas". Un músico de jazz con buenas "chuletas" puede entrar en una discoteca, oír que tocan una canción estándar conocida, reconocer los cambios de acordes y empezar a tocar ideas musicales sobre esos acordes. Del mismo modo, un bioinformático con buenos conocimientos de datos puede recibir un enorme conjunto de datos de secuenciación y empezar inmediatamente a utilizar un conjunto de herramientas para ver qué historia cuentan los datos.

Al igual que un músico de jazz que domina su instrumento, un bioinformático con excelentes habilidades para los datos domina un conjunto de herramientas. Aprender las propias herramientas es un paso necesario, pero no suficiente, para desarrollar habilidades con los datos (del mismo modo, aprender un instrumento es un paso necesario, pero no suficiente, para tocar ideas musicales). A lo largo del libro, desarrollaremos nuestras habilidades con los datos, desde la creación de un proyecto bioinformático y sus datos en la Parte II, hasta el aprendizaje de pequeñas y grandes herramientas para el análisis de datos en la Parte III. Sin embargo, este libro sólo puede ponerte en el camino correcto; el verdadero dominio requiere aprender aplicando repetidamente las habilidades a problemas reales.

Nuevos retos para una investigación reproducible y robusta

El creciente uso en biología de grandes conjuntos de datos de secuenciación está cambiando algo más que las herramientas y habilidades que necesitamos: también está cambiando el grado de reproducibilidad y solidez de nuestros hallazgos científicos. A medida que utilizamos nuevas herramientas y habilidades para analizar los datos genómicos, es necesario garantizar que nuestros enfoques sigan siendo tan reproducibles y sólidos como cualquier otro enfoque experimental. Por desgracia, el tamaño de nuestros datos y la complejidad de nuestros flujos de trabajo de análisis hacen que este objetivo sea especialmente difícil en genómica.

El requisito de la reproducibilidad es que compartamos nuestros datos y métodos. En la era pregenómica, esto era mucho más fácil. Los artículos podían incluir resúmenes detallados de los métodos y conjuntos de datos completos, exactamente como hizo el artículo de Kreitman de 1986 con una secuencia de flanqueo del gen Adh de 4.713 pb (estaba incrustada en medio del artículo). Ahora los artículos incluyen métodos, código y datos suplementarios. Compartir datos tampoco es ya trivial, ya que los proyectos de secuenciación pueden incluir terabytes de datos complementarios. Los genomas de referencia y los conjuntos de datos de anotación utilizados en los análisis se actualizan constantemente, lo que puede dificultar la reproducibilidad. Los enlaces a materiales complementarios, métodos y datos en los sitios web de las revistas se rompen, los materiales de los sitios web de las facultades desaparecen cuando los miembros de las facultades se trasladan o actualizan sus sitios, y los proyectos de software se quedan obsoletos cuando los desarrolladores se marchan y no actualizan el código. A lo largo de este libro, veremos qué se puede hacer para mejorar la reproducibilidad de tu proyecto junto con el análisis propiamente dicho, ya que creo que son actividades necesariamente complementarias.

Además, la complejidad de los análisis bioinformáticos puede hacer que los resultados sean susceptibles de errores y confusiones técnicas. Incluso los proyectos genómicos bastante rutinarios pueden utilizar docenas de programas diferentes, complicadas combinaciones de parámetros de entrada y muchos conjuntos de datos de muestras y anotaciones; además, el trabajo puede estar repartido entre servidores y estaciones de trabajo. Todos estos pasos computacionales de procesamiento de datos crean resultados que se utilizan en análisis de nivel superior en los que extraemos nuestras conclusiones biológicas. El resultado final es que los resultados de la investigación pueden descansar sobre un andamiaje raquítico de numerosos pasos de procesamiento. Para empeorar las cosas, los flujos de trabajo y los análisis bioinformáticos normalmente sólo se ejecutan una vez para producir resultados para una publicación, y luego nunca se vuelven a ejecutar o probar. Estos análisis pueden depender de versiones muy específicas de todo el software utilizado, lo que puede dificultar su reproducción en un sistema diferente. En el aprendizaje de habilidades bioinformáticas de datos, es necesario aprender simultáneamente la reproducibilidad y las buenas prácticas de robustez. Veamos sucesivamente la reproducibilidad y la robustez.

Investigación reproducible

Reproducir los descubrimientos científicos es la única forma de confirmar que son exactos y no el artefacto de un único experimento o del análisis de . Karl Popper, en La lógica del descubrimiento científico, dijo célebremente: "los sucesos únicos no reproducibles carecen de importancia para la ciencia" (1959). La replicación independiente de experimentos y análisis es la regla de oro con la que evaluamos la validez de los descubrimientos científicos. Por desgracia, la mayoría de los experimentos de secuenciación son demasiado caros para reproducirlos a partir del tubo de ensayo, por lo que cada vez confiamos más únicamente en la reproducibilidad in silico. La complejidad de los proyectos bioinformáticos suele desalentar la replicación, por lo que es nuestro trabajo como buenos científicos facilitar y fomentar la reproducibilidad in silico haciéndola más fácil. Como veremos más adelante, adoptar buenas prácticas de reproducibilidad también puede facilitarte la vida como investigador.

Entonces, ¿qué es un proyecto bioinformático reproducible? Como mínimo, es compartir el código y los datos de tu proyecto. La mayoría de las revistas y organismos de financiación exigen que compartas los datos de tu proyecto, y para ello existen recursos como el Archivo de Lecturas de Secuencias del NCBI. Ahora bien, los editores y revisores a menudo sugerirán (o en algunos casos exigirán) que también se comparta el código de un proyecto, especialmente si el código es una parte importante de los resultados de un estudio. Sin embargo, podemos y debemos hacer mucho más para garantizar la reproducibilidad de nuestros proyectos. Al tener que reproducir análisis bioinformáticos para verificar resultados, he aprendido de estos ejercicios de investigación que el diablo está en los detalles.

Por ejemplo, una vez unos colegas y yo tuvimos dificultades para reproducir un análisis de expresión diferencial de ARN-seq que habíamos realizado nosotros mismos. Teníamos resultados preliminares de un análisis sobre un subconjunto de muestras realizado unas semanas antes, pero para nuestra sorpresa, nuestro análisis actual producía un conjunto drásticamente menor de genes expresados diferencialmente. Tras volver a comprobar cómo se crearon nuestros resultados anteriores, comparar las versiones de los datos y los tiempos de creación de los archivos, y examinar las diferencias en el código del análisis, seguíamos perplejos: nada podía explicar la diferencia entre los resultados. Finalmente, comprobamos la versión de nuestro paquete R y nos dimos cuenta de que se había actualizado en nuestro servidor. Volvimos a instalar la versión antigua para confirmar que ése era el origen de la diferencia, y efectivamente lo era. La lección aquí es que a menudo la replicación, ya sea por ti en el futuro o por otra persona, se basa no sólo en los datos y el código, sino en detalles como las versiones del software y cuándo se descargaron los datos y qué versión es. Estos metadatos, o datos sobre los datos, son un detalle crucial para garantizar la reproducibilidad.

Otro caso de estudio motivador sobre la reproducibilidad de la bioinformática es la llamada "Saga de Duke". El Dr. Anil Potti y otros investigadores de la Universidad de Duke crearon un método que utilizaba datos de expresión de microarrays de alto rendimiento para detectar y predecir la respuesta a distintos fármacos de quimioterapia. Estos métodos eran el principio de un nuevo nivel de medicina personalizada, y se estaban utilizando para determinar los tratamientos de quimioterapia para pacientes en ensayos clínicos. Sin embargo, dos bioestadísticos, Keith Baggerly y Kevin Coombes, encontraron graves fallos en el análisis de este estudio al intentar reproducirlo (Baggerly y Coombes, 2009). Muchos de ellos requirieron lo que Baggerly y Coombes denominaron "bioinformática forense", es decir, la búsqueda para intentar reproducir las conclusiones de un estudio cuando no existe documentación suficiente para seguir cada paso. En total, Baggerly y Coombes encontraron múltiples errores graves, entre ellos

• Un error de uno en uno, ya que toda una lista de valores de expresión génica se desplazó hacia abajo en relación con su identificador correcto

• Dos genes atípicos de interés biológico no estaban en los microarrays utilizados

• Hubo confusión del tratamiento con el día en que se realizó la micromatriz

• Se confundieron los nombres de los grupos de muestra

El trabajo de Baggerly y Coombes se resume mejor en su artículo de acceso abierto "Deriving Chemosensitivity from Cell Lines: Forensic Bioinformatics and Reproducible Research in High-Throughput Biology" (consulta el directorio GitHub de este capítulo para ver este artículo y más información sobre la Saga Duke). La lección del trabajo de Baggerly y Coombes es que "los errores comunes son simples, y los errores simples son comunes" y una documentación deficiente puede conducir tanto a errores como a la irreproducibilidad. La documentación de los métodos, las versiones de los datos y el código no sólo habría facilitado la reproducibilidad, sino que probablemente habría evitado algunos de estos errores graves en su estudio. Esforzarte por conseguir la máxima reproducibilidad en tu proyecto a menudo también hará que tu trabajo sea más sólido.

La investigación robusta y la regla de oro de la bioinformática

Como el ordenador es una herramienta lo suficientemente afilada como para ser realmente útil, puedes cortarte con él.

Las habilidades técnicas de la estadística (1964)John Tukey

En biología de laboratorio húmedo, cuando los experimentos fallan, puede ser muy evidente, pero esto no siempre es así en informática. Los geles de electroforesis que parecen manchas de Rorschach en lugar de bandas ordenadas indican claramente que algo ha ido mal. En la informática científica, los errores pueden ser silenciosos; es decir, el código y los programas pueden producir una salida (en lugar de detenerse con un error), pero esta salida puede ser incorrecta. Esta es una noción muy importante que debes tener en mente mientras aprendes bioinformática.

Además, en la informática científica es habitual que el código sólo se ejecute una vez, ya que los investigadores obtienen el resultado deseado y pasan al siguiente paso. Por el contrario, considera un videojuego: se ejecuta en miles (si no millones) de máquinas diferentes y, de hecho, está siendo probado constantemente por muchos usuarios. Si se produce un error que borre la puntuación de un usuario, es excepcionalmente probable que los usuarios lo detecten rápidamente y lo notifiquen. Por desgracia, no ocurre lo mismo con la mayoría de los proyectos bioinformáticos.

Los datos genómicos también crean sus propios retos para una investigación sólida. En primer lugar, la mayoría de los análisis bioinformáticos producen resultados intermedios que son demasiado grandes y de alta dimensión para inspeccionarlos o visualizarlos fácilmente. La mayoría de los análisis también implican múltiples pasos, por lo que incluso si fuera factible inspeccionar todo un conjunto de datos intermedios en busca de problemas, sería difícil hacerlo para cada paso (por lo tanto, normalmente recurrimos a inspeccionar muestras de los datos, o a mirar las estadísticas de resumen de los datos). En segundo lugar, en biología de laboratorio húmedo, suele ser más fácil formarse expectativas previas sobre cuál podría ser el resultado de un experimento. Por ejemplo, un investigador puede esperar ver un determinado ARNm expresado en algunos tejidos en menor abundancia que un gen de mantenimiento particular. Con estas expectativas previas, un resultado aberrante puede atribuirse a un ensayo fallido y no a la biología. En cambio, la elevada dimensionalidad de la mayoría de los resultados genómicos hace casi imposible formar expectativas previas sólidas. Formar expectativas previas específicas sobre la expresión de cada una de las decenas de miles de genes ensayados por un experimento de ARN-seq es poco práctico. Por desgracia, sin expectativas previas, puede ser bastante difícil distinguir los buenos resultados de los malos.

Los bioinformáticos también tienen que tener cuidado de que los programas bioinformáticos, incluso las grandes herramientas validadas por la comunidad, como alineadores y ensambladores, no funcionen bien en su organismo concreto. Todos los organismos son maravillosa y extrañamente diferentes, y sus genomas también lo son. Muchas herramientas bioinformáticas están probadas en unos pocos organismos diploides modelo como el humano, y menos probadas en los genomas complejos de las demás partes del árbol de la vida. ¿Esperamos realmente que los parámetros listos para usar de un alineador de lectura corta ajustado a los datos humanos funcionen en un genoma poliploide cuatro veces más grande? Probablemente no.

La forma más fácil de asegurarse de que todo funciona correctamente es adoptar una actitud cautelosa, y comprobarlo todo entre los pasos computacionales. Además, debes acercarte a los datos biológicos (ya sean de un experimento o de una base de datos) con un sano escepticismo de que pueda haber algo mal en ellos. En la comunidad informática, esto está relacionado con el concepto de "basura dentro, basura fuera": un análisis es tan bueno como los datos que contiene. En la enseñanza de la bioinformática, a menudo comparto esta idea como la Regla de Oro de la Bioinformática:

Nunca jamás confíes en tus herramientas (o datos)

No se trata de que te vuelvas paranoico pensando que no se puede confiar en nada de la bioinformática, ni de que debas probar todos los programas y parámetros disponibles con tus datos. Se trata más bien de enseñarte a adoptar la misma actitud cautelosa que los ingenieros de software y los bioinformáticos han aprendido por las malas. Simplemente comprobar los datos de entrada y los resultados intermedios, realizar comprobaciones rápidas de cordura, mantener los controles adecuados y probar los programas es un gran comienzo. Esto también te ahorra encontrarte con errores más adelante, cuando solucionarlos signifique rehacer grandes cantidades de trabajo. De forma natural, compruebas si las técnicas de laboratorio funcionan y dan resultados coherentes; adoptar un enfoque robusto en bioinformática no es más que hacer lo mismo en los análisis bioinformáticos.

Adoptar prácticas sólidas y reproducibles también hará tu vida más fácil

Trabajar en ciencias nos ha enseñado a muchos de nosotros algunos hechos de la vida por las malas. Son como la ley de Murphy: todo lo que puede salir mal, saldrá mal. La bioinformática tiene su propio conjunto de leyes como ésta. Habiendo trabajado en este campo y discutido historias de guerra con otros bioinformáticos, prácticamente puedo garantizar que ocurrirá lo siguiente:

• Es casi seguro que tendrás que volver a ejecutar un análisis más de una vez, posiblemente con datos nuevos o modificados. A menudo esto ocurre porque encuentras un error, un colaborador añade o actualiza un archivo, o quieres probar algo nuevo antes de un paso. En todos los casos, los análisis posteriores dependen de estos resultados anteriores, lo que significa que hay que volver a ejecutar todos los pasos de un análisis.

• En el futuro, es casi seguro que tú (o tus colaboradores, o tu asesor) tendréis que volver a revisar parte de un proyecto y os parecerá completamente críptico. Tu única defensa es documentar cada paso. Si no anotas los hechos clave (por ejemplo, de dónde descargaste los datos, cuándo los descargaste y qué pasos ejecutaste), seguramente los olvidarás. Documentar tu trabajo computacional equivale a llevar un cuaderno de laboratorio detallado: una parte absolutamente crucial de la ciencia.

Por suerte, adoptar prácticas que hagan que tu proyecto sea reproducible también ayuda a resolver estos problemas. En este sentido, las buenas prácticas en bioinformática (y en informática científica en general) tanto facilitan la vida como conducen a proyectos reproducibles. La razón es sencilla: si cada paso de tu proyecto está diseñado para volver a ejecutarse (posiblemente con datos diferentes) y está bien documentado, ya está bien encaminado para ser reproducible.

Por ejemplo, si automatizamos las tareas con un guión y hacemos un seguimiento de todos los datos de entrada y las versiones del software, los análisis se pueden volver a ejecutar con sólo pulsar una tecla. Reproducir todos los pasos de este guión es mucho más fácil, ya que un guión bien escrito documenta de forma natural un flujo de trabajo (hablaremos más de esto en el Capítulo 12). Este enfoque también te ahorra tiempo: si recibes datos nuevos o actualizados, todo lo que tienes que hacer es volver a ejecutar el guión con el nuevo archivo de entrada. Esto no es difícil de hacer en la práctica; los scripts no son difíciles de escribir y los ordenadores destacan en la realización de tareas repetitivas enumeradas en un script.

Recomendaciones para una investigación sólida

La investigación robusta consiste en gran medida en adoptar un conjunto de prácticas que apilen las probabilidades a tu favor de que un error silencioso no confunda tus resultados. Como ya se ha mencionado, la mayoría de estas prácticas también son beneficiosas por motivos distintos a la prevención del temido error silencioso, razón de más para incluir la aplicación de las siguientes recomendaciones en tu trabajo bioinformático diario.

Presta atención al diseño experimental

Una investigación sólida comienza con un buen diseño experimental. Por desgracia, ningún análisis brillante puede salvar un experimento con un mal diseño. Citando a un brillante estadístico y genetista:

Consultar al estadístico una vez finalizado un experimento suele ser simplemente pedirle que realice un examen post mortem. Quizás pueda decir de qué murió el experimento.

R.A. Fisher

Esta cita me toca muy de cerca; he visto proyectos aterrizar en mi mesa listos para el análisis, después de haber gastado miles de dólares en secuenciación, y sin embargo han quedado completamente muertos al llegar. Un buen diseño experimental no tiene por qué ser difícil, pero como se trata fundamentalmente de un tema estadístico, queda fuera del alcance de este libro. Menciono este tema porque, por desgracia, nada más en este libro puede salvar un experimento con un mal diseño. Es especialmente necesario pensar en el diseño experimental en los estudios de alto rendimiento, ya que los "efectos de lote" técnicos pueden confundir significativamente los estudios (para una perspectiva sobre esto, véase Leek et al., 2010).

La mayoría de los cursos y libros de introducción a la estadística tratan temas básicos de diseño experimental. Diseño experimental y análisis de datos para biólogos, de Quinn y Keough (Cambridge University Press, 2002), es un libro excelente sobre este tema. El capítulo 18 de Statistics in a Nutshell, 2ª edición, de O'Reilly, por Sarah Boslaugh, también cubre bien los aspectos básicos. Ten en cuenta, sin embargo, que el diseño experimental en un experimento genómico es una bestia diferente, y se investiga y mejora activamente. La mejor manera de asegurarte de que tu experimento multimillonario va a alcanzar su potencial es ver cuáles son las buenas prácticas actuales de diseño para tu proyecto concreto. También es una buena idea consultar a tu estadístico local amigo sobre cualquier duda o inquietud de diseño experimental que puedas tener al planificar un experimento.

Escribir código para humanos, escribir datos para ordenadores

Depurar es el doble de difícil que escribir el código en primer lugar. Por lo tanto, si escribes el código de la forma más inteligente posible, por definición no eres lo suficientemente inteligente como para depurarlo.

Brian Kernighan

Los proyectos bioinformáticos pueden implicar montañas de código, y una de nuestras mejores defensas contra los errores es escribir código para humanos, no para ordenadores (un punto tratado en el excelente artículo de Wilson et al., 2012). Los humanos son los que depuran, así que escribir código sencillo y claro facilita la depuración.

El código debe ser legible, estar dividido en pequeños componentes contenidos en (modular), y ser reutilizable (para que no estés reescribiendo código para hacer las mismas tareas una y otra vez). Estas prácticas son cruciales en el mundo del software, y deberían aplicarse también en tu trabajo bioinformático. Comentar el código y adoptar una guía de estilo son formas sencillas de aumentar la legibilidad del código. Google tieneguías de estilo públicas para muchos idiomas, que sirven como excelentes plantillas. ¿Por qué es tan importante la legibilidad del código? En primer lugar, un código legible hace que los proyectos sean más reproducibles, ya que otros pueden entender más fácilmente lo que hacen los scripts y cómo funcionan. En segundo lugar, es mucho más fácil encontrar y corregir errores de software en un código legible y bien comentado que en un código desordenado. En tercer lugar, revisar el código en el futuro siempre es más fácil cuando el código está bien comentado y escrito con claridad. Escribir código modular y reutilizable sólo requiere práctica: veremos algunos ejemplos de ello a lo largo del libro.

A diferencia del código, los datos deben formatearse de manera que se facilite su legibilidad informática. Con demasiada frecuencia, los seres humanos registramos los datos de una forma que maximiza su legibilidad para nosotros, pero que requiere una cantidad considerable de limpieza y orden antes de que puedan ser procesados por un ordenador. Cuantos más datos (y metadatos) sean legibles por ordenador, más podremos aprovechar nuestros ordenadores para trabajar con esos datos.

Deja que tu ordenador haga el trabajo por ti

Los humanos que realizan actividades de memoria tienden a cometer muchos errores. Una de las formas más sencillas de hacer que tu trabajo sea más robusto es hacer que tu ordenador realice la mayor parte posible de este trabajo rutinario. Este enfoque de automatizar tareas es más robusto porque disminuye las probabilidades de que cometas un error trivial, como omitir accidentalmente un archivo o nombrar incorrectamente la salida.

Por ejemplo, ejecutar un programa en 20 archivos diferentes tecleando individualmente (o copiando y pegando) cada comando es frágil: las probabilidades de cometer un error por descuido aumentan con cada archivo que procesas. En el trabajo bioinformático, es bueno desarrollar el hábito de dejar que tu ordenador haga este tipo de trabajo repetitivo por ti. En lugar de pegar el mismo comando 20 veces y limitarte a cambiar los archivos de entrada y salida, escribe un script que lo haga por ti. Esto no sólo es más fácil y es menos probable que provoque errores, sino que también aumenta la reproducibilidad, ya que tu script sirve como referencia de lo que hiciste en cada uno de esos archivos.

Aprovechar las ventajas de automatizar tareas requiere pensar un poco en la organización de tus proyectos, datos y código. Hábitos sencillos como nombrar los archivos de datos de una forma coherente que un ordenador (y no sólo los humanos) pueda entender, pueden facilitar enormemente la automatización de tareas y hacer el trabajo mucho más fácil. Veremos ejemplos de esto en el Capítulo 2.

Haz afirmaciones y habla alto, en el código y en tus métodos

Cuando escribimos código, tendemos a tener suposiciones implícitas sobre nuestros datos. Por ejemplo, esperamos que sólo haya tres opciones de cadenas de ADN (directa, inversa y desconocida), que la posición inicial de un gen sea menor que la posición final y que no podamos tener posiciones negativas. Estas suposiciones implícitas que hacemos sobre los datos influyen en cómo escribimos el código; por ejemplo, puede que no se nos ocurra manejar una determinada situación en el código si suponemos que no va a ocurrir. Desgraciadamente, esto puede conducir al temido error silencioso: nuestro código o programas reciben valores fuera de nuestros valores esperados, se comportan incorrectamente, y aún así devuelven la salida sin avisar. Nuestro mejor enfoque para evitar este tipo de error es declarar y probarexplícitamente nuestras suposiciones sobre los datos en nuestro código utilizando declaraciones de aserción como assert() de Python y stopifnot() de R.

Casi todos los lenguajes de programación tienen su propia versión de la función assert. Estas funciones assert operan de forma similar: si la declaración evaluada es falsa, la función assert detendrá el programa y lanzará un error. Puede que sean sencillas, pero estas funciones assert son indispensables en la investigación robusta. Al principio de mi carrera, un mentor me motivó para que adoptara el hábito de utilizar las funciones assert con bastante liberalidad -incluso cuando parece que no hay absolutamente ninguna posibilidad de que la afirmación sea falsa- y, sin embargo, no dejo de sorprenderme de cuántas veces éstas han detectado un error sutil. En bioinformática (y en todos los campos), es crucial que hagamos todo lo posible por convertir los temidos errores silenciosos en errores ruidosos.

Prueba el código, o mejor aún, deja que el código pruebe el código

Los ingenieros de software son un grupo inteligente, y llevan la idea de dejar que el ordenador haga el trabajo a nuevos niveles. Una forma que tienen de hacerlo es hacer que el código pruebe otro código, en lugar de hacerlo a mano. Un método habitual para probar código se llama prueba unitaria. En las pruebas unitarias, dividimos nuestro código en unidades modulares individuales (lo que también tiene el efecto secundario de mejorar la legibilidad) y escribimos código adicional que prueba este código. En la práctica, esto significa que si tenemos una función llamada add(), escribimos una función adicional (normalmente en un archivo aparte) llamada test_add(). Esta función test_add() llamaría a la función add()con cierta entrada, y comprobaría que la salida es la esperada. En Python, puede tener este aspecto:

EPS = 0.00001 # a small number to use when comparing floating-point values

def add(x, y):
    """Add two things together."""
    return x + y

def test_add():
    """Test that the add() function works for a variety of numeric types."""
    assert(add(2, 3) == 5)
    assert(add(-2, 3) == 1)
    assert(add(-1, -1) == -2)
    assert(abs(add(2.4, 0.1) - 2.5) < EPS)

La última línea de la función test_add() parece más complicada que las demás porque está comparando valores en coma flotante. Es difícil comparar valores de coma flotante en un ordenador, ya que hay errores de representación y de redondeo. Sin embargo, es un buen recordatorio de que siempre estamos limitados por lo que puede hacer nuestra máquina, y debemos tener en cuenta estas limitaciones en el análisis.

Las pruebas unitarias se utilizan mucho menos en la codificación científica que en la industria del software, a pesar de que es más probable que el código científico contenga errores (porque nuestro código suele ejecutarse una sola vez para generar resultados para una publicación, y muchos errores en el código científico son silenciosos). Me refiero a esto comola paradoja de la codificación científica: la naturaleza propensa a los errores de la codificación científica significa que deberíamos utilizar las pruebas tanto o más que la industria del software, pero en realidad hacemos muchas menos pruebas (si es que hacemos alguna). Esto es lamentable, ya que hoy en día muchas conclusiones científicas son el resultado de montañas de código.

Aunque probar el código es la mejor manera de encontrar, corregir y prevenir errores de software, probar no es barato. Probar el código hace que nuestros resultados sean robustos, pero también requiere una cantidad considerable de nuestro tiempo. Por desgracia, a los investigadores les llevaría demasiado tiempo componer pruebas unitarias para cada fragmento de código que escriben. La ciencia avanza deprisa, y en el tiempo que tardarías en escribir y realizar pruebas unitarias, tu investigación podría quedar desfasada o ser noticia. Una estrategia más sensata es considerar tres variables importantes cada vez que escribas un trozo de código:

• ¿Cuántas veces es llamado este código por otro código?

• Si este código fuera erróneo, ¿en qué medida perjudicaría a los resultados finales?

• ¿Cómo de perceptible sería un error si se produjera?

La importancia de probar un trozo de código es proporcional a las dos primeras variables, e inversamente proporcional a la tercera (es decir, si un fallo es muy notable, hay menos motivos para escribir una prueba para él). Emplearemos esta estrategia a lo largo de los ejemplos del libro.

Utilizar las bibliotecas existentes siempre que sea posible

Hay un punto de inflexión en la carrera de todo programador en ciernes cuando se siente lo suficientemente cómodo escribiendo código y piensa: "Oye, ¿por qué iba a utilizar una biblioteca para esto, podría escribirlo yo mismo fácilmente?". Es una sensación fortalecedora, pero hay buenas razones para utilizar en su lugar una biblioteca de software existente.

Las bibliotecas de código abierto existentes tienen dos ventajas sobre las bibliotecas que escribes tú mismo: una historia más larga y un público más amplio. Ambas ventajas se traducen en menos errores. Los errores en el software son similares al proverbial problema de encontrar una aguja en un pajar. Si escribes tu propia biblioteca de software (donde seguro que acechan unos cuantos fallos), eres una sola persona buscando unas cuantas agujas. En cambio, en las bibliotecas de software de código abierto, en esencia, hay muchas más personas buscando esas agujas durante mucho más tiempo. En consecuencia, es más probable que se encuentren, notifiquen y corrijan errores en estas bibliotecas de código abierto que en tus propias versiones caseras.

Un buen ejemplo de ello es un problema potencialmente sutil que surge al escribir un script para traducir nucleótidos a proteínas. La mayoría de los biólogos con cierta experiencia en programación podrían escribir fácilmente un script para realizar esta tarea. Pero detrás de estos sencillos ejercicios de programación se esconde una complejidad oculta que tal vez tú solo no consideres. ¿Y si tus secuencias de nucleótidos tienen Ns? ¿O Ys? ¿O W? Ns, Ys y Ws pueden no parecer bases válidas, pero son nucleótidos ambiguos estándar de la Unión Internacional de Química Pura y Aplicada (IUPAC) y son totalmente válidos en bioinformática. En muchos casos, bibliotecas de software bien probadas ya han encontrado y solucionado este tipo de problemas ocultos.

Tratar los datos como de sólo lectura

Muchos científicos pasan mucho tiempo utilizando Excel, y sin pestañear cambian el valor de una celda y guardan los resultados. Desaconsejo encarecidamente modificar los datos de esta forma. En su lugar, un enfoque mejor es tratar todos los datos comode sólo lectura y sólo permitir que los programas lean los datos y creen nuevos archivos separados de resultados.

¿Por qué es importante tratar los datos como de sólo lectura en bioinformática? En primer lugar, modificar los datos in situ puede conducir fácilmente a resultados corruptos. Por ejemplo, supongamos que escribes un script que modifica directamente un archivo. A mitad del procesamiento de un archivo grande, tu script encuentra un error y se bloquea. Como has modificado el archivo original, ¡no puedes deshacer los cambios e intentarlo de nuevo (a menos que tengas una copia de seguridad)! Esencialmente, este archivo está dañado y ya no se puede utilizar.

En segundo lugar, es fácil perder la pista de cómo hemos cambiado un archivo cuando lo modificamos in situ. A diferencia de un flujo de trabajo en el que cada paso tiene un archivo de entrada y un archivo de salida, un archivo modificado in situ no nos da ninguna indicación de lo que le hemos hecho. Si perdiéramos la pista de cómo hemos modificado un archivo y no tuviéramos una copia de seguridad de los datos originales, nuestros cambios serían esencialmente irreproducibles.

Tratar los datos como de sólo lectura puede parecer contraintuitivo a los científicos familiarizados con el trabajo extensivo en Excel, pero es esencial para una investigación sólida (y evita catástrofes, y ayuda a la reproducibilidad). La dificultad inicial merece la pena; además de salvaguardar los datos de la corrupción y los cambios incorrectos, también fomenta la reproducibilidad. Además, cualquier paso del análisis puede rehacerse fácilmente, ya que el programa no modifica los datos de entrada.

Dedica tiempo a desarrollar scripts de uso frecuente para convertirlos en herramientas

A lo largo de tu desarrollo como bioinformático altamente cualificado de , acabarás creando algunos scripts que utilizarás una y otra vez. Puede tratarse de scripts que descargan datos de una base de datos, o procesan un determinado tipo de archivo, o tal vez simplemente generan los mismos gráficos bonitos. Estos scripts pueden compartirse con miembros del laboratorio o incluso entre laboratorios. Deberías dedicar un esfuerzo y una atención extra a hacer que estos scripts de alto uso o altamente compartidos sean lo más robustos posible. En la práctica, pienso en este proceso como la conversión de guiones únicos en herramientas.

Las herramientas, a diferencia de los scripts, están diseñadas para ejecutarse una y otra vez. Están bien documentadas, tienen un versionado explícito, tienen argumentos comprensibles en la línea de comandos y se guardan en un repositorio compartido de control de versiones. Pueden parecer diferencias menores, pero la investigación robusta consiste en hacer pequeñas cosas que apilen la baraja a tu favor para evitar errores. Los scripts que aplicas repetidamente a numerosos conjuntos de datos, por definición, afectan a más resultados, y merecen estar más desarrollados para que sean más robustos y fáciles de usar. Este es especialmente el caso de los scripts que compartes con otros investigadores que necesitan poder consultar la documentación y aplicar tu herramienta con seguridad a sus propios datos. Aunque desarrollar herramientas es un proceso que requiere más trabajo que escribir un guión aislado, a la larga puede ahorrar tiempo y evitar dolores de cabeza.

Deja que los datos demuestren que son de alta calidad

Cuando los científicos piensan en analizar datos, suelen pensar en analizar datos experimentales para extraer conclusiones biológicas. Sin embargo, para realizar un trabajo bioinformático sólido, en realidad necesitamos analizar algo más que datos experimentales. Esto incluye inspeccionar y analizar datos sobre la calidad de los datos de tu experimento, archivos de salida intermedios de programas bioinformáticos y, posiblemente, datos de prueba simulados. Hacerlo así garantiza que nuestro procesamiento de datos funciona como esperamos, y encarna la regla de oro de la bioinformática: no confíes en tus herramientas ni en tus datos.

Es importante no dar nunca por sentado que un conjunto de datos es de alta calidad. Más bien, la calidad de los datos debe probarse mediante el análisis exploratorio de datos (conocido como AED). El AED no es complejo ni requiere mucho tiempo, y hará que tu investigación sea mucho más sólida frente a las sorpresas que acechan en los grandes conjuntos de datos. Aprenderemos más sobre el AED utilizando R en el Capítulo 8.

Recomendaciones para una investigación reproducible

Adoptar prácticas de investigación reproducibles no requiere mucho esfuerzo adicional. Y al igual que las prácticas de investigación sólidas, los métodos reproducibles acabarán por facilitarte la vida, ya que tú mismo puedes necesitar reproducir tu trabajo anterior mucho después de haber olvidado los detalles. A continuación encontrarás algunas recomendaciones básicas que debes tener en cuenta al practicar la bioinformática para que tu trabajo sea reproducible.

Libera tu código y tus datos

Para la reproducibilidad, los requisitos mínimos absolutos de son que se publiquen el código y los datos. Sin código y datos disponibles, tu investigación no es reproducible (véase Peng, 2001 para un buen debate sobre esto). Discutiremos cómo compartir el código y los datos un poco más adelante en el libro.

Documéntalo todo

El primer día que un científico entra en un laboratorio, se le dice que lleve un cuaderno de laboratorio. Lamentablemente, los investigadores en informática suelen abandonar esta buena práctica. Publicar el código y los datos es el requisito mínimo para la reproducibilidad, pero una documentación exhaustiva también es un componente importante de la reproducibilidad. Para reproducir completamente un estudio, cada paso del análisis debe describirse con mucho más detalle de lo que puede hacerse en un artículo académico, por lo que la documentación adicional es esencial para la reproducibilidad.

Una buena práctica a adoptar es documentar cada uno de tus pasos de análisis en archivos README de texto sin formato. Al igual que un cuaderno de laboratorio detallado, esta documentación sirve como valioso registro de tus pasos, dónde están los archivos, de dónde proceden o qué contienen. Esta documentación puede guardarse junto con el código y los datos de tu proyecto (veremos más sobre esto en los Capítulos 2 y 5), lo que puede ayudar a los colaboradores a averiguar lo que has hecho. La documentación también debe incluir todos los parámetros de entrada de cada programa ejecutado, las versiones de estos programas y cómo se ejecutaron. Los programas modernos como knitr de R y iPython Notebooks son herramientas potentes para documentar la investigación; he enumerado algunos recursos para empezar a utilizar estas herramientas en el LÉEME de este capítulo en GitHub.

Haz que las cifras y estadísticas sean los resultados de los guiones

Garantizar que un proyecto científico sea reproducible implica algo más que la mera reproducibilidad de las pruebas estadísticas clave importantes para las conclusiones, los elementos de apoyo de un artículo (por ejemplo, las figuras y las tablas) también deben ser reproducibles. La mejor forma de garantizar que estos componentes sean reproducibles es hacer que cada imagen o tabla sea la salida de un script (o scripts).

Escribir scripts para producir imágenes y tablas puede parecer un proceso que requiere más tiempo que generarlos interactivamente en Excel o R. Sin embargo, si alguna vez has tenido que regenerar varias figuras a mano tras cambiar un paso anterior, conoces el mérito de este enfoque. Los scripts que generan tablas e imágenes pueden volver a ejecutarse fácilmente, te ahorran tiempo y hacen que tu investigación sea más reproducible. Herramientas como iPython Notebooks y knitr (mencionadas en la sección anterior) también ayudan mucho en estas tareas.

Utilizar el código como documentación

En las cadenas de procesamiento complejas, a menudo la mejor documentación es un código bien documentado. Dado que el código es suficiente para decirle a un ordenador cómo ejecutar un programa (y qué parámetros utilizar), también es casi suficiente para decirle a un humano cómo reproducir tu trabajo (también es necesaria información adicional como la versión del software y los datos de entrada para que sea totalmente reproducible). En muchos casos, puede ser más fácil escribir un guión para realizar los pasos clave de un análisis que introducir comandos y luego documentarlos en otro lugar. De nuevo, el código es algo maravilloso, y utilizar código para documentar cada paso de un análisis significa que es fácil volver a ejecutar todos los pasos de un análisis si es necesario: simplemente se puede volver a ejecutar el guión.

Mejora Continua de tus Habilidades en Datos Bioinformáticos

Mantén la ideología básica introducida en este capítulo en el fondo de tu cabeza mientras trabajas en el resto del libro. Lo que he presentado aquí es suficiente para que empieces a pensar en algunos conceptos básicos de la bioinformática robusta y reproducible. Muchos de estos temas (por ejemplo, la reproducibilidad y las pruebas de software) siguen siendo objeto de investigación activa en este momento, y animo al lector interesado a explorarlos en mayor profundidad (he incluido algunos recursos en el LÉEME de este capítulo en GitHub).