Startup Lesson 28: Softwareentwicklung mit Ruby on Rails - Fehler, die man vermeiden sollte
Donnerstag, 20.November 2008 , Autor: JasonSoftware kommt mir manchmal wie ein Domino-Spiel vor: fällt ein Steinchen um, ist in Windeseile die ganze Website platt. TILT. GAME OVER. Software ist anfälliger als jeder Mensch. Ein Schnupfen behindert einen schon mal, aber tötet nicht unbedingt. Ist aber ein Hochkomma-Zeichen nicht gesetzt, dann kann alles andere plötzlich stehen bleiben. Dies ist uns in den letzten Tagen / Wochen immer wieder passiert. Dass plötzlich ohne ersichtlichen Grund eine wichtige Funktion auf der Plattform nicht mehr oder nicht richtig funktionierte oder auch, dass wir alles neustarten mussten, weil woobby einen Herzstillstand hatte.
Dennoch ist Software kein Mensch, sondern von Menschen gemacht. Und die machen nun mal Fehler. Wir haben davon einige gemacht. Und über einen ganz großen Fehler, den man mit etwas Erfahrung vermeiden kann, möchte ich heute berichten. Wir haben als Software für unsere Plattform woobby.com Ruby on Rails ausgesucht - wie an anderer Stelle bereits berichtet wurde - weil diese Software uns einige Vorteile gegenüber der Alternative “Programmieren mit PHP” versprach.
Der Einsatz von Ruby on Rails bedeutet im Kern, dass die Plattformentwicklung im Rahmen der agilen Softwareentwicklung testgetrieben stattfinden sollte. DIES IST ELEMENTAR für den Einsatz von Ruby on Rails. Klassischerweise kommt das Testen am Schluss. Häufige Nachteile:
- aus Zeitdruck wird die geplante Testphase häufig verkürzt, man will ja LIVE stellen / Deadlines einhalten.
- Die Testabdeckung ist häufig unzureichend, da Konzept und Realität abweichen
- neben fachlichen Tests sind Entwicklertests von Nöten - auf die gerne aus Zeitdruck verzichtet wird
Ruby on Rails will diese Nachteile durch eine andere Vorgehensweise vermeiden: man schreibt zuerst Testfälle, stellt sicher, dass sie daneben gehen, implementiert dann erforderlichen Programmcode, der dafür sorgt, dass der Test fehlerfrei läuft. D.h. es werden Tests noch vor der Entwicklung der zu testenden Software-Komponenten gemacht. So stellt man von vorneherein sicher, dass keine Bugs entstehen und die Software funktioniert. Idealerweise….
Wir haben einen erfahrenen PHP Programmierer beauftragt, woobby zu entwickeln. Bei PHP testet man im klassischen Sinne. Und wir waren Ruby on Rails-Rookies. Dementsprechend liegt unsere Testabdeckung heute bei etwa 10%. Die Folge: jeder neue Programmierer kann nicht testen, ob dies oder jenes auf der Plattform reibungslos funktioniert. Baut er hier etwas an, wackelt das Gebäude an einer ganz entfernten Stelle. Und niemand weiss auf den ersten Blick, warum. Dann fangen alle wie Sherlock Holmes an zu suchen. Wie hat es einer unserer aktuellen Programmierer so schön ausgedrückt: “This leads to my assumption that between 50% and 200% of the development time is being spent with bug finding and fixing after changes. The larger a project gets, the more effect this will have on the development budget. Unit test and functional tests cost about 25% of project development time against between 50% and 200% bug fixing time when too few tests have been written.”
Das ist evil!!! Unbedingt vermeiden! Erfordert Erfahrung und Disziplin von jedem Ruby on Rails-Entwickler. Unbedingt von Beginn an darauf achten, dass dieses Prinzip konsequent und einheitlich eingehalten wird!
Gute Websites zum Thema Ruby on Rails findet Ihr hier. Und wer lieber offline lernt, kann hier gute Ruby on Rails-Bücher finden.
Good luck!!!
php programmierer sagt:
20.November 2008
Solche abwertenden Bemerkungen über “Programmieren mit PHP” regen mich echt auf, als ob das der Inbegriff des schlechten Programmierens wäre. Und fals Ihr es noch nicht gemerkt habt, nicht nur der Web2.0 Hype ist vorbei, auch im Rails Lager macht sich Ernüchterung breit. Die ganzen tollen Funktionen bringen nichts wenn der Programmierer die Konzepte nicht beherscht, wie man ganz klar aus eurem Bericht herauslesen kann.
Die Wahrheit ist einfach, am Ende des Tages ist nicht entscheidend welches Framework man verwendet hat, sondern WIE man es verwendet. Was zählt sind Konzepte und Erfahrung, und nicht der neueste Hype!
Jason sagt:
20.November 2008
Hallo PHP Programmierer - das war definitiv null abwertend gemeint. Wir haben uns für Ruby entschieden, nachdem wir mit 6 Programmieren - alle mit PHP Hintergrund gesprochen haben. Die Hälfte hatte damals (April 2007) und Ruby on Rails empfohlen für das, was wir tun wollten. Ich bin nach wie vor überzeugt, dass die Entscheidung richtig war. Nur hätten wir von Beginn an uns mehr mit dem WIE beschäftigen sollen. Da hast Du vollkommen recht. Aber das ist ja auch genau der Inhalt dieser “Lesson” für uns - und vielleicht für den einen oder anderen Leser, der noch VOR den Fehlern steht und diese vielleicht so vermeiden kann.
Mirko sagt:
24.November 2008
Ich glaube das jede Sprache Ihre Vor und Nachteile hat. Bei Ruby ist es defenetiv die skalierung der Server. PHP ist oft bei großen Projekten etwas unübersichtlich, was einach daran liegt das sich kaum jemand die Mühe der Dokumentation macht.