Clean Code – 3 Prinzipien

Clean Code – 3 Prinzipien

masterTheRules
prinzipien

 

Es gibt in vielen Dingen und Vorgehensweisen im Leben feste allgemeine Grundsätze, Regeln oder Prinzipien genannt. Meistens helfen diese Regeln uns dabei die Orientierung zu behalten und auf diesen Regeln aufbauend Schlussfolgerungen abzuleiten. Manchmal gibt es auch unsinnige Regeln, die ein Vorankommen verhindern und ein Umdenken bedürfen.

Um ein Bild entstehen zu lassen, kann man sich ein Fußballspiel mit seinen Regeln vorstellen, die den Ablauf eines Spiels definieren und in diesen Grenzen sich ein Spieler ohne eine rote oder gelbe Karte zu bekommen bewegen darf. Bewegt man sich beim Spielen an der Regeln oder Konventionen, können sich z.B. auch die Zuschauer an einem Spiel erfreuen und besser beurteilen. Dabei können sie den Spielverlauf gut ablesen und in Grenzsituationen über richtige oder falsche Auslegung der Regeln diskutieren. Am Beispiel eines Fußballspiels kann man auch erkennen, dass es immer Situationen geben kann, die einer Interpretation bedürfen, um eine Entscheidung zu treffen. Wie in vielen Fällen des Lebens.

Beim Programmieren existieren auch Regeln und Prizipien, die man beachten kann. Diese Regeln unterstützen uns dabei gut lesbaren Code zu schreiben, der wartbar und erweiterbar bleibt. Der Grund warum Programmierprinzipien in meinen Augen so wertvoll sind, ist, dass wir als Entwickler im Grunde Autoren sind. Autoren, die an einem gemeinsamen Werk arbeiten, der an verschiedenen Stellen von anderen Autoren erweitert oder optimiert wird. Hier helfen gewisse Regeln, die wenn sie überwiegend eingehalten werden, das gemeinsame Vorankommen entsprechend verbessern kann.

Welche konkrete Prinzipien existieren in der Softwareentwicklung eigentlich und wie helfen sie uns bei der täglichen Programmierarbeit? In diesem Beitrag möchte ich auf diese Fragestellung eingehen und versuchen zu beantworten.

Prinzip Nr. 1: Das richtige Werkzeug für die richtige Aufgabe

Jeder von uns hat seine Lieblingswerkzeuge, die für verschiedene Fragestellungen benutzt werden können. Mal ehrlich, wer liebt als Programmieren nicht seine Entwicklungsumgebung oder Programmiersprache und versucht diese Werkzeuge für alle Problemstellungen zu benutzen, um eine Lösung zu finden. Auch wenn manchmal mit Kanonen auf Spatzen geschossen wird und es sich nicht um das richtige Werkzeug handelt.

Um tatsächlich effektiv zu sein, sollte man immer die Problemstellung analysieren und sicherstellen, ob es bereits eine Patentlösung gibt, mit der ein Problem sehr einfach und effizient oder sogar sehr elegant erledigt werden kann.

Probleme bei der Lösungsfindung können immer da auftreten, wo es Grenzen zu anderen Technologien existieren. Hier ein Beispiel von Grenzen zwischen verschiedenen Programmier oder Auszeichnungssprachen und Ebenen in der Webentwicklung.

Grenzen zwischen Webtechnologien im MVC - Model View Controller Pattern

Hier können sich folgenden Grenzen ergeben:

  • HTML wird im JavaScript Code eingebettet und bei Bedarf in den DOM eingebunden
  • CSS zur Darstellung der Seite wird direkt im HTML Code eingebunden und nicht ausgelagert
  • JavaScript wird direkt in HTML eingebettet und nicht ausgelagert
  • Die Backend Programmiersprache generiert eine Ausgabe in der JavaScript/HTML/CSS ausgegeben wird
  • Das Backend speichert Frontend- bzw. HTML Code in der Datenbank

Ein Ziel beim Clean Code sollte sein, solche Überlappungen zu erkennen und zu vermeiden. Auch macht es Sinn Code in eigenständigen Dateien auszulaggern und bei Bedarf per Include Mechanismen einzubetten. Dadurch ergibt sich die Möglichkeit Dateien z.B. im Browser zu cachen und bei einen erneutem Aufruf nicht neu laden zu müssen, was der Performance zugute kommt. Ein weiterer Vorteil durch die Auslagerung ergibt sich beim Einsatz einer Entwicklungsumgebung, so kann diese bessere Codeunterstützung leisten. Beispielsweise kann der Quellcode besser farblich hervorgehoben und auf Fehler überprüft werden. Weiterhin kann Code einfacher wiederverwendet und die Codebasis reduziert werden.

Prinzip Nr. 2: Ein klares Signal für höchsten Genuss

Jeder von uns hört gern Musik, auch mal lauter. Was wir aber nicht mögen, ist dieses anstrengende Rauschen welches entsteht, wenn der Sender nicht richtig eingestellt ist. Beim Programmieren kann das auch passieren und zwar dann, wenn wir versuchen zu viel auf einmal zu machen und zwar innerhalb einer einzigen Methode. Eine Trennung von Funktionalität ist sehr hilfreich wenn nach Fehlern in Quellcode gesucht wird und der Tag und die Konzentration zu Ende gehen. Hier wird z.B. verständlicherer Code zum Mehrwert für den Leser.

