Sunday, October 16, 2011

Verstecken spielen: ein Eintrag vom Code-Kriegstagebuch


Ich bin versteckt. Es gibt viele Verstecke auf diesem Feld, aber ich fühle mich nicht ganz sicher. Ich weiß, ich bin in grosser Gefahr. Zerstören von der Kommunikationsverbindung setzt sie auf die Jagd auf mich. Sie werden nicht aufhören bevor sie mich gefangen haben. Sie suchen mich vielleicht schon. Ich muss versteckt bleiben.
Ich atme gar nicht als ferne Geräusche kondensieren sich in Schatten. Die Schatten kämmen das Boden. Merkwürdig. Es ist also ob sie mich gar nicht suchten. Was soll das jetzt? Ich denke ich habe von diesem Technik gehört, aber ich dachte es wäre noch Sciencefiction. Wenn sie solche Technologie besitzen, ist mein Problem noch viel grösser als ich dachte. Sie suchen mich nicht, sie gehen durch alle mögliche Verstecke. Das systematische Suchen verrät alles.

Die Schatten scheinen eine spezielle MAGIC Truppe zu sein. Sie markieren jedes unbenannte Versteck auf diesem Feld. Das ist nur der Anfang. Ich weiß meine Tarnung wird sie noch täuschen . Ich liege ja nicht in einem Standardgraben oder in einem normalen Bunker. Ich sehe jedoch viele solche überall um mich. Die sind konstante Merkmale in diesem Gebiet. Die MAGIC Männer geben auf.
Ich werde keine Probleme haben mich von der ELSE Einheit zu verstecken. Ich bin ja nicht auf der Wurzeln von Kondition. Die Rinde von Kondition-Baum haben die lokale Schamanen in ihren Trünken benutzt. Die Trünke haben unterschiedliche Zukunftsvisionen gezeigt. Mit diesen Visionen hat der lokale Stamm richtige Entscheidungen getroffen. Der Baum muss logisch-psychedelisch wirken. Die ELSE Einheit fokussiert fast wie Roboter nur die Zweige von dem Kondition. Die durchsuchen alle Löcher. Ich befürchte dass der Neue in Panik geraten ist und seine Schulung vergessen hat. Er wird dann wohl einen Versteck auf einem Zweige von Kondition gefunden haben. Wir müssten ja uns von einander trennen, jetzt heisst es rettet sich wer kann. 

Sie haben mich immer noch nicht gefunden, aber es wird noch schwieriger. Sie wissen es gibt Saboteure in dieser Gegend, sie geben nicht auf. Sie wissen dass es Saboteure überall, immer gibt. Plötzlich aus dem Bach erscheint eine Periskope. Sie rotiert und ich weiss dass der Taucher die Umgebung prüft. Unvollständige Gruben und suspekte schattige Stellen werden sehr genau gecheckt. Ein Kommentarflussteam spezialisiert auf Flüsse, Seen, Bäche, und sie können auch in wenig Wasser tauchen. Diesmal scheinen sie eine TAG Taktik zu benutzen. TAG steht für Terminierung von Ambiguitäten und Generell unvollständiger Arbeit. Sie haben hier nicht viel zu tun, als nur der nächste Bach Flüssigkeit beinhaltet auf diesem sonst so trockenen Feld.

Wenn ich noch eine halbe Stunde schaffe, werden sie die Suche abbrechen. Das hoffe ich wenigstens. Ich fast verschlucke mich vom Erschrecken, als ich ein Spezialvehikel nahe parken höre. Die militärisch genaue Schrift auf der Seite des Vehikels macht mir Angst: “CLOSURE”. Ich hoffe keiner von uns versteckt sich am Ende einer Brücke oder eines Tunnels. Diese Männer prüfen jedes Ende. Sie operieren mit einem klaren Prinzip. Fängt eine Brücke oder ein Tunnel irgendwo an, muss sie oder er irgendwo auch enden. Theoretisch gesehen sind Brücken und Tunnel ausgezeichnete Verstecke, aber das war bevor CLOSURE Männer angekommen waren. Kein symmetrisches Ende ist sicher wenn sie auf dem Feld sind.
Das PTHESES Team wird mich auch nicht finden, egal wie enthusiastisch sie umrennen mit nackten Bajonetten. Ich bin nicht dumm genug in einer Stapel von fragwürdigen Konditionen mich verstecken zu versuchen, obwohl das ist genau was die Präzedenztabelle, die jeder Feldcoder als Standardausrüstung besitzt. Ein kräftiger Anstoß mit der Bajonette und alle die sich verstecken melden sich schon. Manchmal hat man Glück. Jeder hat sicherlich die Legende von Zweite-Zeile Zandersen gehört. Er hatte sein Versteck auf einer klammerlosen Wurzel einer uralten Kondition gefunden. Er lag nächst zu der einzige Zeile da. Als extra Tarnung hatte er noch eine Einrückung über sich gezogen. Er wurde in drei Jahren nicht entdeckt. Vielleicht liegt er immer noch da.

