Подтвердить что ты не робот

Лучший способ организовать проекты по биоинформатике?

Я из компьютерной науки. фон, но теперь я делаю геномику.

Мои проекты включают в себя много биоинформатики, которые обычно включают в себя: выравнивание последовательностей, сравнение перекрытия и т.д. между последовательностями и различными функциями аннотации генома, из разных классов биологических образцов, данных временного курса, microarray, высокопроизводительная последовательность (последовательность следующего поколения, хотя это текущее поколение на самом деле) данных, такого рода вещи.

Рабочий процесс с таким анализом сильно отличается от того, что я испытал во время учебы в области компьютерных наук: нет UML и тщательно продуманных объектов, сияющих с возвышенной элегантностью, без управления версиями, без надлежащей документации (часто без документации), нет разработки программного обеспечения вообще.

Вместо этого все, что делают в этой области, взламывают один Perl- script или AWK -one-liner после другие, обычно для разового использования.

Я думаю, причина в том, что входные данные и форматы меняются так быстро, на вопросы нужно ответить так скоро (сроки!), что, похоже, нет времени для организации проекта.

Один пример, чтобы проиллюстрировать это: пусть говорят, что вы хотите написать raytracer. Вначале вы, вероятно, приложите много усилий для разработки программного обеспечения. Затем запрограммируйте его, наконец, в некоторой высокооптимизированной форме. Потому что вы использовали бы бесчисленное множество raytracer с различными входными данными и вносили изменения в исходный код в течение долгих лет. Так что хорошая разработка программного обеспечения имеет первостепенное значение при кодировании серьезного raytracer с нуля. Но представьте, что вы хотите написать raytracer, где вы уже знаете, что будете использовать его для поиска одного, единственного рисунка. И эта картина имеет отражающую сферу над клетчатым полом. В этом случае вы как-то просто взломали его. Биоинформатика похожа на последний случай.

В итоге вы получите целые деревья каталогов с той же информацией в разных форматах, пока не достигнете одного конкретного формата, необходимого для следующего шага, и дюжины файлов с именами типа "tmp_SNP_cancer_34521_unique_IDs_not_Chimp.csv", где у вас нет малейшая идея на следующий день, почему вы создали этот файл и что это такое.

Некоторое время я использовал MySQL, который помог, но теперь скорость создания новых данных и изменения форматов такова что невозможно сделать правильный дизайн базы данных.

Мне известно об одной публикации, посвященной этим вопросам (Noble, W. S. (2009, июль). Краткое руководство по организации проектов вычислительной биологии. PLoS Comput Biol 5 (7), e1000424 +). Автор суммирует цель довольно хорошо:

Основной руководящий принцип прост: Кто-то, кто не знаком с вашим проектом должны быть в состоянии компьютерные файлы и подробно о том, что вы сделали и почему.

Хорошо, это то, что я хочу, тоже! Но я уже придерживаюсь той же практики, что и этот автор, и я считаю, что это абсолютно недостаточно.

Документирование каждой команды, которую вы выдаете в Bash, комментируя ее, почему именно вы это сделали и т.д., просто утомительно и подвержены ошибкам. Шаги во время рабочего процесса слишком мелкие. Даже если вы это сделаете, может оказаться очень утомительной задачей выяснить, для чего был создан каждый файл, и в какой момент был прерван определенный рабочий процесс и по какой причине и где вы продолжили.

(Я не использую слово "рабочий процесс" в смысле "Таверна", по рабочему процессу я имею в виду только шаги, команды и программы, которые вы выбираете для достижения определенной цели).

Как вы организуете проекты по биоинформатике?

4b9b3361

ОТВЕТЫ

Ответ 1

Я специалист по программному обеспечению, встроенный в группу ученых-исследователей, хотя и в области наук о Земле, а не в области наук о жизни. Мне знакомо много того, что вы пишете.

Следует иметь в виду, что многое из того, что вы узнали в своих исследованиях, - это инженерное программное обеспечение для дальнейшего использования. Поскольку вы наблюдали много исследований, которые делают ученые, это одноразовое использование, и инженерный подход не подходит. Если вы хотите реализовать некоторые аспекты хорошей разработки программного обеспечения, вам придется тщательно выбирать свои битвы.

Прежде чем вы начнете сражаться с любыми битвами, вам придется критически исследовать свои собственные идеи, чтобы убедиться, что то, что вы узнали в школе о разработке программного обеспечения общего назначения, действительно для вашей текущей ситуации. Не думайте, что это так.

