Программные проекты и разработка в исследовательской среде

Каковы полезные стратегии для принятия, когда у вас или проекта нет четкого представления о том, какой конечный (если есть) продукт будет?

Возьмем "исследование", чтобы означать исследование в области, где многие вещи не известны или не реализованы, и где формальный набор результатов не может быть указан в начале проекта. Это распространено в STEM (наука (физика, химия, биология, материалы и т.д.), Технология, медицина) и многие области информатики и информатики. Программное обеспечение создается как самоцель (например, новый алгоритм), средство управления данными (часто экспериментальное) и симуляция (например, материалы, реакции и т.д.). Обычно он создается небольшими группами или отдельными лицами (я опускаю большую науку, такую как телескопы и адронные коллайдеры, где большое внимание уделяется разработке программного обеспечения.)

Исследование программного обеспечения характеризуется (по крайней мере):

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

Проекты могут быть любыми, начиная с дней ( "см., если это целесообразное направление" ) до лет ( "это моя тема PhD" ) или дольше. Часто люди не нанимаются как люди, работающие по программному обеспечению, но находят, что им нужно написать код, чтобы получить исследование или заразиться, написав программное обеспечение. Как правило, мало хорошего для разработки программного обеспечения - "продукт" является конференцией или журнальной публикацией.

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

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

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

Есть ли онлайн-ресурсы, которые могут помочь убедить людей в хороших привычках программного обеспечения?

EDIT: Я благодарен dmckee (ниже) за то, что он указал на аналогичное обсуждение. Все это хорошо, и я особенно согласен с контролем версий как одной из самых важных вещей, которые мы можем предложить ученым (мы предложили это нашим коллегам и получили очень хороший прием). Мне также нравится подход к курсу Software Carpentry, упомянутому там.

Ответ 1

Это очень сложно. Окружающая среда, которую вы и Стефано Борини описываете, очень точна. Я думаю, что есть три ключевых фактора, которые распространяют ситуацию.

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

Краткосрочное мышление. Есть несколько причин, по которым краткосрочное мышление является нормой, большинство из которых уже хорошо объяснено Стефано. Помимо ужасного давления на публикацию и отсутствия признания для создания программного обеспечения, я хотел бы подчеркнуть количество краткосрочных контрактов. Для более молодых ученых (аспирантов и постдокторов) просто очень мало преимуществ, чтобы тратить время на планирование долгосрочных программных стратегий, поскольку контракты составляют 2-3 года. В случае долгосрочных проектов, например. основанные на симуляционном коде постоянного сотрудника, я видел некоторые приложения базовой разработки программного обеспечения, такие как простой контроль версий, стандартные тестовые примеры и т.д. Однако даже в этих случаях управление проектами чрезвычайно примитивно.

Отсутствие формального обучения и опыта. Это серьезный недостаток. В астрономии и астрофизике программирование является важным инструментом, но понимание затрат на разработку, особенно накладные расходы на техническое обслуживание, крайне мало. Поскольку ученые, как правило, умные люди, существует ощущение, что методы разработки программного обеспечения на самом деле не применяются к ним и что они могут "просто заставить его работать". Имея больше опыта, большинство программистов понимают, что писать код, который в основном работает, не является трудной частью; поддерживая и расширяя его эффективно и безопасно. Некоторый научный кодекс отбрасывается, и в этих случаях быстрый и грязный подход является адекватным. Но слишком часто код будет использоваться и повторно использоваться в течение многих последующих лет, что приведет к скорбным последствиям для всех, кто связан с ним.

Постоянный оборот студентов-градиентов/postdocs для новой разработки. Я думаю, что это ключевая функция, которая позволяет академическому подходу к программному обеспечению продолжать выживать. Если код ужасен и требует времени, чтобы понять и отладить, кто платит эту цену? В общем, это не оригинальный автор (который, вероятно, переехал). Он также не является постоянным членом персонала, который часто только периферийно связан с новым развитием. Обычно аспирант внедряет новые алгоритмы, создавая новые подходы, пытаясь каким-то образом расширить код. Иногда это будет postdoc, нанятый специально для работы над добавлением какой-либо функции в существующий код и контрактной обязанностью работать в этой области в течение некоторой части своего времени.

Эта модель чрезвычайно неэффективна. Я знаю аспиранта в астрофизике, который провел более года, пытаясь реализовать относительно базовую математику, всего несколько сотен строк кода, в существующем коде n-body. Почему так долго? Потому что она буквально провела недели, пытаясь понять существующий, ужасно написанный код, и как добавить к ней свой расчет, а месяцы более неэффективно отлаживают ее проблемы из-за монолитной структуры кода в сочетании с ее собственным отсутствием опыта. Обратите внимание, что в этом процессе практически не было науки; просто теряя время, борясь с кодом. Кто в конечном итоге заплатил эту цену? Только она. Она была тем, кому пришлось потратить больше времени, чтобы попытаться получить достаточные результаты, чтобы получить степень доктора философии. После того, как она уйдет, ее руководитель получит еще одного ученика-градиента, и цикл продолжится.

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

