Schauen wir uns nochmal im Überblick an, bevor wir zum nächsten Abschnitt gehen.
Wir hatten also über die dynamischen Maßnahmen Tests, das war 3,
5 und jetzt machen wir weiter mit Reviews, Inspektionen.
Das ist demzufolge hier nicht 3, 4,
sondern das ist 3, 6. So, 3,
4 war dieser Überblick über die Maßnahmen.
Wenn wir dahin gehen, gibt es gleich zu Anfang
neue Fragen. Also wir erinnern uns ja hier,
vielleicht bevor ich das gehe, noch ein paar Worte.
Wir erinnern uns, dass wir hier sehr viel bessere,
wo war die schöne Tabelle
Genau, hier, dass wir bei den Tests das System ausführen halt,
das soll hier ja nicht sein,
dass wir das System ausführen und das Verhalten beobachten.
Das war gerade das, was Objektorientierung gerade ein bisschen schlechter machte, diese Beobachtbarkeit.
Die statischen Maßnahmen erlauben, funktionieren durch Begutachtung, das heißt,
Menschen schauen sich das an und es gab halt den Vorteil,
das können wir sehr viel früher machen, als wir ausführbares Zeug haben.
Hier drüben ging ja nur ausführbare Sachen und wir sind auch
sehr viel schneller, das heißt,
in zwei Stunden Review-Inspektionen schaffen wir mehr als in zwei
Stunden Test
Und das wollen wir uns jetzt genauer angucken, diese Reviews.
Und das ist der Abschnitt 3,6. Wir sind dann hier hinten
irgendwo bei den Folien. Ja, hier bin ich.
Da gibt es einen neuen Fragenteil dazu. Bei den Fragen
sollen wir zunächst erst mal Inspektionen morgens so gegenüberstellen.
Kotinspektionen, wo kommen die Kriterien her?
Und dann machen wir ein Beispiel für Ratbarkeit noch mal,
wann macht man welche Reviews und wie läuft sowas ab?
Was sind die Beteiligten? Reviews und Inspektionen
ist jetzt
unser Thema
Wenn wir mal dieses Bildchen, was wir vorhin hatten,
diese Baumstruktur, nochmal weiter anschauen.
Ich springe doch mal schnell zurück dahin, dass wir das nochmal sehen.
Hier war es, ja. So hatten wir gesehen,
dass es hier unten mehr Sachen gab.
Und das ist das, ich habe gesehen,
wir gucken uns, werden uns das im Detail angucken.
Aber jetzt doch nochmal, bevor wir dahin springen.
Moment,
wo war es
Sagen wir hier, was gibt es da? Vier Kategorien erstmal,
diese Review-Inspektionen, mit denen wir uns detaillierter beschäftigen wollen,
ist hier die zweite Kategorie, da geht es Gutachter,
irgendwie Experten analysieren, das Ganze beim Audit,
ist es auch wieder das Experten, das Tun,
das ist ja bei all diesen panalarelischen statischen Maßnahmen so,
aber hier geht es bei Audit den Begriff Audit verwendet man vor allen Dingen für die Prüfung zur Einhaltung von Vorgaben,
zum Beispiel lebensmittelmäßig von Themen auditiert oder hält man den Nachhaltigkeitssachen ein von irgendeinem Siegel oder ist man biomäßig arbeitet ein Landwirtschaftsbetrieb,
biomäßig.
Also was wird durch ein Audit geprüft? Dann gab es noch,
also diese Reviewer, das werden wir genauer nochmal anschauen,
da liegt etwas vor, wird begutachtet,
Walksro ist tatsächlich nicht sehr viel anders und das Walksro,
da gehen wir nur in einer bestimmten Sequenz durch.
Das heißt, wir laufen den Use-Case durch, durch so ein System,
sagen wir mal an, wir haben eine Architektur,
als Kästchen und Linien besteht, dann gehen wir diese Linie lang entsprechend eines Ablaufes.
Damit haben wir auch gleichzeitig diese erste Frage beantwortet,
stellen Sie Inspektionen in Wolfsburg gegenüber, Ja,
die haben sehr viele Gemeinsamkeiten, beides funktioniert mit Experten,
beides funktioniert mit etwas, was vorliegt und nicht ausführegeführt wird,
aber beim Wolfsburg machen wir das entlang Abläufen und bei dem Review,
da machen wir es irgendwie, wie die Gütochter das wollen,
von oben nach unten oder Block für Block oder Nachgröße oder nach Risiko oder was auch immer.
Gut, was mir, um nach der Vollständigkeit halber,
das sind eigentlich diese menschbasierten Sachen hier oben,
ich lüchte das durchaus auch noch erwähnen,
dass es noch weitere statische Maßnahmen gibt,
also statisch ist ja wohl das Prüfobjekt selbst nicht ausgeführt wird und es ist ein Korrektheitsbeweiser,
da wird der Quellcode eingelesen und dann wird das irgendwie analysiert,
der Aufrufkraft und so etwas, das ist etwas,
was wir von formalen Spezifikationen so ähnlich sehen, die Spezifikation ist der Hintergrund.
Und symbolischer Programmausführung können Sie wieder sagen, ja,
da wird doch ein Programm ausgeführt,
vielleicht könnte man das auch so bezeichnen,
aber der Begriff wird mehr verwendet dafür, dass man sagt,
das Programm liegt vor und ich tue so,
als würde ich es verarbeiten,
also deswegen symbolischer Programmausführung
Das nächste Bild zeigt nochmal genau, wir wollen es mit Reviews,
Inspektionen beschäftigen und nochmal hier Review und Inspektionen dürfen wir jetzt in dieser Veranstaltung als Synonym betrachten.
Es ist das Gleiche für uns. Es gibt noch ein paar
feine Unterschiede, gibt es, aber die übergehen wir hier.
Solche staatlichen Maßnahmen für Reviews gibt es eine ganze Reihe,
also von dem Review gibt es welche,
die das in Sitzungen machen oder welche,
die das allein machen und nur Kommentare machen,
sozusagen passen zu Homeoffice.
Man macht einen Test am Schreibtisch oder macht nach dem Review
eine Stellungnahme, das würde man vielleicht machen.
Ich mache ein Review der Buchhaltung eines Vereins
Das heißt, deine Beprüfung in der Wirtschaftsprüfung oder sowas,
da mache ich eine Stellungnahme.
Wenn ich mir das mit mehreren Leuten anschaue, ja,
dann kann ich das erstmal ganz informell machen.
Also wir schauen uns das einfach,
wir treffen uns und schauen uns das an und sagen,
weil es ist gut und schlecht.
Oder ich folge einem bestimmten Formalismus. Und diesen Formalismus könnte
ich machen, wenig Einforderungen, ich spezitiere in Speziere,
wenn ich Design in Speziere oder Code inspeziere.
Ja, soweit bei den Informellen gibt es auch noch Arten,
wie ich das organisiere.
Also ich könnte irgendwie das ganz klein machen oder so ein Walk-Through.
Sie erinnern sich gerade, wie Sie gesagt haben,
ich gehe ins Land von Abläufen durch
Review, die Peers, sind die gleichartigen Leute,
sind die Leute auf gleicher Ebene. Da ist also kein
Chef dabei, sondern ich mache das mit Kollegen jedenfalls.
Ja, diese Peer-Review ist das, was ich Ihnen vorstellen möchte,
was wir gemeinsam uns jetzt anschauen werden.
Wie gesagt, Review-Inspektionen sind Synonyme, das Peer-Review,
analysiert, indem der Autor dabei ist,
der Autor stellt das Ganze vor und ein Experte ist dabei.
Der Vorteil oder gegenüber überhaupt die Wirksamkeit erreicht dieses Verfahren dadurch,
dass neue Fragen gestellt werden, fremde Fragen,
die jemand vorher sich so nicht gestellt hat,
weil ein neuer Mensch dabei ist.
Und das bringt tatsächlich neue Erkenntnisse, vor allen Dingen für den Autor.
Man könnte es durchaus sagen, dieses Vier-Augen-Prinzip,
die kognitiven Fähigkeiten werden nicht nur verdoppelt, sondern die werden potenziert.
Und was aber noch als weiteren Effekt ist,
möchte ich selbst aus meiner eigenen Erfahrung als Projektleiter sagen,
es ist mal eine Hunderührung der Arbeit.
Wann schaut sich, wenn jemand mal Quellcode von einem Programmierer
an? Ah, wenn es Probleme gibt und ja,
das ist schon auch alles.
Ja, also Philop ist da nicht zu erwarten
Und es wäre aber ganz gut. Und hier bei der Inspektion
wird tatsächlich der Quellcode mal angeschaut. Und das hat auch tatsächlich
eine Folge, ich hatte eine Form von Anerkennung der Berufsleistung.
Und natürlich kann man da Verbesserungshinweise daraus abnehmen. Meistens nimmt
die mehr der Autor alleine. Wir hatten schon in der Tabelle,
in der Gegenüberstellung, vor zwei Wochen gesagt,
das Ganze ist effizienter als Test, weil wir mehr Fehler pro Zeiteinheit finden.
Und was wir auch nicht vergessen können,
wollen dann in dem Effekt, schaut sich jemand an,
wenn ich das als Programmierer weiß und weiß da,
okay, das ist noch unsauber,
ich mache das erstmal ordentlich.
Ja, besser verständlich, klar und strukturiert.
Das wäre doch
sehr gut
Soweit viel zum Ablauf. Ich will gleich dazu sagen,
da wir Autor und Gutachter in einer Kritisierungssituation haben,
ist das Ganze nicht unkritisch. Man muss dafür sorgen,
dass es ein gutes Klima bei dieser Prüfung herrscht,
dass nicht irgendwie Gefahren, dass der Autor nicht die Gefahr sieht,
da wird mir ein Strick draus gedreht,
weil sonst würde er sich wunderbar verteidigen.
It's not a bug, it's a feature lautet der Spruch.
Ja, also das muss ja genauso sein,
damit ich die und die Ziele erreiche. Nein,
wenn das schlecht ist, darf man es auch so nennen.
Dazu haben wir Fragen, die lauten, wo kommen die Kriterien her,
Kohleninspektion und so weiter, das schauen wir uns gleich an.
Wir haben bis jetzt nur die Inspektion und Reviews gehabt.
Jetzt kommen genau die, waren die Vorteile, nein,
die Verteidigung will ich nicht übergehen.
Tatsächlich finden wir ganz viele der Fehler. Der Hermann sagt,
bis zu 80 Prozent der Fehler oder circa 80 Prozent
der Softwarefehler werden wir gefunden bei diesem Verfahren durchaus mehr,
als wenn wir beim Test finden würden.
Auch es werden auch Mängel entdeckt, die nicht nur mit der Funktion zusammenhängen,
nämlich insbesondere schwer verständliche Sachen, die Mängel der Rockbarkeit,
Tricks oder auch falsche, schlechte Namen gewählt hat.
Sowas würde ich hier schon auffallen. Ich brauche nicht irgendwelche Technik,
ja, insofern ist sie einfach durchzuführen, aber ich brauche die richtigen Menschen.
Das ist manchmal noch viel komplizierter. Ich brauche keine,
ja, weißt du, ja, als Effekt haben,
dass wir, dass dann mehr Leute diesen Root kennen.
Das heißt, wir kommen diesem Ziel, Collective Code Ownership,
den Scrum und Extreme Procoming, when booby, booby sean, ein bisschen näher.
Wir haben diese Möglichkeit des Wissenstransfers, möchte ich unbedingt hervorheben,
man nimmt da jemanden frisches mit dazu, da sieht man,
wie macht man denn das in dem Projekt
Dann können ja leichter gute Arbeit selber machen.
Und damit könne man etwas zur Entwurfsmethoden sagen,
um zum Beispiel zu defensiven Programmierstil, Robustheit, so was können wir machen.
Und man prüft viele Qualitätsziele schon während des Implementierungsprozesses erst mal
nicht erst danach im Test.
Wann mache ich das? Das war jetzt eine Frage.
Ich sollte das immer machen vor einer Feigab. Oder wenn
die Qualität besonders wichtig ist, vor so einem Event,
wo das auffallen könnte,
ja,
und ich sollte es regelmäßig machen
Insbesondere wenn ich Anfänger habe, dass ich sehe, dass sie nichts Falsches machen.
Es gibt denen auch Sicherheit, dass sie nicht so viel
kaputt machen. Und man sollte das vorher bekannt geben,
frühzeitig bekannt geben, damit sich allen darauf einstellen können,
damit sie vielleicht auch gleich so arbeiten.
Das ist ja der wesentliche Punkt, den wir erreichen können.
So, jetzt habe ich schon ganz viel darüber geredet,
aber noch nichts gesagt zum Ablauf.
Der Ablauf ist so, was ist die eigentliche Sitzung hier?
Das ist der Kern. Ja,
da sitzen die Experten zusammen mit dem Autor,
der Experte und der Autor und gehen das Ganze durch.
Ja, bei der Sitzung geht es ganz,
ganz wichtig, das müssen sich bitte merken.
Manchmal sehe ich das im Klausuren,
dass sie wirklich was falsch sagen.
Also es geht nicht darum,
die Software zu verbessern
Ja, da kommt man von 100 Zentausends und da reichen zwei Stunden überhaupt nicht dazu.
Das ist diese zwei Stunden sind nicht in Stein geweiselt,
das ist nur so, dass man,
das ist erfahrungsgemäß die Zeit, für die man sich noch,
in der man sich noch konzentrieren.
Ja, also wir sammeln nur Menge,
wir diskutieren die nicht und versuchen die zu werten oder jemand muss
sich verteidigen oder wir diskutieren, was die bessere Lösung ist.
Nein, ein Mangel gefunden, aufgeschrieben zum nächsten, so geht das.
Und wir versuchen trotzdem ein konstruktives Klima zu haben,
weil es ist dann häufig so,
dass der Autor selber
das meiste erkennt
So, wenn wir hier gleich mal den Ablauf weitergehen,
also das ist aber zur Sitzung, in der Nachbereitung,
behebt der Autor die Mängel und in der Bewertung prüfen wir nochmal und warte das Ganze und wie ist der Prozess gelaufen,
was können wir am nächsten Tag besser machen.
Damit das Ganze gut funktioniert,
macht man vor der Sitzung schon eine Vorbesprechung,
wo alle sich sagen, was ist denn da,
was liegt denn davor, wir schauen uns das schon mal an,
oder wir sprechen nochmal über die Ziele,
die wir haben, auf welchem Level wir suchen,
was sind die großen Risiken,
und man könnte jetzt hier so eine Checkliste abarbeiten nachmittags,
glaube ich
Das war, es gibt uns die Gelegenheit wieder zu fragen,
zu schauen, ja, also wo kommt denn, was ist denn sinnvolle Zeitpunkte,
das hat mir gerade geschrieben und den Ablauf hätten wir beide gesagt.
Wir hatten noch nichts gesagt zu den Rollen,
das passt vielleicht auch hier ganz gut, zu diesem Bildchen,
welche Rollen, nein, ja, aber keine Rollen weiter,
nicht, dass ich das jetzt, welche Rollen haben wir,
wir haben auf jeden Fall den Autor und wir haben den Gutachter.
Das sind die wesentlichen Rollen. Manchmal gibt es noch Moderator,
das wäre auch noch, ich schreibe das mal hier oben
hin,
damit es auch irgendwo steht
Der Autor ist hier die wichtigste Person,
weil nicht nur bis erst vorträgt. Er erzählt auch,
er findet auch im Erklären die meisten Mängel meistens.
Dann haben wir den Experten oder Gutachter.
Dann gibt es vielleicht noch irgendwie so. Ja,
aber das muss auch nicht sein, dass für jemand sein,
der sich der 90 einarbeiten möchte oder so.
Okay. Wo kommen denn nun gegenüber New Kriterien?
Wonach suche ich denn?
Suche ich nun nach Korrektheit
Was für einen Stil deutlich machen. Ja,
und das sollte aus den Aboforderungen, den ich mit uns
falsch gehirn, das sollte aus den Anforderungen kommen.
Also die Anforderungen, der Anforderungsbeschreibung, die sollten das tun. So,
damit frage ich dazu, fragen wir die Stakeholder,
das können auf der Kundenseite jemand sein,
die werden vor allen Dingen äußere Qualitätsmerkmale nennen, Funktionalität,
Benutzbarheit, Effizienz, super, freuen wir uns drüber,
genaue Angaben helfen.
Und für den Entwickler und die technische Seite wird eine Prozessmerkmale
anschauen oder Wartbarkeit. Wartbarkeit ist ein ganz wichtiger Punkt hierbei,
weil der Kaum schauen ja gerade den Kot an.
Und das klingt jetzt so, als würden wir ganz viele Kriterien aufstellen.
Versuchen Sie es bei ein oder zwei Seiten Kriterien zu lassen,
so einen 40-seitigen Kriterienkapanon in Vorbereitung und Inspektion.
Das ist hier gar nicht drin. Natürlich kommt bei
der Vorbereitung, Vorbesprechung, sowas anschauen. Die Leute können
sich darüber diskutieren, aber meistens reicht das dafür nicht.
So, genau hier waren wir stehen geblieben.
Und das war auch eine Frage,
wo stammen die über die Jugkriterien her für diese Dinger,
wo war das
Genau, sinnvolle Zeitpunkte. Wir müssen die Review-Kriterien. Hier
sind die Kriterien für die Code-Inspektionen. Hier sind die.
Das wäre also die Frage, die wir heute haben.
Martin. So. Man kann auch mit Checklisten arbeiten.
Checklisten sind ein guter Wissensrepräsentation, wo die erfahrene Leute reingeschrieben
haben, wie macht man es denn?
Und an diesen Checklisten kann man sich wunderbar orientieren,
auch wenn man ein Fehler ist und etwas neu lernt.
Solche Checklisten können Entwalten etwas zum Codierstil. Etwas,
was macht man in der Sprache oder was macht man nicht,
was ist für eine Lesbarkeit wichtig
Gibt es irgendwelche Regelungen, die wir getroffen haben?
Gibt es Namenskonventionen? Diesen defensiven Programmierstil für Robustheit,
das müssen wir auch noch mit erreichen.
Und wir wollen etwas tun oder prüfen,
ist denn Verständlichkeit, da sind die Namen gut?
Gibt es komplizierte Strukturen? Was wir auch noch machen können,
wir können die komplizierten Probleme, Portabilitäten, Nebenläufigkeit, Fehlerbehandlung entschauen.
Das sind Punkte, wo Fehler häufig ganz sehr versteckt sind und
diffizil sind und selten getestet. Und das Bootokoll reicht,
wenn wir schreiben, wo haben wir was gefunden,
was ist das Problem und ist es schwer,
mittel oder leicht
Damit wäre das schon eigentlich schon genug. Aber wir haben tatsächlich die Möglichkeit,
diesen manuellen Aufwand noch ein bisschen zu verringern,
indem wir hier Werkzeuge einsetzen und sich hier Werkzeuge werden vor allen Dingen Werkzeuge zur statischen Code-Analyse,
die also den Code analysieren, ohne ihn wirklich auszuführen.
Und das wären,
hier möchte ich vor allen Dingen die Tools, Feindbugs,
Checkstyle und PND nennen, indem können mir Regeln vorgeben,
wann etwas gut,
wann etwas schlecht ist,
die markieren das,
die können es
euch auch Fotos davon machen
So, was finden die typischerweise, das sind diese Punkte,
die ich hier angegeben habe? Nämlich Sachen, die ich selbst
diesen Tools sage oder als Kriterien vorgebe. Also häufige Fehler,
zum Beispiel, das ist so ein dreikritisch Finaly,
das Fehlerbehandlung, dass die nicht ausgeführt ist.
Toda Koth, ja, dass ich irgendwie leckere Variablen nicht verwende,
dass ich Parameter und private Methoden habe, die ich nie aufrufe, so etwas.
Wenn der Kot nicht so ganz nach dem Regeln ist,
zum Beispiel Streaming Stream Buffer, nicht korrekt eingesetzt,
oder es gibt ganz komplizierte Ausdrücke, Das wären auch Sachen,
auf die wir achten können.
Und mehrfachen Code ist besser, schon eigentlich, wir sitzen im Werkzeug.
Natürlich kann ich das bei ganz kleinen Systemen auch beachten.
Das wäre auch gut. So, die nächste Frage wäre jetzt,
wo kommen diese Kriterien her, wenn wir Qualitätsziele haben?
Aber das kommt im nächsten Abschnitt hier zuerst mal zu den Fragen nochmal einen Blick drauf,
ob wir da schon was jetzt beantwortet haben.
Nein, das war nicht die Frage, wie mehr zurück.
Wir sind die, ja, wir haben drüber gesprochen,
wo kommen die Kriterien her
Und wie sieht der Ablauf einer Inspektion aus,
haben wir auch schon die Rollen der Beteiligten
immer schon zu den Zielen,
haben wir
noch nichts gesagt