Thomas Baustert's Blog

Ich habe schon immer gedacht, Uncle Bob ist ein wenig anders (im positiven Sinne), wenn es das Vermitteln von Wissen und Erfahrung geht.

Hier jetzt der neueste Streich. Es ist nicht die Tatsache, dass es Videos sind. Es ist das Wie :).

Es lohnt sich!

www.cleancoders.com

Wenn ich ein Framework einsetze, habe ich folgende Erwartungen:

1. Es wurde aus einer laufenden Anwendung extrahiert
2. Es verfügt über eine hohe interne Qualität
3. Es ermöglicht einfache Testbarkeit meines Produktionscodes
4. Es lässt sich schnell und einfach installieren.
5. Es verfügt über gute Dokumentation und Beispiele.
6. Es bietet eine einfache und intiutive Schnittstelle

Es wurde aus einer laufenden Anwendung extrahiert.

Das Framework muss aus einer bestehenden laufenden Anwendung extrahiert worden sein. Nur dadurch hat es (zumindest für eine Applikation) seine Funktionsfähigkeit bewiesen. Im Handwerk werden nur Techniken, Konzepte usw. genutzt und weitergegeben, die sich in der Praxis bewährt haben. Erst die Erfahrung lehrt, was geht und was nicht. Gleiches gilt für ein Framework.

Gute Beispiele sind Ruby on Rails oder Spring (letzteres zumindest wegen diesem Punkt). Ein Anti-Beispiel ist EJB bis 3.0. Die Entwicklung auf der grünen Wiese hat wohl mehr Kosten beim Einsatz verursacht als Nutzen gebracht.

Es verfügt über eine Hohe interne Qualität.

Das Framework muss über eine hohe interne Qualität verfügen, d.h. gut lesbaren modularen Code und eine hohe Testabdeckung bieten. Nur so finde ich Vertrauen in das Framework und bin bereit mich darauf zu verlassen. Warum sollte ich einem Framework vertrauen, dass schluderig programmiert wurde und nicht ausreichend automatisiert getestet wird?

Es ermöglicht einfache Testbarkeit meines Produktionscodes.

Das Framework muss mir auf einfache Art und Weise ermöglichen, meinen darauf aufbauenden Produktionscode zu testen. Andernfalls habe ich den Eindruck, die Entwickler haben dem Thema wenig Beachtung geschenkt und das lässt mich skeptisch im Bezug auf den Rest des Frameworks werden.

Auch hier ist Ruby on Rails ein sehr gutes Beispiel, da ich Tests leicht erstellen und ohne laufenden Webserver ausführen kann. Ein Anti-Beispiel ist auch hier EJB bis 3.0, weil die Beans nur innerhalb des Containers getestet werden konnten und das Schreiben umständlich war. Eigentlich unglaublich, das soetwas jemals produktiv eingesetzt wurde (und wird). Bei 3.0 gibt es nun endlich POJOs und damit einfachere Testbarkeit.

Es lässt sich schnell und einfach installieren.

Wir alle sind immer unter Zeitdruck (zumindest gefühlt) und die Installation sollte daher einfach und zügig gehen. Wenn ich erst viele Abhängigkeiten auflösen muss, vergeht mir vermutlich die Lust und der Frust beginnt. Also bitte diese Arbeit nicht auf den Nutzer abwälzen.

Es verfügt über gute Dokumentation und Beispiele.

Eine gute Dokumentation, vor allem viele gute und einfache Beispiele helfen enorm bei der Einarbeitung. Wenn ich direkt ein Archiv herunterladen, auspacken und loslegen kann, bin ich eher angefixt. Auch Videos sind hier eine gute Unterstützung.

Vielleicht sollte ich noch anfügen, dass das Framework keine Eierlegendevollmichsau sein sollte, sondern sich auf eine Sache konzentrieren sollte, die es besonders gut macht.

Und Vorsicht mit sogenannten Standards! Ein Framework ist nicht Standard, weil ein Firma es als solches benennt. Standard soll nur werden, was sich über lange Zeit bewertet. Also ruhig hinterfragen.

Und was sind deine Kriterien?

Um mich beim Schreiben von Quellcode daran zu erinnern möglichst sauberen Quellcode zu schreiben, habe ich als Gedankenstütze die schöne Aussage “Schreibe Code wie ein Autor” entdeckt (Quelle: Clean Code).