Der letzte Versuch beginnt. Wenn die detaillierte Suche vorbei ist, konzentrieren sie sich auf die Überblick. Das Feuer von CALL Kanonen schlägt nahe. Ich werde fast taub, aber ich erhalte keinen direkten Schlag. Es wird überall leise. Ich habe es geschafft! Die Spezialeinheiten haben unzählige Narben überall auf dem Feld hinter sich gelassen. Ein Flieger gleitet über Kopf. Er photographiert die ganze Gegend. Nur die erste Phase ist vorbei.
Ich habe mich zu früh gefreut. Das Schlimmste kommt noch. Das Bild von diesem Feld und alle Markierungen, die Ticks, werden untersucht. Die Analyse wird von einem echten Fachmann gemacht. Er hat die von uns zerstörte Kommunikationsverbindung gebaut und er hat auch dieses Feld geplant. Ich weiß statistisch habe ich fast keine Chance mehr. Die meisten von uns werden in Analyse verschwinden. Verschwunden in Analyse wird Schicksal vieler werden.

Wer sind wir? Wir sind Vielfalt. Wir sind überall im Code. Wir sind Fahrlässigkeit geboren. Wir sind Aufmerksamkeits-Defizit kodiert. Wir sind Missverständnisse. Wir sind Ausnahmen.   

Wer bin ich? Ich bin niemand und ich bin jeder, ich bin unbekannter Bug.

Sunday, October 2, 2011

5 Gründe warum man Quellcode nicht liest


Am häufigsten von allen Guten Dinge in Software-Entwicklung ignoriert man das Lesen von Quellcode. Warum eigentlich? Fünf Gründe und eine Lösung folgen.

Psychologische Gründe
Warum liest man kaum Code? Vielleicht hat man den nicht zum Lesen geschrieben. Die wichtigste Fähigkeit von Code ist doch, dass er funktioniert. Nur funktionieren genügt, wenn man von kleiner Mengen Testcode oder von kleinen Hilfsprogramme spricht. In grösseren Projekten wird Wartbarkeit extrem wichtig. 

Wenn Testen zeigt, dass Code funktioniert und nur funktionieren genügt, warum sollte man Code lesen? Statistik als Wissenschaft macht es klar dass die grosse Mehrzahl wird den Zaun da überqueren wo er niedrig genug ist. Diese Norm-Nerds sind nicht böse, die arbeiten so gut sie können oder die Managers von ihnen anfordert. Statistisch eine kleine Minderheit schummelt und versucht unter den Zaun zu schlittern. Diese böse Entwickler kann man Coder-Otter nennen. Sie sind auf der Dunklen Seite der Macht gefallen. Eine kleine Minderheit will den Zaun und die Qualität aktiv erhöhen. Das seid ihr, die Leser dieses Blogs, die Tick-Könige, unsere letzte und einzige Hoffnung auf Qualität in Software-Entwicklung. 

Die Norm-Nerds schreiben oft Code der nur funktioniert. Sie denken nie ihren eigenen Code zu lesen. Wenn sie Code lesen, ist es meistens schlecht. Je mehr schlechten Code sie sehen, desto sicherer schreiben sie selbst weiterhin unlesbaren Code. 