Wie viele Dinge kannst Du Dir eigentlich gleichzeitig merken? 100, 10, 5?  Laut George Miller kann das Gehirn 5 bis 9 Informationen gleichzeitig verarbeiten. Wenn man dieses Wissen auf die Programmierung überträgt, kann man folgern, dass Methoden mit weniger Zeilen Code verständlicher sind. Auch wird verständlich, dass Methoden mit weniger Parameter deutlich besser zu begreifen sind. So sollte aus dieser Erkenntnis heraus Code so gestaltet werden, dass er mit wenig Mühe lesbar und nur das tut, was nötig ist, um eine Problemstellung zu lösen.

Wir sollten uns auch immer vor Augen halten, dass Code öfter gelesen als geschrieben wird und anderen Autoren einen besseren Zugang zum Code bieten. Wir sollten uns also als Autoren sehen, die viele kleine und einfache Geschichten erzählen, die auch leicht zu merken sind.

Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.

Killer

Um Geschichten nicht immer wieder und wieder erzählen zu müssen, hilft das DRY-Prinzip. – Don’t repeat yourself -. Es sollte bei der Entwicklung von Code auf Mustern geachtet werden und wenn diese Muster auffallen, sollten diese ausgelagert werden. Das Maintenance-Team wird dir dafür dankbar sein. Jede unnötige Zeile Code fühlt sich mit der Zeit, wie schwere Gewichte beim Laufen. Weniger ist oft mehr.

Prinzip Nr. 3: Code erkläre Dich selbst!

Es passiert regelmäßig, dass man als Entwickler Bugs beheben oder Anpassungen an Code durchführen muss, welches man selbst nicht geschrieben hat. Oft stellt man sich dabei die Frage, was der Entwickler an der gewissen Codestelle eigentlich ausdrücken wollte. Hier liegt einer der größten Herausforderungen bei der Codepflege. Aus diesem Grund ist es sehr wichtig Gedanken so klar wie möglich in Code umzuwandeln. So, dass keine Fragen offen bleiben. Wenn doch offene Fragen bleiben könnten, kann ein kurzer Kommentar helfen, man sollte aber mit Bedacht zusätzliche Kommentare einsetzen. Eine klare Ausdrucksweise sollte immer Vorzug erhalten vor zusätzlichen Kommentaren. Es kann bei der Entwicklung passieren, dass der Code angepasst wird und die ursprünglichen Kommentare obsolet werden. Dies kann dazu führen, dass offene Fragen zum Code bleiben. Was zu verhindern ist.

Stelle Dir ein Buch vor. Ein Buch hat ein Cover, ein Vorwort und ein Inhaltsverzeichnis. Das Buch besteht zusätzlich aus Kapiteln und weiteren Unterkapiteln. So kann ein gutes Programmierdesign aussehen, in dem Schichten existieren, die Abläufe auf verschiedene Detailebenen beschreiben. Ablaufbeschreibungen, die den großen Plan ausführen und darunterliegende Methoden aufrufen, die sich um die Details kümmern. So wie ein Adler in der Höhe eine große Übersicht hat und je tiefer er fliegt, desto mehr Details können entdeckt werden. Ein Code Zoom, der dabei hilft den Überblick zu behalten und bei Bedarf die Möglichkeit zu haben sich in die Tiefe stürzen zu können kann zu einem guten Verständnis von Software beitragen.

Rockband
Rockband

Wenn Du alleine vor Dich hin programmierst ist die Art der Formattierung eher zweitranging. Hauptsache der Code läuft. Im Team verhält sich das etwas anders. Es geht nicht mehr um den Erfolg einer einzelnen Person. Es geht mehr darum zusammen zu einem gutem Ergebnis zu kommen und jeder leistet seinen Beitrag zum gemeinsamen Erfolg. Letztens habe ich gelesen, dass eine Musikband und ein Entwicklerteam viel gemeinsam haben. Auf der einen Seite die die Kunst gemeinsam zu musizieren und auf der anderen Seite die Kunst gemeinsam zu Quellcode zu schreiben, der funktioniert und wenig Fehler hat. Um im Team erfolgreich zu sein, benötigt es gemeinsame Standards und gegenseitige Unterstützung. Zu einem gemeinsamen Standard kann man durch Styleguides und gegenseitige Absprachen kommen, um ein gemeinsames Verständnis der Codebasis zu erreichen.

Styleguides können auch dazu führen, dass der Code, wie aus einem Guss aussieht und nicht wie ein Flickenteppich. Um hier die Buchmetapher wieder aufzugreifen kann ein Styleguide zu einem flüssig lesbarem Roman führen, der sich nicht von Kapitel zu Kapitel anders liest.

 

Clean Code Hauptartikel

Wie ist Deine Meinung zu Clean Code? Führen gemeinsame Prinzipien zu besserem Code?

Wenn Dir dieser Artikel gefallen hat, würde ich mich freuen, wenn Du Ihn teilst. Hast Du Lob oder konstruktive Kritik hinterlasse einen Kommentar.

Vielen Dank, dass Du vorbeigeschaut hast

Andrés

Links:

Das Prinzip im Allgemeinen

Merkfähigkeit

Why coding styleguides matters

Clean Code:A Handbook of Agile Software Craftsmanship (Robert C. Martin)

Always code if the guy who …

photo credit: Rules via photopin (license)

photo credit: biost_093 via photopin (license)

photo credit: Tough E Nuff0002 via photopin (license)

 

 

1 Comment


Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.