- Ich versuche, meine Fähigkeiten im Softwaredesign zu verbessern, und mir wurde empfohlen, bestehende gut gestaltete Codebasen zu studieren
- Ich frage mich, welche öffentlich zugänglichen Codebasen als Goldstandard des Softwaredesigns gelten
1. Empfohlene Codebasen
- Große/maßgebliche Projekte
- Git, Postgres, CPython
- Das "Lieutenants Model" des Linux-Kernels
- UNIX v6, BSDs
- Frameworks/Bibliotheken
- Systeme/Server
- Spiele/Sonderfälle
- Lehr-/Lernmaterialien
- Sonstiges
- Monocypher (Kryptografie-Bibliothek)
- Tcl-Sprachimplementierung
2. Code lesen vs. Dokumentation/Design lernen
- Grenzen von reinem Code
- Eine Codebasis zeigt die Implementierung, verbirgt aber die Designabsicht und Trade-offs
- Wichtigkeit von Designdokumenten
- Entscheidungsaufzeichnungen wie ADRs (Architectural Decision Records), Rust RFCs und Python PEPs sind für das Lernen von Design deutlich hilfreicher
- Schon das Schreiben von Designdokumenten kann selbst ein gutes Training sein
- Buch- und Literaturtipps
3. Praxisorientierte Lerntheorie
- Erfahrung und Versuch-und-Irrtum
- Design lernt man, indem man Probleme wiederholt erlebt und lernt, sie zu vermeiden
- Allein durch das Lesen von Code lernt man nicht genug; man lernt im Prozess des eigenen Schreibens und des Lösens von Fehlschlägen
- Interessenbasiertes Lernen
- Man lernt tiefer, wenn man Projekte baut, die einen wirklich interessieren
- Niedrige Kosten des Scheiterns
- In Software sind die Kosten des Scheiterns geringer als im physischen Engineering, daher ist Lernen durch Ausprobieren und Scheitern besonders effektiv
4. Debatte über den Charakter von Software Engineering
- These vom unreifen Ingenieurwesen
- Wenn fünf Ingenieure zusammenkommen und fünf verschiedene Lösungen hervorbringen, sei das ein Zeichen dafür, dass das Fach als Ingenieurdisziplin noch unreif ist
- These der Experimentierfreundlichkeit
- Software hat wenige Einschränkungen, daher gibt es viele mögliche Lösungen; anders als im physischen Ingenieurwesen ist die richtige Antwort nicht fest vorgegeben
- Grenze zwischen Kunst und Ingenieurwesen
- Design ist auch ein künstlerischer Akt mit ästhetischen Elementen, zugleich aber Ingenieurarbeit, insofern funktionale Anforderungen erfüllt werden müssen
- Software liegt zwischen künstlerischer Flexibilität und ingenieurmäßiger Strenge
5. Alternative Lernmethoden
- Schlechten Code analysieren
- Nicht nur gut gestalteter Code, sondern auch das Verbessern schlechter Codebasen hat einen großen Lerneffekt
- Die eigene Codebasis als Lernmaterial
- Die interne Team-Codebasis wird oft als die lehrreichste Quelle genannt
- Falls der Team-Code jedoch schwach ist, sollte man ihn mit externen Beispielen ergänzen
- Domänenspezifisches Lernen
- Am effektivsten ist es, Codebasen zu lesen, die Problemen ähneln, die man selbst lösen möchte
Zentrale Erkenntnisse
- Gut gestaltete Codebasen helfen, aber Lernen muss mit dem Verständnis der Designabsicht und eigener Versuch-und-Irrtum-Erfahrung einhergehen
- Wichtiger als das reine Codelesen sind Designdokumente und Entscheidungsaufzeichnungen als Lernmaterial
- Repräsentative Qualitätsprojekte (Git, Postgres, CPython, Rust
std usw.) haben hohen Lernwert
- Nicht nur guter Code, sondern auch schlechter Code und der eigene Code sind langfristig oft die praktischere Lernquelle
Zusammenfassung wichtiger Kommentare
Empfehlung repräsentativer Codebasen (CraigJPerry)
- Postfix Mail Server
- Eine sicherheitszentrierte Architektur, die schon vor dem Begriff Microservices eine ähnliche Struktur zeigte
- Während moderne Microservices oft auf verteilte Skalierung in großen Organisationen abzielen, wurde Postfix für Sicherheit und Einfachheit entworfen
- Spring Framework
- Spiegelt eine Kultur wider, die die Anforderungen von Java-Entwicklern im Enterprise-Umfeld tief berücksichtigt
- Man kann daran einen nutzerzentrierten Designansatz lernen
- Git
- Versteht man die Konzepte der Objektdatenbank (Blobs, Trees, Commits) und der Referenzen, ist der Rest eine schrittweise Erweiterung
- Die konsistente Erweiterung von Kernkonzepten wird als gutes Designbeispiel genannt
- Varnish
- Ein Hochleistungs-Reverse-Proxy, dessen Codebasis zugleich so gut strukturiert ist, dass sie als Lernmaterial dienen kann
- Linux-Kernel-Lieutenants-Model
- Keine Codebasis, aber als Modell zur Verwaltung großer Softwareprojekte dennoch sehenswert
- Es geht nicht einfach um "gut designten Code", sondern um Beispiele, in denen Designentscheidungen einen starken Eindruck hinterlassen
Betonung des Lernens an realen Codebasen (crystal_revenge)
- Den größten Lernwert bietet die Codebasis des eigenen Teams
- Im chaotischen Zusammenhang zwischen realen Anforderungen und Implementierung erlebt man zugleich gute und schlechte Entscheidungen
- Der größte realistische Zwang ist Zeitdruck; entscheidend ist, das Gleichgewicht zwischen idealem Design und Realität zu lernen
- Gute Software bedeutet, Nutzeranforderungen zu lösen; durch Wiederholung lernt man Designs, die die Erfolgswahrscheinlichkeit erhöhen
Frühere Diskussionen und Materiallinks (sprobertson)
- Das Thema wurde auf HN bereits mehrfach behandelt
Code vs. Designdokumente (alphazard)
- Eine Codebasis ist nur das Ergebnis der Implementierung, nicht das Design selbst
- Für das Lernen von Design ist das Schreiben von Designdokumenten wirksamer
- Dokumente sollten so klar sein, dass jemand anders sie direkt implementieren könnte
- Wenn man Alternativen aufführt und festhält, warum sie verworfen wurden, ist das ein Beleg für die Designüberlegungen
- Gute Designer berücksichtigen einen breiteren Designraum und wählen daraus einen passenden Punkt
Betonung des Verständnisses des Gesamtsystems (RossBencina)
- Der Prozess, eine gesamte Codebasis zu verstehen, ist äußerst wertvoll
- Man trainiert nicht nur das Lesen gut gestalteten Codes, sondern auch den Blick auf das große Ganze des Systems
- Es hilft, Beziehungen mit Diagrammen wie UML zu visualisieren
- Lernansatz:
- Es ist effektiv, Code von Software zu lesen, die dem ähnelt, was man selbst entwickelt
- Als Einstieg werden Code aus bereits vertrauten Domänen empfohlen (Web-Frameworks, Webserver, Python-Standardbibliothek, VSCode usw.)
- Zu Beginn sollte man mit kleinen Programmen und vertrauten Domänen starten
Maßstäbe für gutes Design (mamcx)
- Gutes Design sind Ziele und Ideen, die Codebasis zeigt nur den Grad ihrer Umsetzung
- Gutes Design sollte nicht nur Schlagworte wie "schnell" oder "sicher" tragen, sondern konkrete Überlegungen und dokumentierte Trade-offs enthalten
- Beispiele dafür lassen sich bei Erlang, frühem Pascal und vielen RDBMS-Designs beobachten
- Rusts
std-Bibliothek ist ein gutes Lernmaterial, weil sie Sicherheit und Konsistenz betont und dies in Code und Dokumentation treu widerspiegelt
Unsichtbare Designentscheidungen (ben30)
- Beim Betrachten gut gestalteter Codebasen ist das Wichtigste oft das, was man nicht sieht
- Entscheidungen des Weglassens – das Ausschließen von Komplexität, das Vermeiden unnötiger Abstraktion, das Ablehnen bestimmter Muster – sind zentral
- Um diesen Kontext zu ergänzen, helfen ADRs (Architectural Decision Records)
- Sie dokumentieren Alternativen, Gründe für ihre Verwerfung und die Begründung der Auswahl und bewahren so den Kontext
- Das hilft sowohl künftigen Maintainer:innen als auch AI-Tools erheblich
- Beim Lernen ist es daher effektiv, nicht nur Code anzuschauen, sondern Projekte mit ADRs, RFCs, PEPs und ähnlichen Designentscheidungsdokumenten
Noch keine Kommentare.