Softwareentwicklung bei Google

Vorwort

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: [e-mail]

Dieses Buch trägt den Titel Softwareentwicklung bei Google. Was genau verstehen wir unter Softwareentwicklung? Was unterscheidet "Softwareentwicklung" von "Programmierung" oder "Informatik"? Und warum hat Google eine einzigartige Perspektive, die dem Korpus der Literatur über Softwareentwicklung aus den letzten 50 Jahren hinzugefügt werden kann?

Die Begriffe "Programmieren" und "Softwareentwicklung" werden in unserer Branche schon seit einiger Zeit synonym verwendet, obwohl jeder Begriff einen anderen Schwerpunkt und eine andere Bedeutung hat. Universitätsstudenten studieren in der Regel Informatik und bekommen Aufträge als "Programmierer", die Code schreiben.

Der Begriff "Softwareentwicklung" klingt jedoch ernster, als ob er die Anwendung von theoretischem Wissen impliziert, um etwas Reales und Präzises zu bauen. Maschinenbauingenieure, Bauingenieure, Luftfahrtingenieure und Ingenieure anderer Fachrichtungen sind alle als Ingenieure tätig. Sie alle arbeiten in der realen Welt und wenden ihr theoretisches Wissen an, um etwas Reales zu schaffen. Auch Softwareentwickler/innen schaffen "etwas Reales", auch wenn es weniger greifbar ist als das, was andere Ingenieur/innen schaffen.

Im Gegensatz zu diesen etablierteren Ingenieursberufen ist die Theorie und Praxis der Softwareentwicklung nicht annähernd so rigoros. Luftfahrtingenieure und -ingenieurinnen müssen strenge Richtlinien und Praktiken befolgen, weil Fehler in ihren Berechnungen echten Schaden anrichten können; bei der Programmierung wird im Allgemeinen nicht so streng vorgegangen. Aber da Software immer mehr in unser Leben integriert wird, müssen wir uns auf strengere technische Methoden verlassen. Wir hoffen, dass dieses Buch anderen hilft, einen Weg zu zuverlässigeren Softwarepraktiken zu finden.

Programmierung im Laufe der Zeit

Wir schlagen vor, dass "Softwareentwicklung" nicht nur das Schreiben von Code umfasst, sondern auch alle Werkzeuge und Prozesse, die ein Unternehmen einsetzt, um diesen Code zu erstellen und langfristig zu pflegen. Welche Praktiken kann ein Softwareunternehmen einführen, um den Wert seines Codes langfristig zu erhalten? Wie können Ingenieure eine Codebasis nachhaltiger und die Disziplin der Softwareentwicklung selbst strenger gestalten? Wir haben keine grundlegenden Antworten auf diese Fragen, aber wir hoffen, dass die kollektiven Erfahrungen von Google in den letzten zwei Jahrzehnten mögliche Wege aufzeigen, diese Antworten zu finden.

Eine wichtige Erkenntnis, die wir in diesem Buch vermitteln, ist, dass Softwareentwicklung als "integrierte Programmierung über die Zeit" betrachtet werden kann. Welche Praktiken können wir in unseren Code einführen, um ihn nachhaltigzu machen - damiter auf notwendige Veränderungen reagieren kann- und zwar über seinen gesamten Lebenszyklus hinweg, von der Konzeption über die Einführung bis hin zur Wartung und Veraltung?

Das Buch hebt drei grundlegende Prinzipien hervor, die Softwareunternehmen unserer Meinung nach bei der Entwicklung, der Architektur und dem Schreiben ihres Codes beachten sollten:

Zeit und Wandel

Wie sich der Code im Laufe seiner Lebensdauer anpassen muss

Größe und Wachstum

Wie sich eine Organisation anpassen muss, wenn sie sich weiterentwickelt

Kompromisse und Kosten

Wie eine Organisation Entscheidungen trifft, basierend auf den Lektionen von Zeit und Wandel sowie Größe und Wachstum

In allen Kapiteln haben wir versucht, an diese Themen anzuknüpfen und Wege aufzuzeigen, wie diese Prinzipien die technische Praxis beeinflussen und nachhaltig machen. (Siehe Kapitel 1 für eine ausführliche Diskussion.)

Googles Sichtweise

Google hat eine einzigartige Perspektive auf das Wachstum und die Entwicklung eines nachhaltigen Software-Ökosystems, die sich aus unserer Größe und Langlebigkeit ergibt. Wir hoffen, dass die Lektionen, die wir gelernt haben, nützlich sind, wenn sich dein Unternehmen weiterentwickelt und nachhaltigere Praktiken einführt.

