Проекты программного обеспечения и разработка в [закрытой] среде исследования
После открытия файла вам необходимо прочитать его содержимое, а для добавления нужно написать. Внутри оператора with сделать следующее:
file_content = out_file.read()
и добавить следующее:
out_file.write("Your output")
6 ответов
Это чрезвычайно сложно. Окружающая среда, которую описываете вы и Стефано Борини , очень точно. Я думаю, что есть три ключевых фактора, которые распространяют эту ситуацию.
- Краткосрочное мышление
- Отсутствие формальной подготовки и опыта
- Постоянная текучесть кадров аспирантов / постдоков, которые берут на себя основную тяжесть новых разработок
термин мышление. Есть несколько причин, по которым краткосрочное мышление является нормой, большинство из них уже хорошо объяснил Стефано. Помимо ужасного давления, связанного с публикацией, и отсутствия признания создания программного обеспечения, я бы выделил количество краткосрочных контрактов. У более молодых ученых (аспирантов и постдоков) просто очень мало преимуществ тратить какое-либо время на планирование долгосрочных программных стратегий, поскольку контракты заключаются на 2-3 года. В случае долгосрочных проектов, например, тех, которые основаны на коде моделирования постоянного сотрудника, я видел некоторые приложения базовой программной инженерии, такие как простой контроль версий, стандартные тестовые примеры и т. Д. Однако даже в этих случаях управление проектами чрезвычайно примитивно.
Отсутствие формальной подготовки и опыта. Это серьезный недостаток. В астрономии и астрофизике программирование является важным инструментом, но понимание затрат на разработку, особенно накладных расходов на обслуживание, крайне слабое. Поскольку ученые, как правило, умные люди, возникает ощущение, что методы разработки программного обеспечения к ним не применимы и что они могут «просто заставить это работать». Обладая большим опытом, большинство программистов понимают, что написание кода, который в основном работает, не является сложной задачей; поддерживать и расширять его эффективно и безопасно. Некоторая часть научного кода оказывается ненужной, и в этих случаях подойдет быстрый и грязный подход. Но слишком часто код будет использоваться и повторно использоваться в течение долгих лет, в результате чего будут страдать все, кто с ним связан.
Непрерывная текучесть аспирантов / постдоков для новых разработок. Я думаю, что это ключевая особенность, которая позволяет академическому подходу к программному обеспечению выжить. Если код ужасен и требует дней, чтобы разобраться и отладить, кто заплатит эту цену? В общем, это не первоначальный автор (который, вероятно, ушел). И это не постоянный сотрудник, который часто лишь второстепенно участвует в новых разработках. Обычно именно аспирант внедряет новые алгоритмы, разрабатывает новые подходы, пытаясь каким-то образом расширить код. Иногда это будет постдок, нанятый специально для работы над добавлением какой-либо функции в существующий код и по контракту обязанный работать в этой области в течение некоторой части своего времени.
Эта модель чрезвычайно неэффективна. Я знаю аспиранта по астрофизике, который потратил больше года, пытаясь реализовать относительно простую часть математики, всего несколько сотен строк кода, в существующем коде из n тел. Почему это заняло так много времени? Потому что она буквально потратила недели, пытаясь понять существующий ужасно написанный код и то, как добавить к нему свои вычисления, и месяцев более неэффективно отлаживая свои проблемы из-за монолитной структуры кода вкупе с отсутствием у нее собственного опыт. Обратите внимание, что в этом процессе почти не было науки ; просто тратить время на борьбу с кодом. Кто в конечном итоге заплатил эту цену? Только она. Именно ей пришлось потратить больше времени, чтобы попытаться получить достаточно результатов, чтобы получить докторскую степень. Ее научный руководитель получит еще одного аспиранта после ее ухода - и цикл продолжается.
Я пытаюсь подчеркнуть, что проблема с процессом создания программного обеспечения в академических кругах присуща самой системе, являясь функцией доступные ресурсы и тип работы, которая вознаграждается. Эта культура глубоко укоренилась в академических кругах. Я не вижу простого способа изменить эту культуру с помощью внешних ресурсов или обучения. Необходимо изменить саму систему, чтобы вознаграждать людей за написание содержательного кода, повышать внимательность к правильности результатов, полученных с использованием научного кода,
Самая сложная часть - это переход между «это просто для бумаги» и «мы действительно собираемся использовать это».
Если вы знаете, что код будет только для бумаги, хорошо, возьмите короткие пути. Жесткий код все, что вы можете. Не тратьте время на тщательную проверку, если программист - единственный, кто когда-либо будет запускать код. И т.д. Проблема в том, что когда кто-то говорит: «Отлично! Теперь давайте использовать это по-настоящему» или «Теперь давайте использовать его для этого совершенно другого сценария, чем то, для чего он был разработан и проверен».
объяснить, почему программное обеспечение не готово к прайм-тайму, хотя оно, очевидно, работает, то есть качество прототипа, а не качество производства. Что вы имеете в виду, что вам нужно переписать это?
Я бы порекомендовал вам / им прочитать «Чистый код»
Основная идея этой книги состоит в том, что если вы не держите код «чистым», в конечном итоге беспорядок помешает вам добиться прогресса.
В моей большой науке (физика элементарных частиц) есть небольшое количество крупных и долгосрочных проектов ( ROOT и Geant4 , для пример). Они разрабатываются в основном настоящими профессионалами в области программирования. Использование процессов, которые были бы признаны кем-либо еще в отрасли.
Кроме того, каждое сотрудничество имеет ряд программ в масштабе проекта, которые разрабатываются совместно под руководством небольшого числа старших ученых-программистов. Они используют по крайней мере базовые инструменты (всегда контроль версий, часто своего рода отслеживание ошибок или автоматические сборки).
Наконец, почти каждый ученый работает над своими собственными программами. Процессы в этих программах используются очень неравномерно, и они часто страдают от всех недугов, о которых говорили другие (короткое время жизни, плохие навыки программирования, отсутствие обзора, много серийных сопровождающих, синдром Not Invented Here и т. д. и т. д.). Единственное преимущество, которое доступно здесь по сравнению с наукой в малых группах, заключается в том, что они работают с инструментами, о которых я говорил выше, поэтому есть что-то, на что вы можете указать и сказать: «Это то, чего вы хотите достичь».
Мне действительно нечего добавить к тому, что уже было сказано. Достичь баланса сложно, потому что наши приоритеты разные - академические круги - это открытие новых вещей, разработка программного обеспечения - это больше, чтобы делать вещи в соответствии со спецификациями.
Самая важная вещь, о которой я могу думать, - это попытаться освободиться от культура внутреннего развития, которая продолжается в академических кругах и пытается поддерживать дисциплинированный подход к развитию, как бы трудно это ни было во многих случаях из-за нехватки времени, отсутствия опыта и т. д. Это безумие контроля засасывает индивидуальную ответственность и принятие решений и оставляет его в руках немногих, кто не обязательно знает лучше всех.
Получите хорошую книгу по разработке программного обеспечения, уже упомянутый Code Complete превосходен, а также любую уважаемую книгу по алгоритмам и структурам данных. Прочтите, как вам нужно будет управлять своими данными, например, нужен ли вам быстрый поиск / хеш-таблицы / двоичные деревья. Не изобретайте велосипед - используйте библиотеки и такие вещи, как STL, иначе вы, скорее всего, зря потратите время. В сети огромное количество информации, в том числе и этот замечательный блог.
Многие ученые, помимо того, что они иногда являются примадонными и ценными в отношении любого подхода, рассматриваемого как деловой, имеют тенденцию к довольно расплывчатым целям. Мягко говоря. Уже по этой причине жизненно важно создать свой собственный программный арсенал вспомогательных функций и рецептов, в конечном итоге, надеюсь, в конечном итоге получится своего рода гибкая экспериментальная структура, которая позволит вам опробовать любую комбинацию вещей, не ограничиваясь какой-либо конкретной проблемой. площадь.
Я расскажу вам свой опыт.
Несомненно, много программного обеспечения создается и тратится впустую в академических кругах. Дело в том, что исследовательское программное обеспечение, специально созданное для конкретной исследовательской цели, сложно адаптировать к более общей среде. Кроме того, продуктом академических кругов являются научные статьи, а не программное обеспечение. Ценность программного обеспечения в академических кругах равна нулю. Данные, которые вы производите с помощью этого программного обеспечения, оцениваются, как только вы пишете на них статью (что занимает много редакционного времени).
В большинстве случаев, однако, исследовательские группы распознали частые шаблоны, которые можно отшлифовать, проверить и заархивированы как внутренние знания. Это то, что я делаю со своим личным набором инструментов. Я выращиваю его в соответствии с моими исследовательскими потребностями, только с теми функциями, которые являются «кросс-проектными». Разработка личного инструментария - это почти обязательное требование, поскольку ваши научные потребности, скорее всего, уникальны для какого-то стиха (иначе вы бы не проводили исследования), и вы хотите иметь как можно меньше внешних зависимостей (поскольку если что-то развивается и ломает ваш
Все остальное, однако, слишком специфично для конкретного проекта, чтобы кристаллизоваться. Поэтому я стараюсь не инкапсулировать что-то, что явно является одноразовым решателем. Однако я все же вернусь и улучшу его, если позже другие проекты потребуют того же фрагмента кода.
Короткий период проекта и жар исследований (например, видение опубликовать или исчезнуть так что центральный сегодня), требует гибких, быстрых языков, и в целом языков, которые можно быстро понять. Докторов наук по геномике и квантовой химии у меня нет формального опыта программирования. В некоторых случаях им это даже не нравится. Таким образом, язык должен быть быстрым, легким, понятным, гибким и легким для понимания позже. Последний пункт имеет большое значение, поскольку некогда создавать документацию, и гарантировано, что в академических кругах все рано или поздно уйдут, вы сжигаете групповой опыт до нуля каждые три года или около того. Академия - это отрасль высокого риска, которая периодически увольняет всех своих жестко сформированных исполнителей, оставляя только некоторых менеджеров. Поэтому иметь код, который можно сопровождать и который может легко понять кто-то другой, является капиталом. Кроме того, никогда не стоит недооценивать силу поиска Google в решении ваших проблем. С хорошо развернутым языком вы с большей вероятностью найдете ответы на подводные камни и проблемы, на которые вы можете наткнуться.
Управление - тоже проблема. Водопад не обсуждается. Нет времени на бумажную работу по программированию (требования, характеристики, дизайн). Спираль вполне подходит, но настоятельно рекомендуется как можно меньше бумажной работы. Дело в том, что все, что не дает вам статьи в академических кругах, - зря потраченное время. Если вы потратите один месяц на написание спецификаций, он будет потрачен впустую, а ваш контракт истечет через 11 месяцев. Более того, этот жирный документ имеет нулевое или близкое к нулю значение для вашей карьеры (как и многие другие вещи: администрация и преподавание - два примера). Конечно, об Agile-методах говорить не приходится. Большая часть разработки осуществляется группами, находящимися далеко, и, как правило, у них также есть много других дел. Концентрация на кодировании проявляется в виде коротких всплесков в «свободное время» между статьями, а также до или после встреч. Базар скорее всего, но на базаре тоже много проблем.
Итак, отвечая на ваш вопрос, лучшая стратегия - это «медленное накопление» известного хорошего программного обеспечения, разработка небольшими пакетами с использованием быстрых и гибких методов и языка. Хорошие методы кодирования необходимо преподавать во время лекций, так как хорошие лабораторные практики преподаются во время практических занятий (например, никогда не наливайте воду в серную кислоту, всегда наоборот)