ITWS BLOG » coding

Deployment von Ruby on Rails Applikationen

Benny — Sat, 10 Dec 2011 21:54:21 +0000

Ich bin ja eigentlich ein sehr großer Fan von Ruby und Ruby on Rails. Der Grund, warum ich mich vor wenigen Jahren davon abgewandt hatte, war, dass es eine riesen Frickelei war eine RoR Application zu deployen. Und das hatte mich damals so genervt, dass ich alles in die Tonne getreten habe und es sein ließ.

Nun hatte ich mich die letzten Tage wieder etwas mit dem Thema RoR Deployment befasst und herausgefunden, dass sich hier in der Zwischenzeit viel getan hat. Dank dem Phusion Passenger (aka mod_rails) Projekt. Habe es vorhin direkt mal ausprobiert und bin davon sehr begeistert. Super performant, super einfach, super super.

Werde demnächst dann wohl wieder etwas mehr mit Ruby on Rails machen

Clean Code: Das KISS-Prinzip

Benny — Fri, 10 Dec 2010 19:53:14 +0000

Diejenigen, die wissen um was es geht, wundert es nicht, dass der nächste Artikel meiner Clean Code-Reihe dem KISS-Prinzip gewidmet ist.

Dem Rest sei gesagt: Dieser Artikel hat nichts mit der US-Amerikanten Hard-Rock-Band aus den 70er zu tun Es handelt sich dabei vielmehr um eine Disziplin beim Programmieren: KISS steht für Keep It Simple, Stupid! im Sinne von "Halt es einfach, Idiot!".

Aber was heißt "einfach"? Einfach bedeutet in diesem Fall, dass man nicht unnötig mehr macht, als wirklich nötig. Denn das kostet im Zweifelsfall nur unnötig Zeit und macht den Code schwerer zu lesen und zu warten.

Leider lassen sich die Entwickler nur zu gern von der "Feature-Geilheit" erfassen und coden wahnsinnige Dinge, die zwar verdammt cool sind, aber niemand braucht und im schlimmsten fall auch sonst niemand versteht. Dies lässt sich wohl darauf zurückführen, dass das Coden an sich eine recht langweilige Sache ist. Selten entwickelt man wirklich innovative und einzigartige Systeme. Meistens implementiert man stattdessen stupide Datenbank-Abfragen, langweilige Business Logiken und unspektakuläre Oberflächen. Im öden Einheits-Code sucht man Herausforderungen und Möglichkeiten seine Fähigkeiten einzusetzen. KISS bedeutet genau diesem Drang zu widerstehen und brav und artig einfach exakt das zu implementieren, was benötigt wird. Nicht mehr, nicht weniger und möglichst aus einer Mücke keinen Elefanten machen.

Clean Code: Das DRY-Prinzip

Benny — Fri, 26 Nov 2010 09:33:07 +0000

Dies ist der erste Teil meiner Artikel-Reihe "Clean Code", welchem noch einige Weitere folgen werden und welche sich hauptsächlich damit befassen, wie man sauberen, wartbaren und stabilen Code schreibt. Ich versuche dabei möglichst von der Programmiersprache selbst zu abstrahieren und mich nur mit den prinzipiellen Mustern und Vorgehensweisen zu beschäftigen. Dennoch muss ich ab und an Code-Beispiele einbringen und da werde ich mir dann wohl mit PHP und Java helfen.

in diesem Artikel geht es also um das DRY-Prinzip, welches nicht nur die einfachste Regel darstellt, sondern zugleich auch die, die am meisten misachtet wird.

DRY steht für Don't Repeat Yourself und der Name ist Programm(code): Ein Code-Fragement sollte immer nur exakt einmal vorkommen und sollte man dieses Fragment nochmal benötigen, wird es in eine Funktion/Methode ausgelagert. Leider erfordert das klassiche Copy'n'Paste weitaus weniger Aufwand und Gehirn-Aktivität, weshalb dies meist die bevorzugte Vorgehensweise ist. Gerade wenn es schnell gehen muss, spart man sich den Aufwand eine neue Methode zu implementieren gerne.

Dieses leichtsinnige Verhalten bläht nicht nur den Code auf, wie man erst vermuten mag: Das eigentliche Problem sind die potentiellen Fehlerquellen, die man dadurch erschafft.
Stelen wir uns folgendes Szenario vor:
Wir haben ein Code-Fragment geschrieben, welches die Verbindung zu einem IMAP-Server aufbaut, eine Liste der ungelesenen E-Mails erstellt und die Verbindung wieder schließt. Diese Funktion benötigen wir an einer anderen Stelle in einer anderen Klasse nochmal, also wird das Code-Fragment einfach kopiert. Nach einiger Zeit fällt auf "Ups, hab die Zeile, mit dem close-Aufruf vergessen zu kopieren …". Diese wir dann noch schnell hinterhergeworfen und direkt haben wir den ersten Fehler: Beim Kopieren wurde das Code-Fragment verändert weil ein Teil nicht mitkopiert wurde.

Zwei Monate später, soll ein Kollege einen Bugfix an diesem Code-Fragment durchführen. Er weiß in welcher Datei und in welcher Zeile der Fehler aufgetreten ist, öffnet diese Datei, korrigiert die Zeile, schließt die Datei, führt ein commit durch und damit wars das. Und hier haben wir direkt das nächste Problem: Dieses Code-Fragment, welches gerade korrigiert wurde, kommt (mit genau dem gleichen Fehler) noch an mindestens einer weiteren Stelle im Code vor. Dieser redundante Code wurde nicht korrigiert, entsprechend unterscheiden sich diese beiden Code-Fragmente, welche exakt die gleiche Aufgabe haben, nun voneinander: es herrscht Inkonsistenz.
Der entsprechende Entwickler hätte nun also prüfen müssen, ob dieses Snippet noch öfter vorkommt und entsprechend jede Instanz mit dem Bugfix versehen müssen. Oder das ganze einem Refactoring unterziehen müssen. Beides bedeutet zusätzlicher Aufwand und zwar mehr als es gekostet hätte es direkt ordentlich zu machen.

Ein Tool, das beim Finden von doppelten Code-Fragmenten hilft, ist die so genannte Copy'n'Paste-Detection. Dies ist in den meisten Continous Integration Systemen enthalten und hilft ungemein, den Code zu verbessern.

Fazit: Doppelte Code-Fragmente, welche durch Copy'n'Paste quer im Projekt verteilt werden, erzeugen schnell Inkonsistenzen, erhöhen die Fehleranfälligkeit und sind Gift für die Wartbarkeit eines Projekts. Bei jedem Programmierer sollten also alle Alarmglocken läuten, wenn er die selbe Funktionalität mehr als einmal benötigt. Hier sollte immer eine neue Methode/Funktion implementiert werden.

ITWS BLOG » coding

Deployment von Ruby on Rails Applikationen

Ähnliche Artikel

Clean Code: Das KISS-Prinzip

Ähnliche Artikel

Clean Code: Das DRY-Prinzip

Ähnliche Artikel