Полезные ссылки на лучшие практики программного обеспечения

14

В настоящее время я пишу свою докторскую диссертацию. Я потратил значительную часть своей докторской степени на очистку и расширение существующего научного кода, применяя лучшие методы разработки программного обеспечения, которые ранее не использовались, и хотел бы написать об этом в своей диссертации. Вместо того, чтобы просто сказать «я добавил юнит-тесты», я хочу написать что-то вроде этого:

Дж. Доу изобрел модульные тесты в 1975 году [ 23 ] . Недавнее исследование, проведенное Bloggs и соавторами [ 24 ], показало, что модульные тесты снижают частоту программных ошибок на 73% ... 234 отдельных модульных теста были добавлены в базу кода, управляемую платформой xUnit, созданной Timpkins et al [ 25 ].[23][24][25]

Я ищу цитируемые академические ссылки (предпочтительно статьи в рецензируемых журналах, где я могу получить DOI, BibTeX и т. Д.) На общепринятые лучшие практики разработки программного обеспечения, в частности:

  • модульные тесты
  • контроль версий
  • модульность / разделение интересов
  • профилирование / оптимизация производительности на основе информации профилирования
  • отслеживание ошибок / проблем

Я ищу информацию как о первоначальном изобретении, так и о последующих оценках эффективности. Если есть обзорная статья, которая перечисляет все эти вещи в одном месте, то тем лучше.

user1915639
источник
1
Поможет ли это: plosbiology.org/article/...
AKID
Если цель добавления ссылок состоит в том, чтобы убедить читателей в том, что лучшие практики лучше, возможно, имеет смысл объяснить, почему они лучше непосредственно; просто давать ссылки могут быть менее убедительными. Имейте в виду, что многие из этих вещей распространены на курсах по разработке программного обеспечения для студентов, могут быть найдены в стандартных учебниках и не обязательно являются передовыми исследованиями.
Кирилл
Мой опыт показывает, что вам нужны мотивация и рекомендации. Вчера я только что разговаривал с коллегами (оба из которых являются практикующими учеными), которые считали, что специальные методики тестирования работают лучше (короткий ответ: они не работают). Важно выразить мотивацию в терминах метрик, которые, по-видимому, интересуют вычислительных специалистов: более быстрое воздействие документов и более правильные результаты (см. Ссылку на воспроизводимые исследования). Укажите ссылки, потому что люди будут бороться с вами по этим пунктам, утверждая, что никаких существенных преимуществ нет.
Джефф Оксберри
По всей вероятности, люди, которые будут рассматривать мою диссертацию, будут профессорами химии или материаловедения, а не специалистами в области вычислительной техники. Вероятно, у них будет некоторый опыт написания кода, но они почти наверняка не будут заниматься каким-либо серьезным кодированием, так как сами были студентами или первыми постдоков. Мне нужно что-то, что говорит: «В тот год моего доктора наук, который я потратил на это, я действительно делал что-то полезное, а не просто
расслаблялся

Ответы:

13

Книга Стива Макконнелла Code Complete, 2-е издание, содержит обширную библиографию, в которой обсуждаются эти вопросы с точки зрения разработчиков программного обеспечения, а не ученых-вычислительных машин. Книга начинает устареть, поскольку ей уже около десяти лет, поэтому она не охватывает более современные методики тестирования, такие как разработка на основе поведения. Тем не менее, это самая близкая статья к всеобъемлющей обзорной статье о разработке программного обеспечения, о которой я знаю. Вы также можете искать статьи в IEEE Software.

С точки зрения вычислительной науки, я думаю, что лучшей статьей, вероятно, является PLoS-версия препринта arXiv DavidKetcheson, на который ссылается «Best Practices for Scientific Computing». Я говорю это из инженерной среды, где меньше людей цитируют ссылки на arXiv или препринты arXiv, и, таким образом, ссылаются на «настоящую журнальную статью» (за исключением, конечно, всех вопросов о научной публикации, которые обсуждаются сейчас ) рассматривается более благоприятно (и у меня сложилось впечатление, что именно поэтому эти авторы решили опубликовать его в журнале).

Авторы статьи PLoS, которую мы с Дэвидом Кетчоном назвали, являются частью организации Software Carpentry , которая организует (обычно 2 дня) «учебные лагеря» для обучения ученых передовым методам разработки программного обеспечения и полезным вычислительным навыкам для ученых (не только вычислительные ученые). Веб-сайт Software Carpentry содержит обширную библиографию, связанную с разработкой программного обеспечения в науке. Если вы заинтересованы в этих вопросах, я призываю вас обратиться к ним; они всегда ищут больше сторонников лучших практик в разработке программного обеспечения, чтобы заниматься волонтерством в различных сферах. ( Отказ от ответственности : я добровольно сотрудничаю с Software Carpentry.)

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

Джефф Оксберри
источник
Список чтения "Software Carpentry" выглядит полезным.
user1915639
6

У меня нет ссылок на происхождение каждой из этих идей / практик. Но вот несколько очень актуальных ссылок:

Дэвид Кетчесон
источник
Я определенно вторую первую из этих ссылок :-) Это полная информация Вольфганга Бангерта, Тимо Хейстера. Что делает вычислительные библиотеки с открытым исходным кодом успешными? Вычислительная наука и открытие, том. 6, статья 015010 (18 страниц), 2013 год
Вольфганг Бангерт
-2

ИМХО, я бы с большой осторожностью цитировал «Best Practices» в контексте научно обоснованных подходов. Большинство практик основано на «том, что, по-видимому, работает для ряда проектов кем-то, кто воспринимается как гуру, участвующий в этих проектах», а не на основе тщательного тестирования различных подходов. В разработке программного обеспечения слишком много переменных и человеческих факторов, чтобы утверждать, что существует реальный список «лучших практик» (например, практика, которая работает в одном проекте, полностью провалится в другом).

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

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

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

internetscooter
источник
1
На самом деле, исследования сравнивали стратегии обнаружения дефектов, такие как модульное тестирование, парное программирование, пошаговое выполнение программы с отладчиком и анализ формального кода, и оценивали их эффективность. Вы правы, что каждая стратегия имеет свое место. Сообщество разработчиков программного обеспечения признает этот момент в литературе и предлагает то, что может работать лучше всего для различных типов проектов. Если бы «слишком много переменных и человеческих факторов» были действительно препятствием для формулирования лучших практик, у нас не было бы их в медицине или других областях со схожими сложными проблемами, но мы делаем это. Я не покупаю ваш аргумент.
Джефф Оксберри
«а кашица более мощное заявление в вашем кандидате» является прекрасной опечаткой
денис