Praktikum SDE Code Reviews: Unterschied zwischen den Versionen
Zur Navigation springen
Zur Suche springen
Keine Bearbeitungszusammenfassung |
Keine Bearbeitungszusammenfassung |
||
| (41 dazwischenliegende Versionen von 5 Benutzern werden nicht angezeigt) | |||
| Zeile 1: | Zeile 1: | ||
Autor: [[Benutzer:Ulrich_Schneider| Prof. Schneider]] | |||
== Einleitung == | == Einleitung == | ||
Mit dem Review werden Arbeitsergebnisse der Softwareentwicklung manuell geprüft. Jedes Arbeitsergebnis kann einer Durchsicht durch eine andere Person unterzogen werden. Der oder das Review ist eine statische Testmethode und gehört in die Kategorie der analytischen Qualitätssicherungsmaßnahmen. | Mit dem Review werden Arbeitsergebnisse der Softwareentwicklung manuell geprüft. Jedes Arbeitsergebnis kann einer Durchsicht durch eine andere Person unterzogen werden. Der oder das Review ist eine statische Testmethode und gehört in die Kategorie der analytischen Qualitätssicherungsmaßnahmen. | ||
| Zeile 6: | Zeile 8: | ||
Der untersuchte Gegenstand eines Reviews kann verschieden sein. Es wird vor allem zwischen einem Code-Review (Quelltext) und einem Architektur-Review (Softwarearchitektur, insbesondere Design-Dokumente) unterschieden. Diesen Bereichen zugeordnet sind technische Dokumente wie etwa Readmes, Installationsanweisungen oder Bedienungsanleitungen, aber auch Programme oder Skripte, die für eine Installation gebraucht werden, sowie Dokumente mit Informationen und Anweisungen an andere, ähnlich qualifizierte Entwickler, um diese zu befähigen, den Übersetzungsvorgang der Quellen zu einem späteren Zeitpunkt erfolgreich zu reproduzieren, etwa für ein Bug-Fixing (Fehlerkorrektur) oder eine Weiterentwicklung. | Der untersuchte Gegenstand eines Reviews kann verschieden sein. Es wird vor allem zwischen einem Code-Review (Quelltext) und einem Architektur-Review (Softwarearchitektur, insbesondere Design-Dokumente) unterschieden. Diesen Bereichen zugeordnet sind technische Dokumente wie etwa Readmes, Installationsanweisungen oder Bedienungsanleitungen, aber auch Programme oder Skripte, die für eine Installation gebraucht werden, sowie Dokumente mit Informationen und Anweisungen an andere, ähnlich qualifizierte Entwickler, um diese zu befähigen, den Übersetzungsvorgang der Quellen zu einem späteren Zeitpunkt erfolgreich zu reproduzieren, etwa für ein Bug-Fixing (Fehlerkorrektur) oder eine Weiterentwicklung. | ||
Beim Code-Review wird ein Programmabschnitt nach oder während der Entwicklung von einem oder mehreren Gutachtern Korrektur gelesen, um mögliche Fehler, Vereinfachungen oder Testfälle zu finden. Dabei kann der Gutachter selbst ein Softwareentwickler sein. Für unerfahrene Entwickler bietet der Code-Review durch einen erfahrenen Programmierer eine gute Möglichkeit, sich schnell und praxisorientiert weiterzubilden | Beim Code-Review wird ein Programmabschnitt nach oder während der Entwicklung von einem oder mehreren Gutachtern Korrektur gelesen, um mögliche Fehler, Vereinfachungen oder Testfälle zu finden. Dabei kann der Gutachter selbst ein Softwareentwickler sein. Für unerfahrene Entwickler bietet der Code-Review durch einen erfahrenen Programmierer eine gute Möglichkeit, sich schnell und praxisorientiert weiterzubilden. | ||
==Ihre Aufgaben== | ==Ihre Aufgaben == | ||
* Recherchieren Sie was ein Code Review ist und wie dieses durchgeführt werden kann. | * Recherchieren Sie was ein [[Anleitung_zum_Code_Review|Code Review]] ist und wie dieses durchgeführt werden kann (s. Weblinks und Literatur). | ||
* Tragen Sie ihr Modul mit Link in die Tabelle ein, welches zu reviewen ist. | * Tragen Sie ihr Modul mit Link in die Tabelle ein, welches zu reviewen ist. | ||
* Tragen Sie sich als | * Tragen Sie sich als Prüfer ein. | ||
* Führen Sie das Review anhand der Vorlage durch und dokumentieren Sie es hier: <code>https://svn.hshl.de/svn/MTR_SDE_Praktikum/trunk/Testdokumente/CodeReviews/</code> | * Führen Sie das Review anhand der Vorlage durch und dokumentieren Sie es hier: <code>https://svn.hshl.de/svn/MTR_SDE_Praktikum/trunk/Testdokumente/CodeReviews/</code> | ||
* Optimieren Sie Ihren Quelltext anhand des Code Reviews. | * Optimieren Sie Ihren Quelltext anhand des Code Reviews. | ||
* | * Besprechen Sie bis zur Deadline 20.12.19 das Ergebnis mit Prof. Schneider. | ||
== Review Zuordnung == | == Review Zuordnung == | ||
| Zeile 23: | Zeile 23: | ||
! # !! Modul !! Autor !! Review von !! Datum | ! # !! Modul !! Autor !! Review von !! Datum | ||
|- | |- | ||
| 1 || | | 1 || [[BSF - Bahn- und Spurführung]] [https://svn.hshl.de/svn/MTR_SDE_Praktikum/trunk/Testdokumente/Unittests/BSF/3210_Verhalten_an_Stopp-Kreuzung/ SVN]||[[Benutzer:Yanick-Christian_Tchenko|Yanick Christian Tchenko]]|| [[Benutzer:Tim-Leonard_Bexten|Tim Leonard Bexten]] || | ||
|- | |- | ||
| 2 || | | 2 || [[SenKam_-_Stopplinienerkennung]] [https://svn.hshl.de/svn/MTR_SDE_Praktikum/branches/2019_10_11_BSF_Stopplinienverhalten/Marcel_Broeckelmann_Arbeitsordner/CaroloCupFahrzeug/bibliotheken/ SVN] || [[Benutzer:Marcel_Broeckelmann|Marcel Bröckelmann]] || [[Benutzer:Luca Di-Lillo|Luca Di Lillo]] || 14.12.2019 | ||
|- | |- | ||
| 3 || || | | 3 ||[[Bildentzerrung und KOS-Transformation]] Teil 1 [https://svn.hshl.de/svn/MTR_SDE_Praktikum/trunk/Teams/OSE/OSE_Bexten_Di_Lillo/OSE_Bahnspurpolynom/Bahnspurpolynom_verlinkt SVN] || [[Benutzer:Tim-Leonard_Bexten|Tim Leonard Bexten]] und [[Benutzer:Luca Di-Lillo|Luca Di Lillo]] || [[Benutzer:Marcel_Broeckelmann|Marcel Bröckelmann]] || | ||
|- | |- | ||
| 4 || || | | 4 || [[Bildentzerrung und KOS-Transformation]] Teil 2 [https://svn.hshl.de/svn/MTR_SDE_Praktikum/trunk/Teams/OSE/OSE_Bexten_Di_Lillo/OSE_Bahnspurpolynom/Bahnspurpolynom_verlinkt SVN]|| [[Benutzer:Tim-Leonard_Bexten|Tim Leonard Bexten]] und [[Benutzer:Luca Di-Lillo|Luca Di Lillo]] || [[Benutzer:Yanick-Christian_Tchenko|Yanick Christian Tchenko]] || 19.12.2019 | ||
|} | |} | ||
== Vorgehensweise bei der statischen Codeanalyse == | |||
# Walktrough | |||
# Inspektion | |||
== Ablauf Code-Review== | |||
# Autor stellt den Quellcodes bereit. | |||
# Autor initiiert eine Code Review Anfrage. | |||
# Autor führt den Prüfer durch den Code (Walktrough). | |||
# Prüfer identifiziert Probleme (Inspektion). | |||
# Prüfer prüft den Code und dokumentiert die Funde (Code_Review_Vorlage.docx). | |||
# Prüfer gibt das Dokument an den Autor zurück. | |||
# Autor arbeitet Befunde ein. | |||
# Autor initiiert eine neue Runde des Review-Prozesses (GOTO 1). | |||
== Weblinks == | |||
* [[Anleitung_zum_Code_Review|HSHL-Wiki: Anleitung zum Code Review]] | |||
* [https://de.wikipedia.org/wiki/Review_(Softwaretest) Wikipedia: Review (Softwaretest)] | |||
* [https://www.doag.org/formes/pubfiles/6774263/2015-null-Rabea_Gransberger-Code_Reviews__Techniken_und_Tipps-Praesentation.pdf Code Reviews: Techniken und Tipps] | |||
* [https://www.johner-institut.de/blog/fda/code-review/ Code Review - Checkliste, Tools & Guidelines] | |||
* [https://svn.hshl.de/svn/MTR_SDE_Praktikum/trunk/Testdokumente/CodeReviews/Code_Review_Vorlage.docx Word SVN: Vorlage für Code Reviews] | |||
== Literatur == | == Literatur == | ||
| Zeile 37: | Zeile 58: | ||
* Understanding Open Source Software Peer Review: Review Processes, Parameters and Statistical Models, and Underlying Behavioursand Mechanisms, Rigby, Dissertation, 2011 | * Understanding Open Source Software Peer Review: Review Processes, Parameters and Statistical Models, and Underlying Behavioursand Mechanisms, Rigby, Dissertation, 2011 | ||
* Mäntylä, M.; LASSENIUS, C.: Code Review Defects. IEEE 2007. URL: http://lib.tkk.fi/Diss/2009/isbn9789512298570/article5.pdf | * Mäntylä, M.; LASSENIUS, C.: Code Review Defects. IEEE 2007. URL: http://lib.tkk.fi/Diss/2009/isbn9789512298570/article5.pdf | ||
* Dukanivic, S.: [https://svn.hshl.de/svn/MTR_SDE_Praktikum/trunk/Testdokumente/CodeReviews/D08-QM-3-Prozesse-Code-Reviews-und-Dokumentationsqualitaet.pdf D08-QM-3 Prozessbeschreibung zur Durchführung von Code-Reviews und Sicherstellung der Dokumentationsqualität]. Darmstadt: Technischer Bericht, 21.06.2013 | |||
---- | |||
→ zurück zum Hauptartikel: [[Praktikum_SDE|Praktikum SDE]] | |||
Aktuelle Version vom 3. Januar 2020, 15:09 Uhr
Autor: Prof. Schneider
Einleitung
Mit dem Review werden Arbeitsergebnisse der Softwareentwicklung manuell geprüft. Jedes Arbeitsergebnis kann einer Durchsicht durch eine andere Person unterzogen werden. Der oder das Review ist eine statische Testmethode und gehört in die Kategorie der analytischen Qualitätssicherungsmaßnahmen.
In Anlehnung an die IEEE-Norm 729 ist das Review ein mehr oder weniger formal geplanter und strukturierter Analyse- und Bewertungsprozess, in dem Projektergebnisse einem Team von Gutachtern präsentiert und von diesem kommentiert oder genehmigt werden.
Der untersuchte Gegenstand eines Reviews kann verschieden sein. Es wird vor allem zwischen einem Code-Review (Quelltext) und einem Architektur-Review (Softwarearchitektur, insbesondere Design-Dokumente) unterschieden. Diesen Bereichen zugeordnet sind technische Dokumente wie etwa Readmes, Installationsanweisungen oder Bedienungsanleitungen, aber auch Programme oder Skripte, die für eine Installation gebraucht werden, sowie Dokumente mit Informationen und Anweisungen an andere, ähnlich qualifizierte Entwickler, um diese zu befähigen, den Übersetzungsvorgang der Quellen zu einem späteren Zeitpunkt erfolgreich zu reproduzieren, etwa für ein Bug-Fixing (Fehlerkorrektur) oder eine Weiterentwicklung.
Beim Code-Review wird ein Programmabschnitt nach oder während der Entwicklung von einem oder mehreren Gutachtern Korrektur gelesen, um mögliche Fehler, Vereinfachungen oder Testfälle zu finden. Dabei kann der Gutachter selbst ein Softwareentwickler sein. Für unerfahrene Entwickler bietet der Code-Review durch einen erfahrenen Programmierer eine gute Möglichkeit, sich schnell und praxisorientiert weiterzubilden.
Ihre Aufgaben
- Recherchieren Sie was ein Code Review ist und wie dieses durchgeführt werden kann (s. Weblinks und Literatur).
- Tragen Sie ihr Modul mit Link in die Tabelle ein, welches zu reviewen ist.
- Tragen Sie sich als Prüfer ein.
- Führen Sie das Review anhand der Vorlage durch und dokumentieren Sie es hier:
https://svn.hshl.de/svn/MTR_SDE_Praktikum/trunk/Testdokumente/CodeReviews/ - Optimieren Sie Ihren Quelltext anhand des Code Reviews.
- Besprechen Sie bis zur Deadline 20.12.19 das Ergebnis mit Prof. Schneider.
Review Zuordnung
| # | Modul | Autor | Review von | Datum |
|---|---|---|---|---|
| 1 | BSF - Bahn- und Spurführung SVN | Yanick Christian Tchenko | Tim Leonard Bexten | |
| 2 | SenKam_-_Stopplinienerkennung SVN | Marcel Bröckelmann | Luca Di Lillo | 14.12.2019 |
| 3 | Bildentzerrung und KOS-Transformation Teil 1 SVN | Tim Leonard Bexten und Luca Di Lillo | Marcel Bröckelmann | |
| 4 | Bildentzerrung und KOS-Transformation Teil 2 SVN | Tim Leonard Bexten und Luca Di Lillo | Yanick Christian Tchenko | 19.12.2019 |
Vorgehensweise bei der statischen Codeanalyse
- Walktrough
- Inspektion
Ablauf Code-Review
- Autor stellt den Quellcodes bereit.
- Autor initiiert eine Code Review Anfrage.
- Autor führt den Prüfer durch den Code (Walktrough).
- Prüfer identifiziert Probleme (Inspektion).
- Prüfer prüft den Code und dokumentiert die Funde (Code_Review_Vorlage.docx).
- Prüfer gibt das Dokument an den Autor zurück.
- Autor arbeitet Befunde ein.
- Autor initiiert eine neue Runde des Review-Prozesses (GOTO 1).
Weblinks
- HSHL-Wiki: Anleitung zum Code Review
- Wikipedia: Review (Softwaretest)
- Code Reviews: Techniken und Tipps
- Code Review - Checkliste, Tools & Guidelines
- Word SVN: Vorlage für Code Reviews
Literatur
- Gransberger, R.: Code Reviews: Techniken und Tipps. URL: https://speakerdeck.com/rgra
- Best Kept Secrets of Peer Code Review, Cohen, Smart Bear Inc., 2006
- Understanding Open Source Software Peer Review: Review Processes, Parameters and Statistical Models, and Underlying Behavioursand Mechanisms, Rigby, Dissertation, 2011
- Mäntylä, M.; LASSENIUS, C.: Code Review Defects. IEEE 2007. URL: http://lib.tkk.fi/Diss/2009/isbn9789512298570/article5.pdf
- Dukanivic, S.: D08-QM-3 Prozessbeschreibung zur Durchführung von Code-Reviews und Sicherstellung der Dokumentationsqualität. Darmstadt: Technischer Bericht, 21.06.2013
→ zurück zum Hauptartikel: Praktikum SDE