Wir haben die Themen in diesem Buch in drei Hauptaspekte der Softwareentwicklung bei Google unterteilt:

• Kultur

• Prozesse

• Werkzeuge

Die Kultur von Google ist einzigartig, aber die Lektionen, die wir bei der Entwicklung unserer Entwicklungskultur gelernt haben, sind allgemein anwendbar. Unsere Kapitel über Kultur(Teil II) betonen den kollektiven Charakter eines Softwareentwicklungsunternehmens, dass die Entwicklung von Software eine Teamleistung ist und dass die richtigen kulturellen Grundsätze für ein Unternehmen unerlässlich sind, um zu wachsen und gesund zu bleiben.

Die in den Kapiteln zu den Prozessen(Teil III) beschriebenen Techniken sind den meisten Softwareentwicklern vertraut, aber die Größe und Langlebigkeit der Codebasis von Google ist ein umfassenderer Stresstest für die Entwicklung bewährter Methoden. In diesen Kapiteln haben wir versucht, das hervorzuheben, was sich im Laufe der Zeit und im großen Maßstab bewährt hat, und die Bereiche aufzuzeigen, auf die wir noch keine zufriedenstellenden Antworten haben.

In den Kapiteln zu den Tools(Teil IV) wird erläutert, wie wir unsere Investitionen in die Tooling-Infrastruktur nutzen, um unsere wachsende und alternde Codebasis zu unterstützen. In einigen Fällen handelt es sich um Google-spezifische Tools, aber wir weisen auch auf Open-Source- oder Drittanbieter-Alternativen hin, wo dies möglich ist. Wir gehen davon aus, dass diese grundlegenden Erkenntnisse für die meisten technischen Organisationen gelten.

Die Kultur, die Prozesse und die Werkzeuge, die in diesem Buch beschrieben werden, beschreiben die Lektionen, die ein typischer Softwareentwickler hoffentlich bei der Arbeit lernt. Google hat sicherlich kein Monopol auf gute Ratschläge, und unsere hier dargestellten Erfahrungen sollen nicht vorschreiben, was dein Unternehmen tun sollte. Dieses Buch ist unsere Sichtweise, aber wir hoffen, dass du es nützlich findest, indem du diese Lektionen entweder direkt übernimmst oder sie als Ausgangspunkt für deine eigenen Praktiken verwendest, die auf deinen eigenen Problembereich spezialisiert sind.

Dieses Buch ist auch nicht als Predigt gedacht. Google selbst wendet viele der Konzepte auf diesen Seiten noch immer unvollkommen an. Die Lektionen, die wir gelernt haben, haben wir durch unsere Misserfolge gelernt: Wir machen immer noch Fehler, setzen unvollkommene Lösungen um und müssen uns ständig verbessern. Doch die schiere Größe von Googles Entwicklungsorganisation sorgt dafür, dass es für jedes Problem eine Vielzahl von Lösungen gibt. Wir hoffen, dass dieses Buch das Beste aus dieser Gruppe enthält.

Was dieses Buch nicht ist

Dieses Buch ist nicht dazu gedacht, Softwaredesign zu behandeln, eine Disziplin, die ein eigenes Buch erfordert (und für die es bereits viele Inhalte gibt). Obwohl dieses Buch zur Veranschaulichung etwas Code enthält, sind die Prinzipien sprachneutral und es gibt nur wenige tatsächliche "Programmier"-Ratschläge in diesen Kapiteln. Daher werden in diesem Text viele wichtige Themen der Softwareentwicklung nicht behandelt: Projektmanagement, API-Design, Sicherheitshärtung, Internationalisierung, Benutzeroberflächen-Frameworks oder andere sprachspezifische Themen. Dass sie in diesem Buch nicht behandelt werden, bedeutet nicht, dass sie nicht wichtig wären. Vielmehr haben wir uns entschieden, sie hier nicht zu behandeln, weil wir wussten, dass wir ihnen nicht die Aufmerksamkeit schenken können, die sie verdienen. Wir haben versucht, die Diskussionen in diesem Buch mehr über die Technik und weniger über das Programmieren zu führen.

Abschiedsbemerkungen