В моем случае первой битвой, которую я выбрал, была реализация управления исходным кодом. Нетрудно было найти примеры всего, что не так, когда у вас нет контроля версий:

  • у некоторых пользователей было множество каталогов, каждый из которых имел разные версии "одного" кода, и только самая туманная идея того, что большинство из них сделали, было уникальным или почему они были там;
  • некоторые пользователи потеряли полезные изменения, перезаписав их и не сумев вспомнить, что они сделали;
  • было легко найти ситуации, когда люди работали над тем, что должно было быть одной и той же программой, но фактически развивались несовместимо в разных направлениях;
  • и т.д. и т.д.

Как только я собрал информацию - и убедитесь, что вы сохраняете хорошие заметки о том, кто сказал что и что это их стоило, стало довольно легко нарисовать картину лучшего мира с контролем исходного кода.

Далее, ну, потом вам нужно выбрать свою собственную следующую битву. Но одним из семян сомнений, которые вы должны посеять в умах учёных-коллег, является "воспроизводимость". Научные эксперименты недействительны, если они не воспроизводятся; если их эксперименты связаны с программным обеспечением (и они всегда это делают), то тщательная разработка программного обеспечения имеет важное значение для воспроизводимости. Многие из них касаются происхождения данных, но это тема для другого дня.

Ответ 3

Часть проблемы здесь - это различие между документацией для программного обеспечения и документацией для публикации.

Для разработки программного обеспечения (и плана исследований) важная документация является структурной и преднамеренной. Таким образом, моделирование данных, причины, по которым вы что-то делаете, и т.д. Я настоятельно рекомендую использовать навыки, которые вы узнали в CS, для документирования вашего плана исследований. Наличие плана для того, что вы хотите сделать, дает вам много свободы для многозадачности при длительном анализе.

С другой стороны, много работы по биоинформатике - это анализ. Здесь вам нужно рассматривать документацию как лабораторный ноутбук, а не обязательно план проекта. Вы хотите быть документированным тем, что вы сделали, может быть, краткий комментарий, почему (например, когда вы пытаетесь устранить неполадки), и каковы результаты и результаты. То, что я делаю, довольно просто. Во-первых, я начинаю в каталоге и создаю репозиторий git. Затем, когда я меняю какой-то файл, я передаю его репо. Насколько это возможно, я пытаюсь назвать выходы данных таким образом, чтобы я мог затем упасть в мои файлы git ignore. Затем, насколько это возможно, я работаю на одном сеансе терминала для проекта за раз, и когда я нажимаю точку паузы (например, когда у меня есть набор заданий, отправленных в сетку, я запускаю "историю"; вырезать -c 8- 'и вставить в файл лабораторных заметок. Затем я редактирую файл, чтобы добавлять комментарии к тому, что я сделал, и помните, измените строки git add/commit на git checkout (у меня есть script, который делает это на основе сообщений фиксации). Пока я запускаю его в правильном каталоге, и мои внешние данные не исчезают, это означает, что я могу снова создать весь процесс.

Для любых даже немного сложных задач обработки я пишу script, чтобы сделать это, чтобы мой ноутбук, насколько это было возможно, выглядел чистым. В приближении хелпер script можно рассматривать как подпрограмму в более крупном проекте и должен быть документирован внутренне по крайней мере на этом уровне.

Ответ 4

Ваш вопрос касается управления проектами. Плохое управление проектом не уникально для биоинформатики. Мне трудно поверить, что вся индустрия биоинформатики связана с плохим дизайном программного обеспечения.

О предчувствии... Опять в этом мире есть другие, у которых очень сложные сроки, и они все еще используют хорошие разработки программного обеспечения.

Во многих случаях, после хорошего дизайна программного обеспечения не удерживает проекты и может даже ускорить его проектирование и техническое обслуживание (по крайней мере в долгосрочной перспективе).

Теперь на ваш реальный вопрос... Вы можете предложить своему менеджеру перепроектировать небольшие части кода, которые не влияют на остальную часть кода в качестве доказательства концепции (POC), но действительно сложно остановить грузовик от продолжения движения, так что не расстраивайтесь, если он чувствует, что "мы так много работали годами - мы знаем, что делаем, и нам не нужен ребенок, чтобы научить нас, как делать нашу работу". Научитесь работать как остальные, и когда вы обретете доверие, вы можете иногда делайте свое дело (надеюсь, у вас будет время и преданность поступать правильно).

Удачи.