Programmierprinzipien, die dir niemand beigebracht hat

DeutschالعربيةEnglishEspañolFrançaisहिन्दीBahasa Indonesia日本語한국어PortuguêsРусский中文
TThe Coding Koala
Computing/SoftwareManagement

Transcript

00:00:00Weißt du, warum manche Leute sich als Entwickler nie weiterzuentwickeln scheinen, obwohl sie Jahre
00:00:04in diesem Bereich verbringen? Es gibt verschiedene Faktoren. Einer dieser Gründe ist das fehlende Verständnis
00:00:09für die grundlegenden Prinzipien der Programmierung. Das sind nicht nur theoretische Konzepte, die man einmal lernt
00:00:14und wieder vergisst. Das sind die echten Grundlagen, die dich als Entwickler wirklich schneller wachsen lassen.
00:00:19Fangen wir mit dem ersten Prinzip an: der Pfadfinder-Regel. Dieses Prinzip stammt von den Pfadfindern in Amerika.
00:00:25Die Grundregel ist einfach: Hinterlasse den Zeltplatz sauberer, als du ihn vorgefunden hast.
00:00:31Ich weiß nicht, wie viele von euch "Uncle Bob" kennen, aber er hat dieses Konzept
00:00:36in der Programmier-Community populär gemacht: die Praxis, Code etwas sauberer zu hinterlassen, als man ihn vorgefunden hat.
00:00:41Wenn man Änderungen an einer bestehenden Codebasis vornimmt, verschlechtert sich die Codequalität oft, was
00:00:47die technische Schuld erhöhen kann. Technische Schulden lassen sich durch kontinuierliche Verbesserung verringern,
00:00:52egal wie klein sie ist. Angenommen, du hast die Aufgabe, eine Änderung am
00:00:57Wert in dieser Funktion vorzunehmen. Du hast es getan, aber du siehst, dass die Variablennamen nicht verständlich
00:01:03genug sind. Wie die meisten Entwickler könntest du es einfach ignorieren und deine zugewiesene Arbeit committen.
00:01:08Aber wenn du diesem Prinzip folgst, würdest du auch den Variablennamen in etwas
00:01:12Verständlicheres ändern. Das ist nur ein einfaches Beispiel. Nicht nur bei Variablennamen, sondern wenn du irgendetwas siehst,
00:01:18das verbessert werden kann: Tu es einfach. Diese kleine Geste ist für die Codebasis sehr wertvoll.
00:01:24Zweites Prinzip: Vermeide vorzeitige Optimierung. Das bedeutet: Versuche nicht, deinen
00:01:30Code schneller zu machen, bevor er tatsächlich schnell sein muss. Erst funktionsfähig machen, dann bei Bedarf optimieren.
00:01:36Es gibt das berühmte Zitat von Donald Knuth: "Vorzeitige Optimierung ist die Wurzel allen Übels."
00:01:42Das stimmt, weil Programmierer oft die meiste Zeit damit verschwenden, sich über die Geschwindigkeit
00:01:47unkritischer Programmteile Gedanken zu machen. Das liegt daran, dass das Konzept des
00:01:51"Alles-Optimierens" so verbreitet ist. Dieses Prinzip ist nicht gegen Optimierung deines Codes.
00:01:57Es geht darum zu verstehen, was optimiert werden muss und vor allem, wann man optimiert. Ich denke,
00:02:03das ist eine Schwäche der meisten Entwickler, denn ich habe Leute Microservices nutzen sehen, obwohl sie
00:02:08100 Nutzer haben, oder Caching für etwas einbauen, das gar nicht erforderlich ist. Drittes Prinzip:
00:02:14Schreibe Code für den Maintainer. Das heißt schlicht: Wenn du Code schreibst, solltest du es so tun,
00:02:19dass die zukünftigen Entwickler, die deinen Code warten, keine Probleme bei der Verwaltung und
00:02:23dem Verständnis haben. Denn der Code, den du heute schreibst, wird von anderen Entwicklern oder
00:02:29von dir selbst gewartet. Wenn du dich nur darauf konzentrierst, dass es funktioniert, und nicht auf Klarheit, wirst du in Zukunft,
00:02:35wenn du zum Code zurückkehrst, Schwierigkeiten haben zu verstehen, was da vor sich geht. Schau dir
00:02:39dieses Beispiel an. Beide funktionieren und erfüllen genau den gleichen Zweck. Aber welches würdest du lieber
00:02:45in deiner Codebasis sehen? Das Fazit ist: Wenn du Code schreibst oder von einer KI generieren lässt,
00:02:50stelle immer sicher, dass er leicht verständlich und wartbar ist, bevor du deine Arbeit committest.
00:02:55Das vierte Prinzip heißt YAGNI, die Kurzform für "You Ain't Gonna Need It" (Du wirst es nicht brauchen).
00:03:01Dieses Prinzip besagt einfach, dass du nichts bauen solltest, was du nicht tatsächlich brauchst, nur weil
00:03:06du es vielleicht in Zukunft brauchen könntest. Denn die meisten Entwickler haben die Angewohnheit, vorherzusagen,
00:03:10was sie in Zukunft benötigen könnten. Aber meistens wird es nie gebraucht und sorgt nur für zusätzliche
00:03:16Komplexität im Projekt. Denk immer daran: Wenn du an etwas arbeitest, das du eventuell in
00:03:21Zukunft brauchen könntest, verschwendest du Zeit für Dinge, die du aktuell brauchst. Fünftes Prinzip: Mach das
00:03:27Einfachste, das funktionieren könnte. Das bedeutet, wenn du vor einem Problem stehst, wähle immer die
00:03:32einfachste Lösung, die tatsächlich funktioniert. Überdenke es nicht. Überkonstruiere es nicht. Frag dich einfach:
00:03:38Was ist das Einfachste, das das jetzt lösen könnte? Diese Idee stammt aus dem Extreme
00:03:43Programming, das uns lehrt, erst etwas Einfaches zu bauen und es dann zu etwas
00:03:48Besserem zu refactoren. Die meisten Entwickler realisieren das nicht, versuchen aber oft, von
00:03:53Anfang an die perfekte Lösung zu bauen, was ihre Lösung letztendlich unnötig verkompliziert.
00:03:59Mit diesem Prinzip hast du schneller einen funktionierenden Code, und selbst wenn du ihn später ändern musst,
00:04:04ist das meist einfacher, als ein komplexes, falsches Design zu reparieren. Und glaub mir, als Entwickler ist es
00:04:10sehr wichtig zu erkennen, wann man etwas überkonstruiert. Das waren die fünf Programmierprinzipien,
00:04:14die du sofort umsetzen solltest. Abgesehen davon gibt es noch andere Prinzipien, die ich
00:04:19in diesem Video nicht behandelt habe. Wenn das hilfreich war, lass es mich in den Kommentaren wissen, dann mache ich einen zweiten Teil.
00:04:24Fürs Erste reicht das. Zeigt etwas Liebe und wir sehen uns im nächsten Video.