Alle, die an diesem Text mitgewirkt haben, haben ihn mit viel Liebe verfasst und wir hoffen, dass du ihn so aufnimmst, wie er dir gegeben wurde: als einen Einblick in die Art und Weise, wie ein großes Unternehmen der Softwareentwicklung seine Produkte herstellt. Wir hoffen auch, dass er eine von vielen Stimmen ist, die dazu beitragen, dass unsere Branche zukunftsorientiertere und nachhaltigere Praktiken anwendet. Vor allem aber hoffen wir, dass du Spaß an der Lektüre hast und einige der Lektionen für deine eigenen Anliegen übernehmen kannst.

Tom Manshreck

In diesem Buch verwendete Konventionen

In diesem Buch werden die folgenden typografischen Konventionen verwendet:

Kursiv

Weist auf neue Begriffe, URLs, E-Mail-Adressen, Dateinamen und Dateierweiterungen hin.

Constant width

Wird für Programmlistings sowie innerhalb von Absätzen verwendet, um auf Programmelemente wie Variablen- oder Funktionsnamen, Datenbanken, Datentypen, Umgebungsvariablen, Anweisungen und Schlüsselwörter hinzuweisen.

Constant width bold

Zeigt Befehle oder anderen Text an, der vom Benutzer wortwörtlich eingetippt werden sollte.

Constant width italic

Zeigt Text an, der durch vom Benutzer eingegebene Werte oder durch kontextabhängige Werte ersetzt werden soll.

Hinweis

Dieses Element steht für einen allgemeinen Hinweis.

O'Reilly Online Learning

Hinweis

Seit mehr als 40 Jahren bietet O'Reilly Media Schulungen, Wissen und Einblicke in Technologie und Wirtschaft, um Unternehmen zum Erfolg zu verhelfen.

Unser einzigartiges Netzwerk von Experten und Innovatoren teilt sein Wissen und seine Erfahrung durch Bücher, Artikel und unsere Online-Lernplattform. Die Online-Lernplattform von O'Reilly bietet dir On-Demand-Zugang zu Live-Trainingskursen, ausführlichen Lernpfaden, interaktiven Programmierumgebungen und einer umfangreichen Text- und Videosammlung von O'Reilly und über 200 anderen Verlagen. Weitere Informationen findest du unter http://oreilly.com.

Wie du uns kontaktierst

Bitte richte Kommentare und Fragen zu diesem Buch an den Verlag:

• O'Reilly Media, Inc.
• 1005 Gravenstein Highway Nord
• Sebastopol, CA 95472
• 800-998-9938 (in den Vereinigten Staaten oder Kanada)
• 707-829-0515 (international oder lokal)
• 707-829-0104 (Fax)

Wir haben eine Webseite für dieses Buch, auf der wir Errata, Beispiele und zusätzliche Informationen auflisten. Du kannst diese Seite unter https://oreil.ly/software-engineering-at-google aufrufen .

Schreib eine E-Mail an [e-mail], um Kommentare oder technische Fragen zu diesem Buch zu stellen.

Neuigkeiten und weitere Informationen zu unseren Büchern und Kursen findest du auf unserer Website unter http://www.oreilly.com.

Finde uns auf Facebook: http://facebook.com/oreilly

Folge uns auf Twitter: http://twitter.com/oreillymedia

Schau uns auf YouTube: http://www.youtube.com/oreillymedia

Danksagungen

Ein Buch wie dieses wäre ohne die Arbeit von unzähligen anderen nicht möglich. Das gesamte Wissen in diesem Buch haben wir alle durch die Erfahrungen vieler anderer bei Google im Laufe unserer Laufbahn erworben. Wir sind die Boten; andere kamen vor uns, bei Google und anderswo, und lehrten uns das, was wir euch jetzt präsentieren. Wir können sie hier nicht alle aufzählen, aber wir möchten uns bei ihnen bedanken.

Wir möchten uns auch bei Melody Meckfessel bedanken, die dieses Projekt in seinen Anfängen unterstützt hat, sowie bei Daniel Jasper und Danny Berlin, die es bis zur Fertigstellung begleitet haben.

Dieses Buch wäre ohne die gemeinsame Anstrengung unserer Kuratoren, Autoren und Redakteure nicht möglich gewesen. Obwohl die Autoren und Redakteure in jedem Kapitel oder in den Aufrufen ausdrücklich erwähnt werden, möchten wir uns die Zeit nehmen, all diejenigen zu würdigen, die mit ihren durchdachten Beiträgen, Diskussionen und Rezensionen zu jedem Kapitel beigetragen haben.

• Was ist Softwareentwicklung? Sanjay Ghemawat, Andrew Hyatt