Ich selber habe ein paar Artikel in Fachzeitschriften und sogar ein Buch geschrieben. Wenn ich schreibe, habe ich eine Botschaft, ich möchte etwas vermitteln (meist fachliches Wissen). Und ich möchte, dass der Leser mich versteht. Ich schreibe den Artikel oder das Buch nicht für mich, sondern für den Leser.

Ok, ich schreibe auch für mich, weil man durch das Schreiben über ein Thema (oder auch durch das Präsentieren) das Thema selber besser versteht. Schreiben ist auch ein Stück Selbstverwirklichung und natürlich auch Marketing.

Letztlich hat man beim Schreiben immer den Leser vor Augen. Und genau so sollte es auch beim Schreiben von Quellcode sein! Sicher immer wieder fragen, ob den Code auch ein anderer leicht versteht (oder ich selbst zu einem späteren Zeitpunkt). Nicht aufhören, wenn es funktioniert. Erst aufhören, wenn der Code auch leicht verständlich ist.

Lasse den Code reviewen

Bevor ich einen Artikel oder ein Buch als fertig abgebe, lasse ich das Geschriebene von Freunden und Kollegen reviewen. Ich möchte ein Feedback, ob der Text verständlich ist und keine fachlichen Fehler enthält (und keine Rechtschreibfehler ;) ). Das macht vermutlich jeder Autor.

Auch diese Möglichkeit gibt es in der Softwareentwicklung und verbreitet sich als Praktik immer mehr. Ich spreche von Code Reviews und auch Pair Programming. So wie das Feedback dem Autor hilft, seinen Text zu überdenken, helfen Code Reviews den Quellcode verständlicher zu machen. Pair Programming ist quasi das permanente “Verständlichermachen” des Codes.

Also, immer daran denken: “Schreibe Code wie ein Autor!”

Ressourcen

• Buch: Clean Code
• Blog: Clean Code – Oder der gute Programmierer

Immer wieder kosten IT-Projekte mehr als geplant oder scheitern ganz. Die Gründe sind vielschichtig und häufig nicht technischer Natur. Dennoch muss man sich fragen, was wir als Programmierer zum Erfolg von Projekten beitragen oder auch nicht.

Irgendwo habe ich gelesen: “Schlechte Programmierer schreiben Code, der vom Computer verstanden wird. Gute Programmierer schreiben Code, der von Menschen (anderen Programmierern) verstanden wird.” (kennt jemand die Quelle?).

Das Thema des guten Programmierers ist komplex, aber das Zitat bringt die Sache auf den Punkt. Wenn es um das Schreiben von Quellcode geht, gibt es zwischen Programmierern sehr große Unterschiede.

80% aller Programmierer Schreiben unsauberen Quellcode

Wenn es nur um das Funktionieren des Quellcode geht, bekommen das vermutlich 80% aller Programmierer hin. Wenn es um das Schreiben von sauberen Quellcode geht, sind 80% aller Programmierer eher schlecht als gut. Und das finde ich sehr bedenklich, da sauberer Quellcode essentiell für den Erfolg eines Projekt (eines Softwaresystems) ist.

Was wenn Juristen, Medizinern, Architekten, Handwerkern so schludrig wären. Wo wären wir dann? Wahrscheinlich dort, wo wir jetzt mit der IT sind. Noch weit am Anfang.

Mit schlecht ist hier nicht vorsätzlich schlechte Arbeit gemeint. Eher eine Unwissenheit, Faulheit oder das fehlende Verständnis für die notwendigen Disziplinen eines guten Programmierers.

Vielleicht sind 80% sehr hoch gegriffen. Vielleicht habe ich einen besonders hohen Anspruch, was guten Quellcode ausmacht. Wenn ich sehe, was möglich ist und das mit dem vergleiche, was ich in Projekten sehe, neige ich zu 80%. Das schliesst meinen eigenen Code (zum Teil) mit ein :)

Unsauberer Quellcode hat seinen Preis

Sicher gibt es unzählige Anwendungen, die funktionieren. Es kann also nicht so schlecht um unsere Zunft bestellt sein oder? Aber zu welchem Preis funktionieren diese Systeme? Und vor allem zu welchem Preis der Wartung und Weiterentwicklung?

Sicher hat Software ihren Preis, denn die Entwicklung ist nach wie vor aufwendig. Was für den Manager ein Knopf auf der Seite ist, bedeutet für den Programmierer häufig ein Wunder schaffen. Entweder zahlt man den Preis (bei guten Programmierern) oder man zahlt ihn doppelt (bei schlechten Programmierern). Insgesamt kosten die meisten Projekt aber deutlich mehr als notwendig.