Key Takeaway

Durch die konsequente Anwendung von Prinzipien wie YAGNI, der Pfadfinder-Regel und der Priorisierung einfacher, wartbarer Lösungen steigt die Qualität und Entwicklungsgeschwindigkeit in Softwareprojekten signifikant.

Highlights

  • Die Pfadfinder-Regel verlangt, Code bei jeder Änderung sauberer zu hinterlassen, als er vorgefunden wurde, um technische Schulden abzubauen.

  • Donald Knuth bezeichnet vorzeitige Optimierung als Wurzel allen Übels, da sie unnötige Komplexität in unkritischen Programmteilen erzeugt.

  • Lesbarkeit und Wartbarkeit haben Vorrang vor Perfektion, da zukünftige Entwickler oder man selbst den Code verstehen müssen.

  • Das YAGNI-Prinzip verbietet die Implementierung von Funktionen, die zwar zukünftig nützlich erscheinen, aktuell jedoch nicht benötigt werden.

  • Die einfachste funktionierende Lösung ist der Standardansatz, um Überkonstruktion zu vermeiden und die Entwicklungsgeschwindigkeit zu erhöhen.

Timeline

Pfadfinder-Regel und technische Schulden

  • Jede Änderung am Code bietet eine Gelegenheit zur schrittweisen Verbesserung der Codebasis.
  • Die Anwendung der Pfadfinder-Regel reduziert langfristig technische Schulden.
  • Kleine Anpassungen, wie etwa die Klarheit von Variablennamen, erhöhen den Wert des Codes erheblich.

Die Pfadfinder-Regel fordert, Zeltplätze sauberer zu hinterlassen, als man sie vorgefunden hat. In der Softwareentwicklung bedeutet dies, bei jeder Bearbeitung kleinerer Programmteile die Codequalität kontinuierlich zu steigern. Anstatt nur funktionale Anforderungen umzusetzen und Unklarheiten im Code zu ignorieren, verbessert man diese aktiv.

Vermeidung vorzeitiger Optimierung

  • Code sollte erst nach dem Erreichen der Funktionsfähigkeit bei tatsächlichem Bedarf optimiert werden.
  • Vorzeitige Optimierung führt oft zu verschwendeter Zeit für unkritische Programmteile.
  • Komplexe Architekturen, wie Microservices oder Caching, sind für Projekte mit wenigen Nutzern meist unnötig.

Vorzeitige Optimierung gilt als ineffizient, da Entwickler oft Zeit in die Geschwindigkeitssteigerung investieren, ohne den tatsächlichen Bedarf zu prüfen. Erst wenn Code funktionsfähig ist, rechtfertigt ein nachgewiesener Bedarf eine Optimierung. Das übermäßige Implementieren komplexer Konzepte führt häufig zu einer unnötigen Steigerung der Projektkomplexität.

Wartbarkeit und YAGNI

  • Code ist primär für den Maintainer zu schreiben, nicht nur für die Maschine.
  • Das YAGNI-Prinzip verhindert die Verschwendung von Zeit für Funktionen, die möglicherweise nie benötigt werden.
  • Die Vorhersage zukünftiger Anforderungen erhöht oft nur die Komplexität und behindert die aktuelle Arbeit.

Die Wartbarkeit steht bei der Codeerstellung im Mittelpunkt, da der Code zukünftig verstanden und gepflegt werden muss. Zusätzlich minimiert das YAGNI-Prinzip (You Ain't Gonna Need It) die Komplexität, indem es untersagt, Funktionalitäten präventiv für eine ungewisse Zukunft zu entwickeln.

Einfachheit vor Überkonstruktion

  • Bei Problemen ist immer die einfachste funktionierende Lösung zu wählen.
  • Extreme Programming befürwortet den Ansatz, erst einfach zu bauen und später bei Bedarf zu refactoren.
  • Die perfekte Lösung von Anfang an führt oft zu unnötig komplizierten Designs.

Die Wahl der einfachsten Lösung beschleunigt die Bereitstellung von funktionierendem Code. Überkonstruktion verkompliziert Systeme unnötig, während einfache Lösungen später leichter angepasst oder refactored werden können, falls sich Anforderungen ändern sollten.

Community Posts

No posts yet. Be the first to write about this video!

Write about this video