Jede Küchenpsychologe weiß dass die eigene Einstellung färbt wie man die Welt sieht. Wenn Markus immer lügt, muss er vorsichtig sein, weil er denkt dass alle andere lügen auch. Wenn ich also Code schreibe der unlesbar ist, wie könnte Code von anderen besser sein? Unlesbaren Code liest man selten, obwohl genau unlesbaren Code sollte man lesen.

Die Jagd auf Perfektion
Warum liest man kaum Code? Vielleicht ist es noch keine richtige Zeit Code zu lesen. Man scheitert so lange man nach die richtige Zeit sucht. Die richtige Zeit kommt nämlich sobald eine Klasse fertig ist, so früh wie möglich, bevor Testen, nach der letzten Änderung, erst wenn die Klasse oder Packung komplette Funktionalität hat, usw.
“ Es gibt keine richtige Zeit Code zu lesen.”
Ernst R. Hauschka schrieb es so: 
“Nicht wer Zeit hat, liest Bücher, sondern wer Lust hat, Bücher zu lesen, der liest ob er viel Zeit hat oder wenig.”
Ich kann es nicht besser ausdrücken.

Die die nicht können, aufschieben
Warum liest man kaum Code? Es ist besonders einfach eine Aufgabe aufzuschieben, wenn es nicht ganz klar ist. Norm-Nerds wissen nicht wie man Code liest und was man zu suchen hat. Man würde annehmen dass weil die Code schreiben können, könnten sie auch Code lesen. Ein Buch zu lesen als Unterhalt ist völlig anders als ein Buch zu lesen mit den Ziel ein Report daraus zu schreiben. Kritisches Lesen unterscheidet sich von normales Lesen wie Streifen auf einem Zebra. Das Produzieren von Text ist wirklich viel einfacher als das Produzieren von gutem Text. Das kann auch erklären wieso Norm-Nerds Code produzieren können. Kritisches Lesen von Code benötigt Können und Erfahrung.

Feedback ist eine soziale Herausforderung
Warum liest man kaum Code? Erzeugen von Kritik mag schwer sein, aber das Liefern von negatives Feedback ist fast unmöglich. Dafür braucht man besondere soziale Kenntnisse, welche technische Menschen oft nicht besitzen. Managers kennen das Problem. Sie müssen ja Kritik liefern so dass die Objekte noch weiterhin arbeiten wollen und sogar noch bessere Ergebnisse produzieren. Man muss die Kritik positiv bekleiden aber nicht so dass es nicht als Kritik genommen wird. Unverdientes Loben wird schnell vergessen.

Ohne Hierarchie hat man die Situation dass Kollegen sich gegenseitig kritisieren. Dann muss man sich vorsichtig bewegen. Wenn man über kleinen Fahrlässigkeiten meckert, wird der Schreiber sich nicht vertrauenswürdig fühlen und wenn man grössere Fehler findet, wird der Schreiber sich dumm fühlen. In beiden Fällen ist das Feedback falsch geliefert geworden. Feedback muss in einer gesunden Arbeitsumgebung die ganze Zeit fließen. Jeder kann sich immer noch verbessern.

Das Prüfen wird untergeschätzt
Warum liest man kaum Code? Für Norm-Nerds ist das Prüfen als Aktivität nicht so produktiv wie das Schreiben von neuen Code. Dieser Grund erklärt auch warum man zu wenig testet in Softwareprojekten. Wenn man die Aufgabe nicht für hochwertig hält, wird die nie hoch genug priorisiert um gemacht zu werden. Der Wert einer Aufgabe hängt von deren Ergebnissen ab, und wenn man beim Code-Lesen keine wertvolle Befunde findet, sollte man wahrscheinlich nicht Code lesen. Anstatt Zeit in eine ineffiziente Aufgabe zu verschwenden, wird man eher mehr neuen Code schreiben, weil es wertvoller wirkt, obwohl sehr viel geschriebener Code besser wäre ungeschrieben geblieben.

Die Lösung
Man liest Code schon
-wenn alle schreiben Code für andere Menschen,
-wenn Prüfen von Code wird als notwendig in Software-Entwicklung gesehen, 
-wenn Leute können Code lesen und prüfen,
-wenn das generierte Feedback konstruktiv und belehrend ist,
-wenn die Prüfergebnisse den jetzigen Code (und allen zukünftigen Code) verbessern.