Clean Code Developer - Roter Grad: Beware of Premature Optimization und Version Control System

Beware of Premature Optimization

Ergänzende eigene Gedanken zu clean-code-developer.de

Das Prinzip, dass ich euch heute vorstelle, sagt im Grunde folgendes aus: Optimiere nichts, was nicht wirklich nötig ist.

Schon oft habe ich gesehen, dass für ein kleines Projekt noch vor der ersten Zeile Code bereits unendlich viele Gedanken in die Skalierbarkeit über die ganze Welt gemacht wurden. Anstatt zunächst das Projekt umzusetzen und zu schauen, ob es auch überhaupt jemand nutzt.

Aber auch im Alltag stolpere ich immer wieder über Code, den ich gerne ständig optimieren möchte. Dabei steht aber die Optimierung oft in keinem sinnvollen Verhältnis zum Nutzen der Optimierung.

Oft stehen Optimierungen sogar im Konflikt mit anderen Zielen, die das Projekt hat. Solche Ziele können zum einen sein, dass der Code schnell oder sparsam läuft, aber viel regelmäßiger stehen bei größeren Softwareprojekten Sicherheit, Wartbarkeit, Erweiterbarkeit und auch die Stabilität im Vordergrund. Eine Optimierung hin zur Schnelligkeit kann dazu führen, dass eine der wichtigeren Eigenschaften der Software darunter leidet. Meist stehen auch Schnelligkeit und Sparsamkeit in Konflikt, z.B. wenn der Code schneller wird, wenn mehr Daten zwischengespeichert werden.

Daraus sollte folgen, dass Optimierungen immer auch begründet sein sollten. Bevor du versuchst 1% RAM zu sparen, solltest du sicher sein, dass diese 1% RAM wirklich den Erfolg deines Projektes gefährden.

Version Control System

Ergänzende eigene Gedanken zu clean-code-developer.de

Mein Alltag als Entwickler*in besteht in den seltensten Fällen daraus, dass ich kleine Scripte alleine vor mich hin programmiere (auch wenn das nicht ausschließt ein Version Control System zu nutzen). Viel öfter arbeite ich allerdings mit anderen zusammen, meist auch an etwas komplexerem Code.

Dadurch entstehen 2 Bedürfnisse. Zum einen, möchte ich eine Historie meines Codes haben, einzelne Änderungen nachvollziehen können, ggf. auch rückgängig machen. Das andere ist, dass ich den Quellcode mit den anderen Entwickler*innen teilen, aber trotzdem noch unabhängig von diesen arbeiten möchte.

Diese Bedürfnisse werden von den gängigsten VCS abgedeckt. Bei mir ist das Mittlerweile durchgängig git (erfahre mehr unter https://git-scm.com/). Es existieren aber auch andere, z.B. mercurial, svn und noch viele mehr. In meinem Leben hat git aber alle anderen vertrieben.

Was die meisten aber gemeinsam haben, sind folgende Features:

• Geänderter Code kann als kleines Paket in die Historie des Projektes angehangen werden (git commit)
• Es lassen sich alle Änderungen in dieser Historie anschauen (git log)
• Ist einer Änderung nicht zufriedenstellend, kann diese aus der Historie entfernt werden (git revert)
• Andere Entwickler*innen können sich diese Historie auf ihrem Rechner laden und können eigene Änderungen in die Historie hinzufügen (git pull)
• Eine Entwickler*in kann sich einen Stand in der Historie des Codes nehmen, eine Abzweigung starten und ggf. später wieder zusammen führen (git checkout bzw. git branch)

git selbst funktioniert unheimlich gut bei Dateien, die in einem Textformat vorliegen. Du kannst es also sogar für Sachen benutzen, die nichts mit Programmieren zu tun haben. Z.B. wenn du deine Bachelorarbeit schreibst. Auch hier profitierst du vielleicht von der Versionierung. Binäre Dateien lassen sich leider nicht ganz so gut versionieren.