Zitierte Referenzen für Best Practices für Software

14

Ich schreibe gerade meine Doktorarbeit. Ich habe einen erheblichen Teil meiner Doktorarbeit damit verbracht, vorhandenen wissenschaftlichen Code zu bereinigen und zu erweitern, indem ich Best Practices des Software-Engineerings angewendet habe, die zuvor nicht verwendet wurden, und möchte in meiner Arbeit darüber schreiben. Anstatt einfach "Ich habe Unit-Tests hinzugefügt" zu sagen, möchte ich in der Lage sein, so etwas zu schreiben:

J. Doe erfand 1975 Unit-Tests [ 23 ] . Eine aktuelle Studie von Bloggs et al. [ 24 ] hat gezeigt, dass Unit-Tests die Häufigkeit von Softwarefehlern um 73% reduzieren ... 234 separate Unit-Tests wurden zur Codebasis hinzugefügt, die von dem von Timpkins et al. [ 25 ] erstellten xUnit-Framework verwaltet wird.[23][24][25]

Ich suche nach zitierbaren wissenschaftlichen Referenzen (vorzugsweise Artikeln in begutachteten Fachzeitschriften, in denen ich DOIs, BibTeX usw. erhalten kann) zu allgemein anerkannten Best Practices für das Software-Engineering, insbesondere:

  • Unit-Tests
  • Versionskontrolle
  • Modularisierung / Trennung von Anliegen
  • Leistungsprofilerstellung / -optimierung basierend auf Profilinformationen
  • Bug / Issue Tracking

Ich suche Informationen sowohl über die ursprüngliche Erfindung als auch über nachfolgende Bewertungen der Wirksamkeit. Wenn es einen Übersichtsartikel gibt, der all diese Dinge an einem Ort auflistet, dann umso besser.

user1915639
quelle
1
Hilft das: plosbiology.org/article/…
akid
Wenn der Zweck des Hinzufügens von Referenzen darin besteht, die Leser davon zu überzeugen, dass bessere Praktiken besser sind, ist es möglicherweise sinnvoller zu erklären, warum sie direkt besser sind. Nur Referenzen zu nennen, könnte weniger überzeugend sein. Bedenken Sie, dass viele dieser Dinge in Studiengängen zum Thema Software-Engineering häufig vorkommen, in Standardlehrbüchern zu finden sind und nicht unbedingt auf dem neuesten Stand der Forschung sind.
Kirill
Ich habe die Erfahrung gemacht, dass Sie sowohl Motivation als auch Referenzen benötigen. Ich hatte gestern gerade ein Gespräch mit Kollegen (beide praktizierende Wissenschaftler), die der Meinung waren, dass Ad-hoc-Testmethoden besser funktionieren (kurze Antwort: sie tun es nicht). Es ist wichtig, die Motivation in Form von Metriken auszudrücken, um die sich Computerwissenschaftler offenbar zu kümmern scheinen: schnellere und korrektere Ergebnisse bei Arbeiten mit höherer Auswirkung (siehe den Link zur reproduzierbaren Forschung). Verweisen Sie auf Referenzen, da die Leute Sie in diesen Punkten bekämpfen und behaupten, dass es keine wesentlichen Vorteile gibt.
Geoff Oxberry
Höchstwahrscheinlich sind die Leute, die meine Doktorarbeit prüfen, Professoren für Chemie oder Materialwissenschaften und keine Experten für Computerwissenschaften. Sie werden wahrscheinlich einige Erfahrung mit dem Schreiben von Code haben, aber sie werden mit ziemlicher Sicherheit keine ernsthaften Codierungen vorgenommen haben, da sie selbst Studenten oder frühe Post-Docs waren. Was ich brauche, ist etwas, das sagt: "In dem Jahr meiner Promotion, das ich damit verbracht habe, habe ich tatsächlich etwas Nützliches getan und nicht nur
nachgelassen

Antworten:

13

Steve McConnells Buch Code Complete, 2. Auflage, enthält eine umfangreiche Bibliographie, in der diese Themen eher vom Standpunkt der Softwareentwickler als der Computerwissenschaftler aus erörtert werden. Das Buch fängt an, ein wenig älter zu werden, da es sich einem Jahrzehnt nähert, sodass neuere Testmethoden wie die verhaltensgesteuerte Entwicklung nicht mehr behandelt werden. Trotzdem kommt es einem umfassenden Übersichtsartikel über Software-Erstellung, der mir bekannt ist, am nächsten. Sie können auch nach Artikeln in IEEE-Software suchen.

Auf der rechnerwissenschaftlichen Seite denke ich, dass der beste Artikel wahrscheinlich die PLoS-Version des Vorabdrucks von arXiv ist, den David Ketcheson zum Thema "Best Practices for Scientific Computing" zitiert hat. Ich sage dies aus einem technischen Hintergrund, in dem weniger Leute arXiv-Referenzen oder Post-arXiv-Preprints zitieren und daher einen "echten Zeitschriftenartikel" zitieren ) wird günstiger angeschaut (und ich habe den Eindruck, dass diese Autoren beschlossen haben, es in einer Zeitschrift zu veröffentlichen).