Ein für mich ganz wesentlicher Aspekt ist die interne Qualität des Quellcode, die langfristig deutlich zur Kostenreduzierung beiträgt. Der Punkt ist für mich wichtig, weil ich als Programmierer genau hier etwas beitragen kann. Und zwar, indem ich Quellcode schreibe, der nicht nur funktioniert, sondern auch für andere Programmierer gut lesbar und gut verständlich ist.

Was ist sauberer, gut lesbarer, verständlicher Code?

Prinzipien, Praktiken und Beispiele guten Quellcodes finden sich in CleanCode [1]. Pflichtlektüre!

Siehe auch Schreibe Code wie ein Autor

Warum ist verständlicher Quellcode wichtig?

80% aller Kosten für Software sind Wartungskosten. Die initiale Erstellungen nimmt also den kleineren Teil ein. Beim Schreiben von Code muss langfristiger gedacht werden.

Das Funktionieren des Features ist trotz aller Umstände immer möglich und wird häufig als einziges Mass für das Entwicklungsende verwendet. Es ist offensichtlich. Entweder es funktioniert oder es funktioniert nicht. Das für Menschen lesbarer Quellcode für die langfristige Wartung eine ganz wesentliche Rolle spielt wird nicht gesehen.

Das Projekt schreitet voran und es dauert immer länger, um Features zu entwickeln. Das Team verbringt immer mehr Zeit für die Stabilisierung des Entwicklungsprozesses und die Fehlerbehebung. Die Anzahl neuer Features pro Zeiteinheit sinkt und sinkt.

Wichtig ist zu erkennen, dass Programmierer 80% ihrer Zeit Code lesen und nicht schreiben (siehe auch When understanding means rewriting). Ebenso wird ein Grossteil der Zeit mit dem Ändern von bestehenden Quellcode verbracht. Den kleinsten Anteil bildet das Neuschreiben von Code!

Stunden und Tage gezeichnet von Anforderungsanalyse, Diskussionen, Entwicklung, Fehlerbehebung usw. sind komprimiert im Code gelandet. Bei der Wartung oder Fehlerbehebung muss der (lesende) Programmierer dieses Wissen aus dem kryptischen Code wiedergewinnen. Er muss die Absicht des Originalprogrammierers verstehen, die Geschichte hinter dem Code, die Anforderungen, das Wissen aus Stunden und Tagen. Warum hat er es so gemacht und nicht anders? Gab es keine Alternative oder hat er sie nicht gesehen?

Das ist häufig sehr mühsam und zeitaufwendig, erfordert Konzentration und möglichst keine Ablenkung. (Und ist auch dann nicht immer einfach, wenn der Leser der ursprüngliche Programmierer ist.)

Je unverständlicher der Code, um so größer die Chance, dass er nicht ausreichend verstanden wird und Änderungen neue Fehler bringen. Je unsauberer der Code, um so aufwendiger wird die Wartung oder werden Refactorings.

Daher ist es mehr als notwendig, dass der Quellcode sehr aussagekräftig und lesbar ist. Das bekommt man nicht geschenkt und kann man sich nicht kaufen. Das ist eine Disziplin, ein Handwerk, eine Kunst. Diese unterscheidet u.a. den Anfänger vom Meister, den schlechten vom guten Programmier. Schlecht verständlicher Quellcode ist die Wurzel allen Übels. Und wie gesagt, ich vermute, in 80% aller Projekte ist er eher schlecht als gut.

Am Beginn eines Projekt fällt das noch wenig auf. Aber wer auf hohe interne Qualität verzichtet, muss früher oder später dafür zahlen. Und zwar gewaltig. Ich halte es da mit der Aussage von Uncle Bob aus Clean Code : “The only way to make the deadline – the only way to go fast – is to keep the code as clean as possible at all times.”

Gründe für unsauberen Code

Warum gibt es so vielen schlechten Quellcode? Warum haben wir diesen Kern unserer Arbeit so schwer im Griff?

Kurz gesagt, weil es keine vernünftige Ausbildung gibt.

Vermutlich weil das IT-Handwerk noch so jung ist und wir erst nach und nach lernen, was wirklich wichtig ist. Am offensichtlichsten ist da, dass jemand programmieren kann, wenn das von ihm geschriebene Programm “funktioniert”. Und genau da bleiben die meisten Programmier stehen.

Das Programmieren, die tägliche Arbeit in der Diskussion mit Kollegen und am Rechner ist harte Arbeit. Das Erlernen erfordert viel Disziplin und Zeit.

