Поважні посилання на найкращі практики програмного забезпечення

Зараз я пишу кандидатську дисертацію. Я витратив значну частину свого доктора на очищення та розширення існуючого наукового коду, застосувавши найкращі практики інженерії програмного забезпечення, які раніше не використовувалися, і хотів би написати про це у своїй дипломній роботі. Замість того, щоб просто сказати "Я додав одиничні тести", я хочу вміти написати щось подібне:

Дж. Доу винайшов одиничні тести в 1975 році [ 23 ] . Недавнє дослідження Bloggs et al. [ 24 ] показало, що одиничні тести знижують частоту помилок програмного забезпечення на 73% ... 234 окремі тестові одиниці були додані до кодової бази, керованої рамкою xUnit, створеною Timpkins et al. [ 25 ]$^{[23]}$$^{[24]}$$^{[25]}$

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

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

Я шукаю інформацію як про початковий винахід, так і про подальші оцінки ефективності. Якщо є оглядова стаття, в якій перераховано все це в одному місці, то тим краще, тим краще.

Книга Кодексу Стіва МакКоннелла, повне видання має велику бібліографію, що обговорює ці питання з більшої точки зору розробників програмного забезпечення, ніж з комп'ютерних вчених. Книга починає трохи старіти, оскільки наближається до десятиліття, тому вона не охоплює новітні методики тестування, такі як розвиток, орієнтований на поведінку. Тим не менш, це мені найближча інформація до всеосяжної оглядової статті про побудову програмного забезпечення, про яку я знаю. Ви також можете шукати статті в IEEE Software.

Що стосується обчислювальної науки, я вважаю, що найкращою статтею є, мабуть, версія PLoS для препринта arXiv, яку DavidKetcheson цитував у розділі "Кращі практики для наукових обчислень". Я кажу, що це відбувається з інженерного походження, де менше людей цитують посилання на arXiv або публікують препринти arXiv, і, таким чином, цитуючи "реальну статтю журналу" (відкладаючи, звичайно, всі питання про наукові публікації, про які зараз дискутується). ) сприймається більш прихильно (і я створюю враження, що саме тому ці автори вирішили опублікувати це в журналі).

Автори статті PLoS, яку ми цитували DavidKetcheson, є частиною організації під назвою Software Carpentry, яка проводить (як правило, 2 дні) "завантажувальні табори", щоб навчити вчених деяким найкращим практикам розробки програмного забезпечення та корисним обчислювальним навичкам для вчених (не тільки вчені-обчислювачі). На веб-сайті Software Carpentry є велика бібліографія, що стосується розробки програмного забезпечення в науці. Якщо вас цікавлять ці питання, я рекомендую вам звернутися до них; вони завжди шукають більше прихильників кращих практик в розробці програмного забезпечення, щоб робити волонтерство в різних можливостях. ( Відмова від відповідальності : Я добровольцем займаюся програмою "Столярні програми".)

Ще одне поширене виправдання для залучення до кращих практик розробки програмного забезпечення - відтворюваність. Вікторія Стодден підготувала довгий список відтворюваних посилань на дослідження, які можуть бути цікавими, залежно від того, що ви хочете сказати.

У мене немає посилань на походження кожної з цих ідей / практик. Але ось кілька останніх релевантних посилань:

• Що робить обчислювальну бібліотеку програмного забезпечення з відкритим кодом успішною?
• Кращі практики наукових обчислень

ІМХО я б дуже обережно посилався на "Кращі практики" в контексті науково доведених підходів. Більшість практик походить із "того, що, здається, працює для набору проектів кимсь, кого сприймають як гуру, залученого до цих проектів", а не виходить із жорсткого тестування різних підходів. Існує занадто багато змінних та людських факторів в інженерії програмного забезпечення, щоб стверджувати, що існує перелік "найкращих практик" (наприклад, практика, яка працює над одним проектом, повністю провалиться на інший).

Я підійшов би до цього, зазначивши, що потрібно вашому проекту, навіщо він потрібен та додав посилання на використовувані методи та чому ви їх використовували.

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

редагувати: (фіксована помилка) - Відповідаючи на таке - я часто даю вихованню дітей як аналогію програмним проектам. Існує багато методів і перевірених способів їх виховання, намагаючись виховати своїх дітей одним методом, оскільки він працює для середнього або тестованого підпробору, працюватиме до тих пір, поки ваша дитина буде такою ж, як перевірена. Краще знати багато методів і застосувати ті, які працюють у вашому екземплярі. Так, тестування приладів може бути доведено, але застосування його на основі лише цього може означати, що ваш проект пізно виходить на ринок, і тому не вдається його об'єктивно (якщо це є ціллю). Я кажу, що застосовувати метод для отримання результату і давати результат цього результату, на мою думку, це краще в дипломній роботі, ніж перелік речей, які ви спробували на основі інших проектів - якщо, звичайно, тема дисертації не є методологією вимірювання. :)