Die Autoren des von David Ketcheson und mir zitierten PLoS-Papers sind Teil einer Organisation namens Software Carpentry , die (in der Regel zweitägige) "Bootcamps" veranstaltet, um Wissenschaftlern einige bewährte Verfahren für die Softwareentwicklung und nützliche Rechenfähigkeiten für Wissenschaftler (nicht nur) beizubringen Informatiker). Die Website von Software Carpentry enthält eine umfangreiche Bibliographie zur Softwareentwicklung in der Wissenschaft. Wenn Sie an diesen Themen interessiert sind, ermutige ich Sie, sich mit ihnen in Verbindung zu setzen. Sie sind immer auf der Suche nach mehr Befürwortern von Best Practices in der Softwareentwicklung, um Freiwilligenarbeit in verschiedenen Funktionen leisten zu können. ( Haftungsausschluss : Ich melde mich freiwillig bei Software Carpentry.)

Eine weitere häufige Rechtfertigung für die Teilnahme an Best Practices für die Softwareentwicklung ist die Reproduzierbarkeit. Victoria Stodden hat eine lange Liste reproduzierbarer Forschungsreferenzen zusammengestellt , die je nach dem, was Sie sagen möchten, von Interesse sein können.

Geoff Oxberry
quelle
Die Leseliste "Software Carpentry" sieht hilfreich aus.
user1915639
6

Ich habe keine Referenzen für die Herkunft dieser Ideen / Praktiken. Aber hier sind einige sehr aktuelle, relevante Referenzen:

David Ketcheson
quelle
Ich bin definitiv der Zweite dieser Referenzen :-) Die vollständigen Informationen stammen von Wolfgang Bangerth, Timo Heister. Was macht Open-Source-Softwarebibliotheken erfolgreich? Computational Science & Discovery, vol. 6, Artikel 015010 (18 Seiten), 2013
Wolfgang Bangerth
-2

IMHO würde ich sehr darauf achten, "Best Practices" im Kontext wissenschaftlich erprobter Ansätze zu zitieren. Die meisten Praktiken leiten sich eher von dem ab, "was für eine Reihe von Projekten von jemandem, der als Guru in diesen Projekten involviert ist, zu funktionieren scheint", als von strengen Tests verschiedener Ansätze. Es gibt einfach zu viele Variablen und menschliche Faktoren im Software-Engineering, um anzugeben, dass es eine referenzierbare Liste von "Best Practices" gibt (z. B. schlägt eine Praxis, die an einem Projekt arbeitet, an einem anderen vollständig fehl).

Ich würde mich dem nähern, indem ich erkläre, was für ein Projekt erforderlich ist, warum es erforderlich ist, und Verweise auf verwendete Methoden hinzufüge und warum Sie sie verwendet haben.

Ich möchte auch eher quantifizierbare Ergebnisse melden als Verweise, um Ihren Standpunkt darzulegen. Wenn Ihr Unit-Test beispielsweise 100 Bugs aufgedeckt hat, von denen 10 schwerwiegend genug sind, um das zuvor veröffentlichte Ergebnis in Frage zu stellen. Dies ist eine viel aussagekräftigere Aussage in Ihrer Promotion als eine Aussage, dass Sie den Ursprung von Unit-Tests kennen.

edit: (fester Tippfehler) - Beantworte Folgendes - Ich gebe oft Kindererziehung als Analogie zu Softwareprojekten. Es gibt viele Methoden und getestete Methoden, um sie zu erziehen. Wenn Sie versuchen, Ihre Kinder mit einer Methode zu erziehen, da dies für den Durchschnitt oder eine getestete Teilstichprobe funktioniert, funktioniert dies, solange Ihr Kind mit der getesteten Methode identisch ist. Es ist besser, viele Methoden zu kennen und diejenigen anzuwenden, die in Ihrer Instanz funktionieren. Ja, Unit-Tests können bewiesen werden, aber wenn Sie sie nur auf dieser Grundlage anwenden, kann dies bedeuten, dass Ihr Projekt zu spät auf den Markt kommt und daher sein Ziel verfehlt (wenn dies das Ziel ist). Ich sage, dass es meiner Meinung nach in einer Abschlussarbeit besser ist, eine Methode anzuwenden, um ein Ergebnis zu erzielen und das Ergebnis dieses Ergebnisses anzugeben, als Dinge aufzulisten, die Sie anhand anderer Projekte versucht haben - es sei denn, das Thema der Abschlussarbeit ist natürlich die Messung von Methoden :)

Internetscooter
quelle
1
Tatsächlich wurden in Studien Strategien zur Fehlererkennung wie Unit-Tests, Paarprogrammierung, Durchlaufen eines Programms mit einem Debugger sowie formale Codeüberprüfung verglichen und deren Wirksamkeit bewertet. Sie haben Recht, dass jede Strategie ihren Platz hat. Die Softwareentwickler-Community erkennt diesen Punkt in der Literatur an und schlägt vor, was für verschiedene Projekttypen am besten geeignet ist. Wenn "zu viele Variablen und menschliche Faktoren" wirklich ein Hindernis für die Formulierung von Best Practices wären, hätten wir sie nicht in der Medizin oder in anderen Bereichen mit ähnlich komplexen Problemen, aber wir tun es. Ich kaufe dein Argument nicht.
Geoff Oxberry
„ein brei mächtige Erklärung in Ihrem PhD“ ist ein schöner Typo
denis