• Gut im Team arbeiten: Sibley Bacon, Joshua Morton

• Wissen teilen: Dimitri Glazkov, Kyle Lemons, John Reese, David Symonds, Andrew Trenk, James Tucker, David Kohlbrenner, Rodrigo Damazio Bovendorp

• Technik für Gerechtigkeit: Kamau Bobb, Bruce Lee

• Wie man ein Team führt: Jon Wiley, Laurent Le Brun

• Führen in großem Maßstab: Bryan O'Sullivan, Bharat Mediratta, Daniel Jasper, Shaindel Schwartz

• Die Produktivität von Ingenieuren messen: Andrea Knight, Collin Green, Caitlin Sadowski, Max-Kanat Alexander, Yilei Yang

• Style Guides und Regeln: Max Kanat-Alexander, Titus Winters, Matt Austern, James Dennett

• Codeüberprüfung: Max Kanat-Alexander, Brian Ledger, Mark Barolak

• Dokumentation: Jonas Wagner, Smit Hinsu, Geoffrey Romer

• Testübersicht: Erik Kuefler, Andrew Trenk, Dillon Bly, Joseph Graves, Neal Norwitz, Jay Corbett, Mark Striebeck, Brad Green, Miško Hevery, Antoine Picard, Sarah Storck

• Einheitstests: Andrew Trenk, Adam Bender, Dillon Bly, Joseph Graves, Titus Winters, Hyrum Wright, Augie Fackler

• Test-Doppel: Joseph Graves, Gennadiy Civil

• Größere Tests: Adam Bender, Andrew Trenk, Erik Kuefler, Matthew Beaumont-Gay

• Abschaffung: Greg Miller, Andy Shulman

• Versionskontrolle und Zweigstellenmanagement: Rachel Potvin, Victoria Clarke

• Code-Suche: Jenny Wang

• Systeme aufbauen und Philosophie aufbauen: Hyrum Wright, Titus Winters, Adam Bender, Jeff Cox, Jacques Pienaar

• Kritik: Das Codeüberprüfungs-Tool von Google: Mikołaj Dądela, Hermann Loose, Eva May, Alice Kober-Sotzek, Edwin Kempin, Patrick Hiesel, Ole Rehmsen, Jan Macek

• Statische Analyse: Jeffrey van Gogh, Ciera Jaspan, Emma Söderberg, Edward Aftandilian, Collin Winter, Eric Haugh

• Abhängigkeitsmanagement: Russ Cox, Nicholas Dunn

• Großflächige Veränderungen: Matthew Fowles Kulukundis, Adam Zarek

• Kontinuierliche Integration: Jeff Listfield, John Penix, Kaushik Sridharan, Sanjeev Dhanda

• Kontinuierliche Lieferung: Dave Owens, Sheri Shipe, Bobbi Jones, Matt Duftler, Brian Szuter

• Compute Services: Tim Hockin, Collin Winter, Jarek Kuśmierek

Außerdem möchten wir Betsy Beyer dafür danken, dass sie ihr Wissen und ihre Erfahrung bei der Veröffentlichung des ursprünglichen Site Reliability Engineering-Buches mit uns geteilt hat, was uns die Arbeit sehr erleichtert hat. Christopher Guzikowski und Alicia Young von O'Reilly haben großartige Arbeit geleistet, als sie dieses Projekt ins Leben riefen und zur Veröffentlichung führten.

Die Kuratoren möchten sich auch persönlich bei den folgenden Personen bedanken:

Tom Manshreck: An meine Mutter und meinen Vater, weil sie mich dazu gebracht haben, an mich selbst zu glauben - und weil sie mit mir am Küchentisch gearbeitet haben, um meine Hausaufgaben zu machen.

Titus Winters: An Dad, für meinen Weg. An Mom, für meine Stimme. An Victoria, für mein Herz. An Raf, der mir den Rücken freihält. Außerdem an Mr. Snyder, Ranwa, Z, Mike, Zach, Tom (und alle Paynes), mec, Toby, cgd und Melody für Unterricht, Mentoring und Vertrauen.

Hyrum Wright: An Mom und Dad für ihre Ermutigung. Bryan und den Bewohnern von Bakerland für meinen ersten Ausflug in die Softwarebranche. An Dewayne, weil er diese Reise fortgesetzt hat. An Hannah, Jonathan, Charlotte, Spencer und Ben für ihre Liebe und ihr Interesse. An Heather, die immer für mich da war.