David Heinemeier Hansson Interview
Vorwort
David Heinemeier Hansson ist der Schöpfer von Ruby on Rails, Mitbegründer und CTO von Basecamp, Bestsellerautor, Rennfahrer in Le Mans, Familienvater, häufiger Podcast-Gast und inspirierender Konferenzredner.
Ruby on Rails wurde von David 2003 entwickelt, und seit der Gründung von Evrone im Jahr 2008 verwenden wir das Open-Source Web-Framework Rails täglich. Es hat uns bereits tausende Male dabei unterstützt, schönen Code für unsere Projekte zu schreiben. Neben der Entwicklung eines der nützlichsten Tools in der Software-Entwicklung hat David noch viele andere beeindruckende Leistungen vollbracht, vom Schreiben der Bücher „It Doesn't Have To Be Crazy At Work“, „REWORK“ und „REMOTE: Office Not Required“ bis hin zur Teilnahme bei der FIA World Endurance Championship. 2014 belegte er beim 82. 24-Stunden-Rennen von Le Mans, dem weltweit renommiertesten Sportwagen-Langstreckenrennen, den ersten Platz in seiner Klasse. In diesem Jahr gewann er auch die FIA-Langstrecken-Weltmeisterschaft in der Kategorie GTE-Am.
2020 haben wir David eingeladen, auf RubyRussia, Evrones 11. jährlicher Moskauer Programmierer-Konferenz, zu sprechen. Vor der Veranstaltung hatten wir die Gelegenheit, mit David über die Welt der Software-Entwicklung und seinen Ansatz zum Schreiben von phänomenalem Code zu sprechen.
Das Interview
Evrone: Hey David, es ist uns eine Freude, heute mit Ihnen zu sprechen. Beginnen wir mit unserem Interview. Wie kann ein durchschnittlicher Entwickler am besten entscheiden, ob er mit einem „Low-JavaScript“-Ansatz beginnen und seine Anwendung später weiterentwickeln soll, oder ob er von Anfang an Angular, React oder Vue verwenden muss? Welche Entscheidungsstrategie würden Sie empfehlen?
David: Wenn man etwas programmieren will, das wie eine Vanilla-Webanwendung aussieht und sich anfühlt, so wie Basecamp, GitHub oder Shopify, dann denke ich, dass Minimal-JS der richtige Weg ist. Es ist nach wie vor JS, nur eben minimalistisch. Wenn man etwas programmiert, das hochgradig interaktiv ist, wie z. B. ein Spiel oder eine Anwendung zum Bearbeiten von Fotos, dann macht es Sinn, sich mit einem vollständigen SPA zu befassen. Das gilt für die meisten Anwendungsfälle, wo ein einzelner Bildschirm der Anwendung bereits über unzählige verschiedene Zustände verfügt.
Evrone: Da die Codebasis und das Team immer größer werden, welche Teile der typischen Rails-Anwendung würden Sie für den Übergang zu Microservices empfehlen? Angesichts der Tatsache, dass sich jedes Unternehmen eine gute Organisation bei der Codeentwicklung wünscht, ist es keine Option, das gesamte Produkt von Grund auf neu zu schreiben.
David: Es ist eine Illusion, dass man, wenn man Software nicht gut genug geschrieben hat, um beim ersten Mal keine Fehler zu machen, beim zweiten Mal besser darin sein wird. Man muss sich neue Gewohnheiten aneignen und sie dort anwenden, woran man täglich arbeitet. Sarah Mei hat auf der RailsConf 2018 einen großartigen Vortrag darüber gehalten. Sie hat darüber gesprochen, dass die Codebasis etwas ist, das wir nicht wirklich selbst erstellen. Eine Codebasis ist ein Ort, an dem wir leben, und unser Ziel ist es, sie für uns selbst und für alle anderen Menschen, die dort leben, lebenswert zu machen. Wenn wir Code schreiben, ist es nicht unser Ziel, ihn fertig zu stellen und direkt weiterzumachen. Unser Ziel ist es, ihn für das Team, das ihn verwendet, nachhaltig und angenehm zu gestalten.
Man kann so viele Neufassungen vornehmen, wie man will, aber wenn man die kleinen Dinge, die einen überhaupt erst dazu gebracht haben, nicht ändert, hat man am Ende nur ein verworrenes Netzwerk von Microservices. Man hat also genau solch ein verworrenes Netzwerk wie bei den ganzen Klassendefinitionen im Monolithen. Der Code ist buchstäblich ein Wohnraum, der von Menschen bewohnt wird. Der wichtige Teil der Software ist das System. Der Code und die Menschen gehören zusammen und sind unzertrennlich. Je mehr wir uns Software als ein miteinander verbundenes System aus Code und Menschen vorstellen können, desto näher kommen wir einem Durchbruch. So kommen wir auch einer Revolution, einem Paradigmenwechsel, ein Stück näher. Und was für uns vielleicht am wichtigsten ist, wir lernen dadurch eine Codebasis aufzubauen, an der wir gerne arbeiten.
Evrone: Wow, das klingt umwerfend, und wir können dem eigentlich nichts mehr hinzufügen! Welchen Ansatz würden Sie empfehlen, wenn Sie zwischen „Monkey-Patching“ und anderen Code-Kompositionsmustern wählen müssten? Was sollten wir bedenken, um die Freiheit beim Patchen nicht in ein Durcheinander von widersprüchlichen Überschreibungen zu verwandeln?
David: „Freedom Patches“ dienen zum Erstellen allgemeiner Dialekte der Sprache. Active Support steckt voller Freedom Patches. Es dient nicht zum Erstellen von anwendungsspezifischen Änderungen.
Evrone: Sie haben in Ihrem Leben sicherlich viel Ruby-Code gesehen. Was macht Code Ihrer persönlichen Meinung nach gut oder schlecht? Irgendetwas, das Ihnen sofort ins Auge sticht?
David: Wenn der Code schlecht geschrieben ist, erkennt man das normalerweise sofort, bevor man sich überhaupt die Logik anschaut. Keine ordentliche Einrückung, gemischte Code-Stile und eine fehlende Code-Pflege im Allgemeinen. Man lernt nie aus, wenn es darum geht, guten Code zu schreiben. Wie ich in meiner Keynote zur RailsConf 2014 erwähnt habe, sind wir keine Softwareentwickler, sondern Software-Autoren. „Autor“ ist eine viel passendere Metapher für das, was wir die meiste Zeit tun, als „Entwickler“. Beim Schreiben von Code geht es um Klarheit und eine übersichtliche Darstellung von Informationen, damit jeder sie verstehen kann.
Es gibt keine Liste von Prinzipien und Praktiken, die jemandem beigebracht werden können, damit sein Code automatisch jedes Mal für jeden verständlich ist. Wenn man ein guter Schriftsteller sein will, reicht es nicht aus, nur das Wörterbuch auswendig zu lernen. Alle Wörter zu kennen, also mit allen Entwicklungsmustern vertraut zu sein, macht noch keinen guten Programmierer. Man muss dafür erst einen Blick entwickeln. Man muss sich bewusst dafür entscheiden, Verständlichkeit zu priorisieren. Hat man das getan, kann man langsam ein Gespür dafür entwickeln.
Der einzige Weg, ein guter Programmierer zu werden – wobei ich per Definition einen guten Programmierer als jemanden verstehe, der Software mit verständlichem Code schreibt – ist, viel Code zu lesen und viel Code zu schreiben.
Evrone: Absolut. Normalerweise ist es für CEOs, die nicht selber Programmierer sind, schwer, die Konzepte der „technischen Verschuldung“, der „Architektur“ und des mehrfachen Umschreibens derselben Anwendung zu begreifen. Wie würden Sie als Programmierer und Geschäftsmann empfehlen, Unternehmer ohne Programmiererfahrung von diesen Konzepten zu überzeugen?
David: Ich glaube so gut wie nie daran, dass man eine App aus technischen Gründen umschreiben sollte. Sarah Meis Keynote beleuchtet, warum. Ich glaube allerdings an das Neuschreiben, wenn man die fundamentale Funktionsweise der Anwendung ändern will. Ich habe viel dazu in einem Vortrag auf der Business of Software Conference USA erzählt.
Wir haben den Code für Basecamp mehrmals neu geschrieben und veröffentlicht. Natürlich ist es schön, mit seinen eigenen Kunden alt zu werden. Das hat viele Vor- und auch viele Nachteile. Man braucht allerdings auch frischen Wind, denn wenn alles statisch bleibt, hat man irgendwann nur noch einen sehr alten und einen sehr schrumpfenden neuen Kundenstamm. Die eigenen Kunden kündigen vielleicht ihren Job und verwenden das Produkt nicht mehr.
Das Problem ist, wenn man sich nicht um neue Kunden kümmert, hat man irgendwann gar keine mehr. Man muss Änderungen vornehmen, während alles gut läuft. Dies ist normalerweise allerdings die schwierigste Zeit dafür.
Niemand wird für immer daran interessiert bleiben, an der genau gleichen Umsetzung seiner Ideen von vor fünfzehn Jahren zu arbeiten. So funktioniert es einfach nicht. Bringt man jedoch regelmäßig frischen Wind in das Projekt und arbeitet man kontinuierlich daran, kann man sich seinen Zukunftsängsten in dieser Hinsicht entledigen. Schreiben Sie also Ihre Software ruhig neu.
Evrone: Und jetzt unsere bekannte „Zeitreise“-Frage! Wenn Sie die Gelegenheit hätten, in die Zeit zurück zu reisen, in der Sie angefangen haben, Rails aus Basecamp zu extrahieren, welchen technischen Rat würden Sie Ihrem jüngeren Ich geben?
David: Ich hätte davon nichts wissen wollen. Unwissenheit ist Glückseligkeit.
Wir freuen uns sehr, David als Speaker bei der RubyRussia-Konferenz 2020 begrüßen zu dürfen. Unser Team hier bei Evrone freut sich auch auf die weitere Entwicklung von Basecamp und natürlich Ruby on Rails. Je leistungsfähiger das Framework wird, desto besser sind die Lösungen, die wir für unsere Kunden und Partner entwickeln können. Wenn Sie eine Projektidee haben und an der Verwendung von Ruby on Rails interessiert sind, sind unsere Entwickler jederzeit gerne bereit, Ihre Möglichkeiten mit Ihnen zu besprechen. Ganz gleich, in welcher Phase der Entwicklung Ihres Projekts Sie sich befinden, zögern Sie nicht, uns Ihre Kontaktdaten zu hinterlassen, und wir werden uns bald mit Ihnen in Verbindung setzen. So können wir gemeinsam herausfinden, wie wir Ihnen dabei helfen können, Ihr Ziel zu erreichen.