Ruby on Rails: Wie wichtig es ist, 1.0 zu sein

ZDNet: Könnten Sie etwas detaillierter beschreiben, wie Sie bei der Entwicklung von Rails vorgegangen sind?

Heinemeier Hansson: Der hilfreichste Ansatz bei der Entwicklung von Ruby war die Idee, dass Frameworks Auskopplungen sind. Sie sind die allgemeinen, nützlichen Teile, die Sie in vorhandenen Anwendungen finden. Sie sind keine Vorhersagen und kein Kaffeesatzlesen darüber, was ein Programmierer bei einer zukünftigen Anwendung vielleicht haben möchte.

Ich habe mich also nicht hingesetzt, um Rails zu erstellen. Ich wollte Basecamp erstellen, eine echte Anwendung, die wir bei 37signals entwickelt haben. Diese Anwendung hat das Design des Frameworks angetrieben, indem ich eine neue Funktion in Basecamp implementiert habe, dann habe ich den Code angesehen, abstrahiert, extrahiert und weitergemacht.

Bis heute ist dies immer noch unsere wichtigste Quelle für neue Funktionen in Rails: Kram, den wir erst in echten Anwendungen einbauen, dann extrahieren. Rails ist eine Sammlung von Lösungen für echte Probleme, denen die Mitwirkenden ausgesetzt waren.

ZDNet: Sie sagten vorhin, dass Sie kleinere Teams bei der Entwicklung vorziehen. In welchem Maß wird Rails immer noch auf diese Weise entwickelt, in Anbetracht seiner Popularität? Wie konnten Sie mit wachsender Projektgröße die Entwicklung in einer kleinen Gruppe konzentriert halten?

Heinemeier Hansson: So lange wie möglich kontrollierte ich die Entwicklung von Rails, indem ich der einzige war, der Patches in den Codespeicher anwenden konnte. Alles lief über mich. Damit war eine Vision gesichert und eine Kultur festgelegt. Heutzutage sind wir eine etwa 12köpfige Gruppe mit festgelegten Rechten, und davon führt etwa die Hälfte die Rechte regelmäßig aus. Damit wird der größte Teil von Rails weiterhin von einem sehr kleinen Team entwickelt oder zumindest überprüft.

Aber wir erlebten einen riesigen Ansturm von Beiträgen engagierter Programmierer, die Rails aus allen Blickwinkeln erweitert haben. Neue Patches und Tickets über Grenzfallprobleme prasseln in einem enormen Tempo auf uns ein, so schnell, dass wir gar nicht mithalten können. Aber das ist in Ordnung. Ich übersehe lieber aus Versehen einen guten Patch, als dass ich drei schlechte aufnehme.

ZDNet: Wie passt Ihrer Meinung nach Ihr Ansatz zum Konzept des konzeptuellen Framework der Agile Softwareentwicklung?

Heinemeier Hansson: Sowohl 37signals als Firma als auch Ruby on Rails als Framework sind eng an die Entwicklungsphilosophie von Agile angelehnt. Viele Prioritäten von Agile sind bei Rails gleich mit drin. Wir haben unglaublich starke Testeinrichtungen, eine engmaschige Änderungs- und Auswirkungs-Feedbackschleife, um kleine Iterationen zu fördern, und allgemein eine Abneigung gegenüber großen Vorschusslorbeeren.

Dem Ansatz von Agile positiv gegenüber zu stehen ist also mehr oder weniger Bedingung, um auf den Zug von Rails aufspringen zu können. Es gibt definitiv einen Austausch zwischen Kultur und Code in Rails. Wer nicht mit dem Agile-Programm mithält, wird in Rails vermutlich nicht gut hineinpassen.