Wenn ihr einen Pull Request stellt, schreibt bitte dabei ob die Änderung geprüft werden soll (Review/Test) oder nicht.
Wenn es nicht geprüft wird, ist der Entwickler selbst dafür verantwortlich dass es funktioniert und muss sich dann ggf. auch selbständig um Bugreports und Bugfixes kümmern.
Wenn es geprüft werden soll bleibt der Pull Request solange offen, bis jemand die Änderungen geprüft (= korrekturgelesen und getestet) und freigegeben hat. Die Prüfung kann jeder übernehmen, der
* über ein funktionierendes OC-Entwicklersystem verfügt,
* selbst schon Codeänderungen zu OC beigesteuert hat und
* in der Lage wäre, eventuelle Bugs im geprüften Code selbst zu korrigieren.
Er ist dann mitverantwortlich dafür, dass die Änderung funktioniert. Das Ergebnis der Prüfung dann bitte als Kommentar in den Pull Request schreiben.
Beiträge von Nicht-Teammitgliedern und von neuen Entwicklern müssen immer geprüft werden.
Weitere Vorgehensweise bei der Codefreigabe
-
ClanFamily (Mirco)
- Administrator
- Beiträge: 1413
- Registriert: 03.09.2012, 21:55
Ich denke ich würde mir den Schritt einmal genauer anschauen wollen.
Eine Sache jedoch - wenn ein Entwickler einen Bug/Fehler im Script hat und dieser nicht in wenigen Minuten durch den CodeReviewer beseitigt werden kann (z.B. Typo-fehler) dann sollte der Entwickler eine Negativprüfung erhalten und sein Script noch mal nachgehen. Ich denke, dass das Eindenken in ein Script die meiste Zeit raubt und zu letzt Peter damit viel arbeit hatte.
Ich sehe es schon in der Verantwortung des jeweiligen Entwicklers, dass das, was er programmiert auch laufen muss. Als CodeReviewer hat man zuletzt die Fehlerprüfung und ein Auge darauf, dass keine Backdoors eingearbeitet werden. Dazu überwacht er die Struktur der Programmierung.
Ich denke, dass der Reviewprozess auch von Redmine begleitet werden kann.
Programmiert man etwas, dass nicht in Redmine als Ticket existiert, sollte man ein Ticket mit Beschreibung etc einführen.
Eine Sache jedoch - wenn ein Entwickler einen Bug/Fehler im Script hat und dieser nicht in wenigen Minuten durch den CodeReviewer beseitigt werden kann (z.B. Typo-fehler) dann sollte der Entwickler eine Negativprüfung erhalten und sein Script noch mal nachgehen. Ich denke, dass das Eindenken in ein Script die meiste Zeit raubt und zu letzt Peter damit viel arbeit hatte.
Ich sehe es schon in der Verantwortung des jeweiligen Entwicklers, dass das, was er programmiert auch laufen muss. Als CodeReviewer hat man zuletzt die Fehlerprüfung und ein Auge darauf, dass keine Backdoors eingearbeitet werden. Dazu überwacht er die Struktur der Programmierung.
Ich denke, dass der Reviewprozess auch von Redmine begleitet werden kann.
Programmiert man etwas, dass nicht in Redmine als Ticket existiert, sollte man ein Ticket mit Beschreibung etc einführen.
-
following
[quote="ClanFamily (Mirco)"]
Ich sehe es schon in der Verantwortung des jeweiligen Entwicklers, dass das, was er programmiert auch laufen muss. [/quote]
Jup, das sehe ich auch so. Dass der Reviewer den Code selbst korrigieren können sollte bezog sich mehr auf die Qualifikation - wer etwas prüft muss davon soviel verstehen, dass er es im Prinzip auch selbst programmieren könnte.
Mir geht's vor allem darum, die Verantwortung für Prüfung und Freigabe von Code zu verteilen. Wir haben nach wie vor keinen Projektmanager, Stategievorstand oder Entwicklungsvorstand der dafür zuständig wäre, also muss diese Aufgabe durch das "Entwicklerkollektiv" gemeinsam wahrgenommen werden.
Ich sehe es schon in der Verantwortung des jeweiligen Entwicklers, dass das, was er programmiert auch laufen muss. [/quote]
Jup, das sehe ich auch so. Dass der Reviewer den Code selbst korrigieren können sollte bezog sich mehr auf die Qualifikation - wer etwas prüft muss davon soviel verstehen, dass er es im Prinzip auch selbst programmieren könnte.
Mir geht's vor allem darum, die Verantwortung für Prüfung und Freigabe von Code zu verteilen. Wir haben nach wie vor keinen Projektmanager, Stategievorstand oder Entwicklungsvorstand der dafür zuständig wäre, also muss diese Aufgabe durch das "Entwicklerkollektiv" gemeinsam wahrgenommen werden.