Ответ 2

Я расскажу вам свой опыт.

Несомненно, что в науке создается и направляется большое количество программного обеспечения. Факт в том, что трудно адаптировать исследовательское программное обеспечение, специально созданное для конкретной исследовательской цели, к более общей среде. Кроме того, продуктом научных кругов являются научные статьи, а не программное обеспечение. Стоимость программного обеспечения в академических кругах равна нулю. Данные, которые вы производите с помощью этого программного обеспечения, оцениваются, как только вы пишете на нем бумагу (которая занимает много времени для редакционной работы).

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

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

Короткий охват проекта и высокая эффективность исследований (например, опубликование или исчезновение видения, столь централизованное сегодня), требуют гибких, быстрых языков и, в общем, языков, которые можно быстро схватить. Кандидаты в области геномики и квантовой химии не имеют формального программирования. В некоторых случаях им это даже не нравится. Поэтому язык должен быть быстрым, легким, чистым, гибким и легко понять позже. Последний момент - это капитал, так как нет времени для подготовки документации, и это гарантировало, что в академических кругах все рано или поздно уйдут, вы сжигаете групповой опыт до нуля каждые три года или около того. Academia - это отрасль с высоким уровнем риска, которая периодически запускает всех своих жестких исполнителей, сохраняя только некоторых менеджеров. Таким образом, наличие кода, который может быть легко обслуживаемым и может быть легко захвачен кем-то другим, является капиталом. Кроме того, никогда не недооценивайте возможности поиска Google для решения ваших проблем. С хорошо развернутым языком вы с большей вероятностью найдете ответы на вопрос о проблемах и проблемах, на которые вы можете наткнуться.

Управление также является проблемой. Водопад не обсуждается. Не существует времени для программирования документов (требования, спецификации, дизайн). Спираль вполне нормально, но, насколько это возможно, рекомендуется использовать как можно более мелкие документы. Факт в том, что все, что не дает вам статьи в академических кругах, напрасно тратится впустую. Если вы проводите месячные письменные спецификации, это будет потрачено на месяц, и ваш контракт истечет через 11 месяцев. Более того, этот жирный документ считается нулевым или близким к нулю для вашей карьеры (как и многие другие: администрирование и обучение - это два примера). Конечно, гибкие методы также не обсуждаются. Большая часть развития осуществляется группами, которые далеки и, как правило, имеют множество других вещей. Концентрация кодирования вкратце появляется во время "свободного времени" между статьями и до или после встреч. Самый вероятный базар, но на базаре тоже много проблем.

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

Ответ 3

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

Если вы знаете, что код будет только для бумаги, хорошо, сделайте короткие сокращения. Hardcode все, что вы можете. Не тратьте время на тщательную проверку, если программист является единственным, кто когда-либо запустит код. И т.д. Проблема заключается в том, что кто-то говорит "Отлично! Теперь позвольте использовать это для реального" или "Теперь давайте использовать его для этого совершенно другого сценария, чем то, для чего оно было разработано и проверено".

Связанная задача состоит в том, чтобы объяснить, почему программное обеспечение не готово к прайм-тайму, даже несмотря на то, что оно, очевидно, работает, т.е. качество прототипа, а не качество продукции. Что вы имеете в виду, вам нужно переписать его?

Ответ 4

Я бы рекомендовал вам/им прочитать "Чистый код"

http://www.amazon.co.uk/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882/ref=sr_1_1?ie=UTF8&s=books&qid=1251633753&sr=8-1

Основная идея этой книги заключается в том, что если вы не сохраните код "чистым", в конечном итоге беспорядок остановит вас от достижения какого-либо прогресса.

Ответ 5

Вид большой науки, которую я делаю (физика частиц), имеет небольшое количество крупных долгосрочных проектов (ROOT и Geant4, например). Они разработаны в основном специалистами по программированию. Использование процессов, которые будут распознаны кем-либо еще в отрасли.

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

Наконец, почти каждый ученый работает над своими программами. Использование процесса в этих программах очень пятнистое, и они часто страдают от всех болезней, о которых говорили другие (короткие сроки жизни, плохие навыки кодирования, отсутствие обзора, множество последовательных сопровождающих, Inv Invented Here Syndrome и т.д.). Единственное преимущество, которое доступно здесь, по сравнению с малой группой, заключается в том, что они работают с инструментами, о которых я говорил выше, поэтому есть что-то, на что вы можете указать и сказать: "Это то, чего вы хотите достичь".

Ответ 6

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

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

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

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