Das deutsche Handwerk ist weltweit für die Qualität bekannt. Die Ausbildung gehört sicher zur besten in der Welt. Wenn ich Tischler werden will, mache ich eine Ausbildung bei einem Tischlerbetrieb. Der Meister lehrt mich in Theorie und vor allem Praxis. Mit genügend Motivation und Ehrgeiz werde ich zum Gesellen und nach Jahren auch zum Meister.

Affinität zum Thema, Motivation und Eigeninitiative sind für das Erlernen des Handwerks wichtig. Der Meister hilft mir dabei, ist mein Ausbildern und Mentor. Er sorgt dafür, dass ich das Richtige lerne (effektiv) und es richtig lerne (effizient). Das gibt es in der IT-Welt so (noch) nicht oder selten. Oder wo ist der Meister in meiner Stadt, bei dem ich in die Ausbildung gehe?

Es geht mir nicht um die Einführung eines Meisterbriefes für IT-Fachkräfte. Das ist eine andere Baustelle. Es geht um das Fehlen einer fundierte Ausbildung für Programmierer.

Jeder bringt sich Programmieren selber bei

Weder im Studium, in Instituten oder in Firmen erfolgt eine fundierte und angemessene Ausbildung. Eine Ausbildung die weiter geht als “Programmieren ist Funktionieren” (s.u.).

Jeder, den ich kenne, hat sich das Programmieren selber beigebracht. Und damit haben wir den ersten Teilzeitjob bekommen und sind in die Berufswelt als hauptberuflicher Programmierer eingetaucht. Und zwar mehr oder weniger von Null an.

Wo gibt es so etwas in anderen Bereichen? Bei Architekten, Medizinern, Juristen, Handwerkern usw.? Fange ich irgendwo als Mediziner an, weil ich schon mal meinen Hund verarztet habe? Oder als Jurist, weil ich das Grundgesetz gelesen habe?

Klar lernt man nie aus und muss sich selber immer weiterbilden. Auch ein Tischler mit gerade bestandenem Meisterbrief ist nicht am Ende, sondern eher am Anfang. Er muss weiterhin viel Erfahrung sammeln und sich in Theorie und Praxis permanent weiterbilden. Aber er hat zumindest eine solide Ausbildung (von einem Meister) erhalten, die die Grundlage für die weiteren Schritte bildet.

Wenn man bedenkt, das die Softwareentwicklung ein so wichtiger Markt und anspruchsvoller Job ist, wundert mich die nicht vorhandene fundierte Ausbildung.

Der Zugang zur professionellen Arbeit ist wohl bei keiner Zunft so einfach, wie bei der Programmierung. Meines Wissen gibt es kaum Quereinsteiger bei Architekten, Juristen, Medizinern, aber verhältnismässig viele in der IT. Damit sage ich nichts gehen Quereinsteiger. Ich meine nur, dass die Einstiegshürde in anderen Bereichen wesentlich höher ist. Wäre sie in der IT ebenso hoch, gäbe es hier wesentlich weniger Quereinsteiger.

Jeder hat heute einen Computern. Man benötigt ein gewisse Affinität zu diesem (zur IT), kauft sich ein paar Bücher und bringt sich selbst Programmierung bei. So hat es vermutlich jeder von uns gemacht, egal ob Studium, Ausbildung oder Quereinsteiger.

Programmieren ist nicht nur funktionieren

Aber was genau bringt man sich bei? Erst einmal nur Code so zu schreiben, dass der Computer (Compiler) den Code versteht und ausführt. “Hey, er zeigt mir ‘Hello World!’”

Wenn ich Sprachkonstrukte nur richtig schreibe, versteht das der Computer und das Programm läuft. Hie und da schon fummelig und manchmal nervenzehrend, aber mit der nötigen Affinität insgesamt nicht so schwer.

Es hinterlässt den Eindruck, man muss nur lernen, Code so zu schreiben, dass der Computer ihn versteht. Programmieren wird mit “funktionieren” verbunden. Wenn der Code funktioniert, kann ich programmieren, wenn nicht, dann nicht. Das ist logisch und offensichtlich.

Was weniger offensichtlich ist, ist den Quellcode verständlich zu schreiben. Denn dass ist eine Disziplin und kann nicht so leicht nachvollzogen werden, wie ein laufendes oder nicht laufendes Programm.

Aber genau dieser weitere Schritt, macht den Unterschied zum guten Programmierer. Oder wie es Uncle Bob in Clean Code beschreibt: “To many think we are done once the programm work”.

