Программные проекты и разработки в исследовательской среде
Какие полезные стратегии следует использовать, когда вы или проект не имеете четкого представления о том, каким будет конечный (если таковой имеется) продукт?
Давайте возьмем "исследование", чтобы обозначить исследование области, где многие вещи не известны или не реализованы и где формальный набор результатов не может быть определен в начале проекта. Это распространено в STEM (наука (физика, химия, биология, материалы и т. Д.), Технологии, медицина) и во многих областях информатики и информатики. Программное обеспечение создается как самоцель (например, новый алгоритм), как средство управления данными (часто экспериментальными) и моделирования (например, материалы, реакции и т. Д.). Обычно он создается небольшими группами или отдельными лицами (я опускаю такие крупные науки, как телескопы и адронные коллайдеры, где большое внимание уделяется разработке программного обеспечения).
Программное обеспечение для исследований характеризуется (как минимум):
- неизвестный результат
- неизвестные сроки
- немного формального управления проектами
- ограниченные бюджеты (по крайней мере, в академических кругах)
- непредсказуемость сторонних инструментов и библиотек
- изменения во внешнем мире во время проекта (например, новые открытия, которые могут быть положительными - сэкономить усилия - или отрицательными - получить сенсацию
Проекты могут быть любыми от дней ("посмотрите, стоит ли идти в этом направлении") до лет ("это тема моей кандидатской диссертации") или дольше. Часто люди не нанимаются как люди, занимающиеся программным обеспечением, но обнаруживают, что им нужно писать код для выполнения исследований или заражаться при написании программного обеспечения. Как правило, мало хорошего в разработке программного обеспечения - "продукт" - это конференция или публикация в журнале.
Однако некоторые из этих проектов оказываются весьма ценными - наиболее очевидной областью является геномика, где в первые годы ученые показали, что динамическое программирование было революционным инструментом, помогающим думать о белке и структуре нуклеинов - теперь это многомиллиардная индустрия (или больше). То же самое относится и к кодам квантовой механики для прогнозирования свойств веществ.
Недостатком является то, что большое количество кода выбрасывается, и его трудно построить. Чтобы попытаться преодолеть это, мы создали библиотеки, которые совместно используются в группе и во всем мире как Open Source (но и здесь очень мало пользы). Многие исследователи изобретают колесо (программирование "головой вниз", когда с коллегами не консультируются, и программирование "героя", когда кто-то пытается сделать все самому).
Слишком много формальностей в начале проекта часто отталкивает людей и инновации теряются (никто не потратит 2 месяца на написание формальных спецификаций и модульных тестов). Слишком мало и вредные привычки развиваются и распространяются. Курсы программирования помогают, но опять же трудно заставить людей делать их, особенно когда вы полагаетесь на их добрую волю. Наставничество чрезвычайно ценно, но не всегда успешно.
Существуют ли онлайн-ресурсы, которые могут помочь убедить людей в хороших привычках программного обеспечения?
РЕДАКТИРОВАТЬ: Я благодарен dmckee (ниже) за указание на подобное обсуждение. Это все хорошо, и я особенно согласен с тем, что контроль версий - это одна из самых важных вещей, которые мы можем предложить ученым (мы предложили это нашим коллегам и получили очень хорошую оценку). Мне также нравится подход упомянутого там курса Software Carpentry.
6 ответов
Это чрезвычайно сложно. Окружающая среда, которую вы и Стефано Борини описываете, очень точна. Я думаю, что есть три ключевых фактора, которые распространяют ситуацию.
- Краткосрочное мышление
- Отсутствие формального обучения и опыта
- Непрерывный оборот аспирантов / постдоков, чтобы взять на себя основную тяжесть новых разработок
Краткосрочное мышление. Есть несколько причин, по которым краткосрочное мышление является нормой, большинство из них уже хорошо объяснено Стефано. Помимо ужасного давления на публикацию и отсутствия признания для создания программного обеспечения, я бы подчеркнул число краткосрочных контрактов. У более младших преподавателей (аспирантов и докторантов) просто очень мало возможностей тратить время на планирование долгосрочных программных стратегий, поскольку контракты заключаются на 2-3 года. В случае более долгосрочных проектов, например, основанных на коде моделирования постоянного сотрудника, я видел некоторые приложения базовой разработки программного обеспечения, такие как простой контроль версий, стандартные тестовые сценарии и т. Д. Однако даже в этих случаях Управление проектами крайне примитивно.
Отсутствие формального обучения и опыта. Это серьезный недостаток. В астрономии и астрофизике программирование является важным инструментом, но понимание затрат на разработку, особенно затрат на обслуживание, крайне плохое. Поскольку ученые, как правило, умные люди, возникает ощущение, что методы разработки программного обеспечения на самом деле к ним не относятся, и что они могут "просто заставить это работать". Имея больше опыта, большинство программистов понимают, что написание кода, который в основном работает, не самая сложная часть; поддерживать и расширять его эффективно и безопасно. Некоторый научный кодекс одноразовый, и в этих случаях быстрый и грязный подход является адекватным. Но слишком часто код будет использоваться и многократно использоваться в течение многих лет, что приведет к печальным последствиям для всех, кто с ним связан.
Непрерывный оборот аспирантов / постдоков для новых разработок. Я думаю, что это ключевая особенность, которая позволяет академическому подходу к программному обеспечению продолжать выживать. Если код ужасен и занимает несколько дней, чтобы понять и отладить, кто платит эту цену? В общем, это не оригинальный автор (который, вероятно, перешел). И при этом это не постоянный сотрудник, который часто только периферийно связан с новым развитием. Обычно аспирант внедряет новые алгоритмы, разрабатывает новые подходы, пытается каким-то образом расширить код. Иногда это будет постдок, специально нанятый для работы над добавлением какой-либо функции в существующий код, и по контракту обязанный работать над этой областью в течение некоторой части своего времени.
Эта модель крайне неэффективна. Я знаю аспиранта по астрофизике, который потратил более года, пытаясь реализовать сравнительно базовый фрагмент математики, всего несколько сотен строк кода, в существующем коде из n тел. Почему это заняло так много времени? Потому что она буквально потратила недели, пытаясь понять существующий, ужасно написанный код и как добавить к нему свои вычисления, а месяцы - более неэффективно отлаживая свои проблемы из-за монолитной структуры кода в сочетании с ее собственным недостатком опыта. Обратите внимание, что в этом процессе почти не было науки; просто тратить время на борьбу с кодом. Кто в итоге заплатил эту цену? Только она. Она была той, кто должен был потратить больше часов, чтобы попытаться получить достаточное количество результатов, чтобы получить докторскую степень. Ее руководитель получит еще одного аспиранта после ее ухода - и цикл продолжается.
Я пытаюсь подчеркнуть, что проблема с процессом создания программного обеспечения в академических кругах присуща самой системе, зависит от доступных ресурсов и вида работы, которая будет вознаграждена. Культура глубоко укоренилась во всех научных кругах. Я не вижу простого способа изменить эту культуру с помощью внешних ресурсов или обучения. Это сама система, которая должна измениться, вознаградить людей за написание существенного кода, уделить больше внимания правильности результатов, полученных с использованием научного кода, признать важность обучения и процесса в коде, и привлечь руководителей, несущих солидарную ответственность за потери время членов их исследовательской группы.
Я расскажу вам свой опыт.
Несомненно, что много программного обеспечения создается и тратится впустую в академических кругах. Факт заключается в том, что трудно адаптировать исследовательское программное обеспечение, специально созданное для конкретной исследовательской цели, к более общей среде. Кроме того, продуктом научных исследований являются научные статьи, а не программное обеспечение. Ценность программного обеспечения в научных кругах равна нулю. Данные, которые вы производите с помощью этого программного обеспечения, оцениваются после того, как вы напишите на них статью (что занимает много времени на редактирование).
В большинстве случаев, однако, исследовательские группы распознали частые схемы, которые можно отточить, проверить и заархивировать как внутренние знания. Это то, что я делаю с моим личным инструментарием. Я выращиваю его в соответствии со своими потребностями в исследованиях, только с теми функциями, которые являются "кросс-проектными". Разработка личного инструментария является почти обязательным требованием, поскольку ваши научные потребности, скорее всего, уникальны для какого-то стиха (в противном случае вы бы не занимались исследованиями), и вы хотите иметь как можно меньше внешних зависимостей (поскольку, если что-то развивается и ломает вашу мелочи, у тебя не будет времени это починить).
Все остальное, однако, слишком специфично для данного проекта, чтобы быть кристаллизованным. Поэтому я склонен не заключать в капсулу что-то однозначно решающее. Однако я вернусь и улучшу его, если позже другим проектам потребуется такой же кусок кода.
Короткий проектный период и накал исследований (например, концепция публикации и гибели, столь важная сегодня), требуют гибких, быстрых языков и, в общем, языков, которые можно быстро понять. Кандидаты наук в области геномики и квантовой химии не имеют формального опыта программирования. В некоторых случаях им это даже не нравится. Таким образом, язык должен быть быстрым, легким, чистым, гибким и легким для понимания в дальнейшем. Последний момент - капитал, так как нет времени на подготовку документации, и гарантируется, что в академических кругах каждый рано или поздно уйдет, а вы сожжете групповой опыт до нуля каждые три года или около того. Academia - индустрия высокого риска, которая периодически увольняет всех своих трудолюбивых исполнителей, оставляя только некоторых менеджеров. Таким образом, наличие кода, который можно поддерживать и который может быть легко понят кем-то другим, является капиталом. Кроме того, никогда не стоит недооценивать силу поиска Google для решения ваших проблем. С хорошо развернутым языком вы с большей вероятностью найдете ответы на вопросы и проблемы, с которыми вы можете столкнуться.
Управление также является проблемой. Водопад не обсуждается. Нет времени на программирование документов (требования, спецификации, дизайн). Спираль вполне в порядке, но явно рекомендуется как можно меньше бумажной работы. Факт в том, что все, что не дает вам статьи в академической среде, - это пустая трата времени. Если вы тратите один месяц на написание спецификаций, это месяц впустую, и ваш контракт истекает через 11 месяцев. Более того, этот жирный документ считается нулем или близким к нулю для вашей карьеры (как и многие другие вещи: администрация и обучение - два примера). Конечно, гибкие методы также не обсуждаются. Большая часть разработок осуществляется группами, находящимися далеко, и, как правило, у них есть еще куча дел. Концентрация кодирования происходит короткими очередями в "свободное время" между статьями, а также до или после встреч. Базар является наиболее вероятным, но базар также несет в себе много проблем.
Итак, чтобы ответить на ваш вопрос, лучшая стратегия - это "медленное накопление" известного хорошего программного обеспечения, разработка небольшими пакетами с быстрым и гибким методом и языком. Надлежащую практику кодирования нужно преподавать во время лекций, как добросовестная лабораторная практика преподается во время практических курсов (например, никогда не добавляйте воду в серную кислоту, всегда наоборот)
Самым сложным является переход между "это только для бумаги" и "мы действительно собираемся использовать это".
Если вы знаете, что код будет только для бумаги, хорошо, возьмите короткие пути. Жесткий код все, что вы можете. Не тратьте время на тщательную проверку, если программист - единственный, кто когда-либо будет запускать код. И т.д. Проблема в том, что когда кто-то говорит: "Отлично! Теперь давайте использовать это по-настоящему" или "Теперь давайте использовать его для этого совершенно другого сценария, чем тот, для которого он был разработан и протестирован".
Связанная с этим задача состоит в том, чтобы объяснить, почему программное обеспечение не готово к прайм-тайм, хотя оно, очевидно, работает, то есть качество прототипа, а не качество производства. Что вы имеете в виду, вам нужно переписать это?
Я бы порекомендовал вам / они читать "Чистый код"
Основная идея этой книги заключается в том, что если вы не будете содержать код в чистоте, то в конечном итоге беспорядок остановит вас.
В моей большой науке (физике элементарных частиц) есть небольшое количество крупных, долгосрочных проектов (например, ROOT и Geant4). Они разработаны в основном настоящими профессионалами в области программирования. Использование процессов, которые были бы признаны кем-либо еще в отрасли.
Затем каждое сотрудничество имеет ряд программ для всего проекта, которые разрабатываются совместно под руководством небольшого числа старших ученых-программистов. Они используют, по крайней мере, основные инструменты (всегда контроль версий, часто какое-то отслеживание ошибок или автоматические сборки).
Наконец, почти каждый ученый работает по своим собственным программам. Использование процессов в этих программах очень неравномерно, и они часто страдают от всех недугов, которые обсуждали другие (короткое время жизни, плохие навыки кодирования, отсутствие рецензий, большое количество сопровождающих, синдром "не изобретено здесь" и т. Д. И т. Д.). Единственное преимущество, которое доступно здесь по сравнению с наукой о малых группах, заключается в том, что они работают с инструментами, о которых я говорил выше, поэтому есть кое-что, на что вы можете указать и сказать: "Это то, чего вы хотите достичь".
На самом деле больше нечего добавить к тому, что уже было сказано. Это сложный баланс, потому что у нас разные приоритеты - научные круги стремятся к открытию новых вещей, а разработка программного обеспечения - к выполнению задач в соответствии со спецификациями.
Самая важная вещь, о которой я могу подумать, - это попытаться освободиться от культуры внутреннего развития, которая существует в академических кругах, и попытаться придерживаться дисциплинированного подхода к развитию, который может быть сложным во многих случаях из-за нехватки времени, нехватка опыта и т. д. Это уродство контроля высасывает личную ответственность и принятие решений и оставляет его в руках немногих, кто не обязательно знает лучше
Получив хорошую книгу по разработке программного обеспечения, Code Complete уже упоминается отлично, как и любая уважаемая книга по алгоритмам и структурам данных. Узнайте, как вам нужно управлять своими данными, например, нужны ли вам быстрые поисковые / хеш-таблицы / двоичные деревья. Не изобретайте велосипед - используйте библиотеки и такие вещи, как STL, иначе вы, скорее всего, будете тратить время впустую. В Интернете есть огромное количество материалов, включая этот очень хороший блог.
Многие академики, помимо того, что иногда примадонны и ценны в отношении любого подхода, рассматриваемого как деловой, имеют тенденцию быть весьма расплывчатыми в своих целях. Мягко говоря. Только по этой причине крайне важно создать собственный программный арсенал вспомогательных функций и рецептов, в конечном итоге, надеясь, что в итоге получится некая гибкая экспериментальная среда, которая позволит вам опробовать любую комбинацию вещей, не ограничиваясь какой-либо конкретной проблемой. площадь. Сильно устоять перед искушением просто погрузиться в проблему под рукой.