Und es ist ein sehr großer Schritt (eigentlich viele viele kleine) und benötigt Disziplin und Zeit. Und hier scheidet sich dann die Spreu vom Weizen. Wer wirklich gewillt ist, weiter zu kommen, Schritt für Schritt. Und wer die Mühen und den Aufwand scheut und stehen bleibt. Wer Durchschnitt bleibt oder zum Meister wird. (Analog vom Karate-Änfanger zum Meister mit mehreren schwarzen Gürteln. Man schreitet Schritt für Schritt voran und erreicht den höchsten Grad vielleicht nie.)

Keine Zeit für Weiterbildung

Ein weiterer Grund weshalb viele auf der erste Stufe stehen bleiben ist die fehlende Zeit für Weiterbildung. Weil die Basis nicht reicht und weil sich in der IT-Welt alles Wissen ständig weiterentwickelt, muss man sich ständig weiterbilden.

Aber kaum hat man die Basis erlernt, startet man im Job. Und hier hat man eines nicht und das ist Zeit. Jedes Projekt läuft immer unter Hochdruck und die 40 Stunden pro Woche reichen dafür gerade aus. Eine Weiterbildung erfolgt nur, wenn man selber in der Freizeit Bücher liest oder ausprobiert. Und mittlerweile wird die Weiterbildung in der Freizeit quasi von jedem Mitarbeiter erwartet.

(Chef: “Für Weiterbildung ist jetzt keine Zeit. Machen sie es in der Freizeit, machen allen anderen Kollegen auch!”) Kein Wunder, das viele nur das Nötigste lernen, um im Job dranzubleiben.

Man kann nur hoffen, dass die Firma und die Kollegen wissen, was richtig ist und es richtig machen und diese quasi als Meister, Auszubildender oder Mentor fungieren. Und man selbst sein Wissen an andere weitergibt. Darüber hinaus kommt es eben auf die eigene Einstellung an.

Bin ich ein guter Programmierer?

Ich habe schon viel schlechten Code geschrieben. Die Anwendung funktioniert, keine Frage. Aber verständlicher Quellcode ist anders. Wie gesagt, ich wusste es nicht besser, denn ich habe es nie wirklich gelernt. Und das gilt für alle meine Kollegen auch.

Erst nach und nach habe ich wesentliche Disziplinen erkannt und erlernt und bin so stetig besser geworden. Ein wesentlicher Schritt nach vorne war das Lesen vieler Bücher, der Austausch mit gleich gesinnten Kollegen und ganz konkret der Einsatz der testgetriebene Entwicklung.

Clean Code Developer – Software Craftsmanship

Ich könnte hier eine Reihe weitere Punkte aufführen, aber stattdessen verweise ich lieber auf Clean Code Developer. Es enthält quasi alles, was ich für essentiell halte, um ein guter Programmierer zu werden oder zu sein.

Ob ein solides Verständnis von OO, der Einsatz von TDD, von statischer Codeanalyse, Continuous Integration, Code Reviews, Pair Programming oder die eigene Weiterbildung. Alles, alles trägt letztendlich zu sauberem Quellcode bei!

Was mir gefällt, ist dass die vielen wichtigen Prinzipien und Praktiken schrittweise durch das Wertesystem durchlaufen werden. Zu einem Zeitpunkt konzentriert man sich immer auf ein paar Punkte. Dann wechselt man die Farbe und befolgt eine Zeit andere Werte. Am Ende angekommen, beginnt man von vorne. Durch das kontinuierliche Durchlaufen verinnerlicht man alle wesentliche Punkte. Werde ich mal ausprobieren.

Ebenso bin ich angetan von der Bewegung des Software Craftsmanship.

Beide haben das selbe Ziel und zum grossen Teil die selben Prinzipien und Praktiken.

Fazit

Fehlende Ausbildung und fehlende Zeit sind zwei wesentliche Faktoren für schlechten Quellcode. Dieser führt früher oder später zu aufwendigerer Wartung, mehr Fehlern, weniger Zeit für neue Features und zu stetig steigenden Kosten.

In beiden Punkten sind wir Programmierer arme Schweine. Es liegt an uns, ob wir die Mühen und Anstrengungen auf uns nehmen, uns kontinuierlich zu verbessern, um zum Clean Code Developer werden.

In diesem Sinne, ich bin dann mal weg, mich weiterbilden!

Resourcen

• [1] CleanCode, Robert C. Martin, Prentice Hall, 2008
• [2] Clean Code Developer
• [3] Software Craftsmanship