Add German translation with all 7 chapters of Section 1 completed

Author: a3ka

content/de/1-1-Approach.md

@@ -0,0 +1,25 @@
+## 1.1. Lernansätze beim Programmieren
+
+Viele denken, dass die wichtigste Fähigkeit eines Programmierers das Schreiben von Code ist. Tatsächlich lesen und korrigieren Programmierer jedoch viel öfter Code. Die Hauptkriterien für qualitativ hochwertigen Code sind Verständlichkeit, Lesbarkeit und Einfachheit. Wie Harold Abelson sagte: „Programme sollten für Menschen geschrieben werden, die sie lesen, nicht für Maschinen, die sie ausführen.“
+
+> Die wichtigsten Fähigkeiten eines Programmierers sind das Lesen und Korrigieren von Code.
+
+Jedes Thema enthält Beispiele für guten und schlechten Code. Diese Beispiele stammen aus der Programmierpraxis und der Projektüberprüfung. Die absichtlich vorbereiteten schlechten Codebeispiele funktionieren zwar, sind aber voller Anti-Patterns und Probleme, die erkannt und behoben werden müssen. Bereits die allererste praktische Aufgabe im Kurs besteht darin, Code zu verbessern und seine Lesbarkeit zu erhöhen. Gibt man Anfängern klassische Aufgaben (z. B. eine Funktion, einen Algorithmus oder eine Klasse nach Vorgabe zu schreiben), setzen sie diese meist nicht optimal um, verteidigen ihren Code aber, weil es das erste ist, was sie geschrieben haben. Ist die Aufgabe jedoch, „fremden schlechten Code zu nehmen, Probleme zu finden und sie zu beheben“, also den Code nicht von Grund auf neu zu schreiben, sondern schrittweise zu verbessern und diese Schritte bewusst nachzuvollziehen, wird ein kritischer Denkprozess angestoßen.
+
+> Schlechten Code zu korrigieren ist eine der effektivsten Lernmethoden.
+
+Einsteiger erhalten Beispiele für Code-Reviews und versuchen anschließend, ihre eigenen Aufgaben analog zu verbessern. Solche Iterationen wiederholen sich häufig und fördern dauerhaft eine kritische Herangehensweise. Ideal ist es, wenn ein Mentor die Verbesserungen beobachtet und gezielt korrigierend eingreifen oder Hinweise geben kann. Der Mentor sollte jedoch keinesfalls die Arbeit für den Anfänger erledigen, sondern ihn vielmehr dazu anregen, wie man über Programmierung nachdenken und nach Lösungen suchen sollte.
+
+> Ein Mentor ist ein unverzichtbarer Begleiter bei der beruflichen Weiterentwicklung.
+
+Anschließend folgen Aufgaben, bei denen der eigene Code geschrieben wird. Wir empfehlen Anfängern ausdrücklich, ihre Lösungen untereinander auszutauschen, um Peer-Reviews durchzuführen. Zuvor sollten jedoch Linters und Formatierer eingesetzt werden, um den Code syntaktisch zu analysieren, Fehler zu finden und problematische Stellen anhand vieler Codevorlagen aufzudecken. Ziel ist es, dass der Kollege den Gedankengang versteht – und keine Zeit mit Syntax oder Formatierung verliert.
+
+> Nutzt freundliches Code-Review, Peer-Review, Linters und Formatierer.
+
+Im nächsten Schritt folgen Übungen zur Entkopplung verschiedener Abstraktionsebenen und anschließend von Modulen. Ziel ist es, dass möglichst wenig Wissen über Datenstrukturen eines Programmteils in einem anderen notwendig ist. Sprachfanatismus wird reduziert, indem von Anfang an mehrere Programmiersprachen parallel erlernt und gegenseitig übersetzt werden. Zwischen `JavaScript` und `Python` ist dies sehr einfach, bei `C` etwas schwieriger – aber auf diese drei Sprachen darf im Kurs keinesfalls verzichtet werden.
+
+> Vermeidet von Anfang an jeglichen Fanatismus: sprachlich, framework-basiert oder paradigmenbezogen.
+
+Framework-Fanatismus wird reduziert, indem Anfängern die Nutzung von Bibliotheken und Frameworks untersagt und der Fokus auf möglichst nativen, abhängigkeitfreien Code gelegt wird. Paradigmenfanatismus wird reduziert, indem versucht wird, prozedurale, funktionale, objektorientierte, reaktive und zustandsbasierte Programmierung zu kombinieren. Wir werden zeigen, wie diese Kombinationen helfen, Muster und Prinzipien aus GoF und SOLID zu vereinfachen.
+
+Ein weiterer wichtiger Bestandteil des Kurses ist das Studium von Anti-Patterns und Refactoring. Zunächst geben wir einen Überblick, anschließend wird mit echten Codebeispielen aus realen Projekten geübt.

content/de/1-2-Examples.md

@@ -0,0 +1,38 @@
+## 1.2. Beispiele in JavaScript, Python und C
+
+Wir werden Codebeispiele in verschiedenen Programmiersprachen schreiben, wobei der Fokus nicht auf den besten, schönsten oder schnellsten Sprachen liegt, sondern auf denen, ohne die man nicht auskommt. Wir nehmen `JavaScript` als die am weitesten verbreitete Sprache, `Python`, weil es Bereiche gibt, in denen man ohne sie nicht auskommt, und `C` als eine Sprache, die Assembler sehr nahe kommt, nach wie vor relevant ist und modernen Sprachen sowohl im Hinblick auf Syntax als auch auf konzeptionelle Ideen stark beeinflusst hat. Alle drei Sprachen sind weit entfernt von der Sprache meiner Träume – aber es ist das, womit wir arbeiten.
+
+Auf den ersten Blick wirkt `Python` sehr verschieden von `JavaScript` und anderen C-ähnlichen Sprachen. Doch dieser Eindruck täuscht: Wir werden zeigen, dass `Python` `JavaScript` sehr ähnlich ist, insbesondere aufgrund der Typensysteme, Datenstrukturen und eingebauten Collections. Die syntaktischen Unterschiede, etwa bei der Blockstruktur über Einrückungen versus geschweifte Klammern `{}`, stechen zwar ins Auge, sind in der Praxis jedoch nicht besonders entscheidend. Zwischen `JavaScript` und `Python` gibt es deutlich mehr Gemeinsamkeiten als zwischen beiden und `C`.
+
+Wir beginnen nicht mit dem Erlernen der Syntax, sondern sofort mit dem Lesen von fehlerhaftem Code und der Fehlersuche. Sehen wir uns die folgenden Codefragmente an. Der erste ist in `JavaScript`:
+
+```js
+let first_num = 2;
+let secord_num = 3;
+let sum = firstNum + secondNum;
+console.log({ sum });
+```
+
+Versuche zu verstehen, was hier geschrieben steht, und wo mögliche Fehler liegen. Vergleiche diesen Code dann mit der entsprechenden Version in `C`:
+
+```c
+#include <stdio.h>
+
+int main() {
+  int first_num = 2;
+  int secord_num = 3;
+  int sum = firstNum + secondNum;
+  printf("%d\n", sum);
+}
+```
+
+Die Fehler sind hier identisch. Sie können auch von jemandem erkannt werden, der keinerlei Programmierkenntnisse hat – sofern er sich mit dem Code beschäftigt. Der nächste Codeausschnitt ist in `Python`, erfüllt die gleiche Aufgabe und enthält die gleichen Fehler:
+
+```py
+first_num = 2;
+secord_num = 3;
+sum = firstNum + secondNum;
+print({ 'sum': sum  });
+```
+
+Im weiteren Verlauf werden wir häufig Codebeispiele aus verschiedenen Sprachen vergleichen, Fehler finden und korrigieren, den Code optimieren und dabei vor allem die Lesbarkeit und Verständlichkeit verbessern.

content/de/1-3-Modeling.md

@@ -0,0 +1,17 @@
+## 1.3. Modellierung: Abstraktionen und Wiederverwendung
+
+Das Herzstück des Programmierens ist die **Modellierung** – also die Erstellung eines Domänenmodells beziehungsweise eines Modells von Objekten und Prozessen im Arbeitsspeicher des Computers. Programmiersprachen liefern dafür Syntax­elemente, mit denen sich **Randbedingungen** für Modelle formulieren lassen. Jede zusätzliche Struktur, die eingeführt wird, um Funktionalität zu erweitern, bringt allerdings weitere Einschränkungen mit sich. Eine höhere **Abstraktionsebene** kann umgekehrt einige dieser Beschränkungen aufheben und die Komplexität des Modells sowie des Codes reduzieren. Wir balancieren daher ständig zwischen dem Ausweiten von Funktionen und deren Zusammenfassung zu einem allgemeineren Modell – und dieser Prozess sollte iterativ immer wieder durchlaufen werden.
+
+Erstaunlich ist, dass Menschen mithilfe von Modellen und Abstraktionen Probleme lösen können, deren Komplexität ihre Gedächtnis- und Denk­kapazität eigentlich übersteigt. Wie **präzise** ein Modell ist, bestimmt seinen Nutzen für Entscheidungen und Steuerungsmaßnahmen. Ein Modell bleibt stets unvollständig und spiegelt nur einen kleinen Ausschnitt der Realität wider – eine oder mehrere ihrer Seiten. Unter klar begrenzten Einsatzbedingungen kann ein Modell jedoch dem realen Objekt einer Domäne praktisch **gleichwertig** sein. Es gibt physikalische, mathematische, Simulations- und viele weitere Modelle; uns interessieren hier vor allem **Informations- und algorithmische Modelle**.
+
+**Abstraktion** ist eine Verallgemeinerung, die viele unterschiedliche, aber ähnliche Fälle zu einem einzigen Modell zusammenführt. Uns beschäftigen Datenabstraktionen und abstrakte Algorithmen. Die einfachsten algorithmischen Abstraktionen sind **Schleifen** (iterative Verallgemeinerung) und **Funktionen** (Prozeduren, Routinen). Eine Schleife beschreibt mit einem einzigen Befehlsblock viele Iterationen, indem sie diesen mehrfach mit unterschiedlichen Variablenwerten ausführt. Funktionen werden ebenfalls vielfach mit unterschiedlichen Argumenten aufgerufen. Typische Datenabstraktionen sind Arrays, assoziative Arrays, Listen, Mengen usw. In Anwendungen fasst man Abstraktionen zu **Schichten** (Abstraktionsebenen) zusammen:
+
+- Niedrig­level-Abstraktionen sind direkt in der Programmiersprache eingebaut (Variablen, Funktionen, Arrays, Events).
+- Höhere Abstraktionen finden sich in Plattformen, Runtimes, Standard- und externen Bibliotheken oder werden aus einfachen Abstraktionen selbst aufgebaut.  
+  Sie heißen „abstrakt“, weil sie **generische** Aufgaben lösen, also nicht domänenspezifisch sind.
+
+Das **Aufbauen von Abstraktions­schichten** ist vielleicht die wichtigste Programmier­aufgabe; davon hängen Flexibilität, Änderungs­aufwand, Integrations­fähigkeit und Lebensdauer einer Software ab. Alle Schichten, die nicht an eine Fachdomäne gebunden sind, nennen wir **Systemschichten**. Darüber legt der Entwickler **Applikationsschichten**, deren Abstraktionsgrad und Universalität abnehmen, je konkreter sie auf Aufgaben zugeschnitten werden.
+
+Abstraktionen verschiedener Ebenen können im selben **Adressraum** (einem Prozess bzw. einer Anwendung) oder in getrennten laufen. Ihre Trennung und Interaktion erreicht man über APIs, Modularität, Komponenten­ansätze – oder schlicht Disziplin, indem man direkte Aufrufe „mitten aus“ einer Komponente „mitten in“ eine andere vermeidet, sofern Sprache oder Plattform das nicht erzwingen. Das gilt selbst innerhalb eines Prozesses, wo theoretisch jede Funktion überall aufrufbar wäre. Ziel ist es, die **Kopplung** zwischen Schichten und Komponenten zu verringern, damit sie austauschbar, wieder­verwendbar und separat entwickelbar bleiben. Zugleich erhöht man die **Kohäsion** innerhalb einer Schicht oder eines Moduls, was Lesbarkeit, Verständlichkeit und Änderbarkeit verbessert. Gelingt es, Abstraktionsebenen sauber zu trennen und Module so klein zu halten, dass ein Entwickler sie vollständig überblicken kann, wird der Entwicklungs­prozess skalierbar, steuerbar und vorhersagbar. Dieses Prinzip liegt auch der **Microservices-Architektur** zugrunde, gilt aber genauso für Module im selben Prozess.
+
+Generell gilt: Je besser ein System **verteilt** ist, desto besser ist es auch zentralisierbar. Aufgaben werden auf der **passenden Ebene** gelöst, wo ausreichende Informationen vorliegen; starre Verbindungen zwischen Modellen unterschiedlicher Abstraktion entfallen. Dadurch kommt es zu keiner unnötigen Eskalation von Problemen nach oben, Entscheidungs­knoten werden nicht „überhitzt“, Daten­verkehr bleibt minimal und die Reaktions­geschwindigkeit steigt.

content/de/1-4-Program.md

@@ -0,0 +1,72 @@
+## 1.4. Algorithmus, Programm, Syntax, Sprache
+
+Es gibt viele Begriffe, die mit der Programmierung verbunden sind. Um Klarheit zu schaffen, sollten wir den Unterschied zwischen ihnen verstehen. Ein informelles Verständnis ist dabei nützlicher als eine rein formale Definition.
+
+> **Algorithmus (Algorithm)**
+
+Ein Algorithmus ist noch kein Programm, sondern eine formal beschriebene Idee zur Lösung einer Aufgabe. Die Beschreibung muss so verfasst sein, dass andere sie verstehen, überprüfen und umsetzen können. Einen Algorithmus kann man nicht ausführen; er muss in Code einer Programmiersprache übertragen werden. Ein Algorithmus enthält die Beschreibung von Operationen und kann auf verschiedene Arten notiert werden: als Formel, als Blockdiagramm oder als Schrittfolge in natürlicher Sprache. Er ist immer auf eine bestimmte Klasse von Aufgaben beschränkt, die er in endlicher Zeit löst. Häufig können wir einen Algorithmus vereinfachen und optimieren, indem wir die Aufgabenklasse einschränken. Wenn wir zum Beispiel von der Addition ganzer und gebrochener Zahlen auf die Addition nur ganzer Zahlen übergehen, können wir eine effizientere Implementierung erreichen. Ebenso können wir die Aufgabenklasse erweitern, indem wir zusätzlich Zeichenketten, die Zahlen darstellen, als Eingabe zulassen; das macht den Algorithmus allgemeiner, aber weniger effizient. Wir müssen entscheiden, was genau wir optimieren. In diesem Fall ist es besser, den Algorithmus aufzuteilen: Einer wandelt alle Zahlen in einen Datentyp um, der andere führt die Addition durch.
+
+> **Beispiel zur Implementierung des GGT-Algorithmus (Euclid)**
+
+In `JavaScript` kann der euklidische Algorithmus zur Bestimmung des größten gemeinsamen Teilers (GGT) so aussehen:
+
+```js
+const gcd = (a, b) => {
+  if (b === 0) return a;
+  return gcd(b, a % b);
+};
+```
+
+Oder noch kürzer:
+
+```js
+const gcd = (a, b) => (b === 0 ? a : gcd(b, a % b));
+```
+
+Dieser einfache Algorithmus ist **rekursiv**: Er ruft sich selbst auf, bis `b` den Wert `0` erreicht. Für Algorithmen können wir die Rechenkomplexität bestimmen und sie nach dem benötigten Zeit- und Speicheraufwand klassifizieren.
+
+> **Programm (Program)**
+
+Im vorherigen Beispiel hatten wir eine Funktion – nur einen Teil eines Programms. Damit sie wirkt, muss man sie aufrufen und Daten übergeben. Programmcode und Daten, die zu einer Einheit zusammengeführt sind, bilden ein **Programm**. Niklaus Wirth verdeutlichte das im Buchtitel: „Algorithmen + Datenstrukturen = Programme“. In den ersten Jahrzehnten der Softwareindustrie zeigte sich, dass Datenstrukturen nicht weniger wichtig sind als Algorithmen. Linus Torvalds meint: „Schlechte Programmierer kümmern sich um Code. Gute Programmierer kümmern sich um Datenstrukturen und ihre Beziehungen.“ Die Wahl der Datenstrukturen bestimmt weitgehend den Algorithmus und dessen Komplexität; über die Daten im Speicher versteht der Programmierer die Aufgabe besser als über die reine Abfolge von Operationen.
+
+Eric Raymond formulierte: „Intelligente Datenstrukturen und dummer Code funktionieren viel besser als andersherum.“
+
+> **Code als gemeinsame Sprache**
+
+Linus Torvalds sagte auch: „Reden ist billig. Zeig mir den Code.“ Programmcode ist eindeutig und ermöglicht es Entwicklern, sich zu verständigen, selbst wenn natürliche Sprachen wegen Mehrdeutigkeit versagen.
+
+> **Ingenieurwesen (Engineering)**
+
+Ingenieurwesen ist die praktische Nutzung vorhandener Ressourcen durch Wissenschaft, Technik, Methoden, Organisation und Wissen. Schon früh war mir wichtig, dass Code Menschen nützt, ihr Leben verbessert und lange lebt. Wettbewerbs- oder Lehrbeispiele erschienen mir künstlich; ich wollte Software schreiben, die täglich genutzt wird: Datenbankanwendungen, Netz- und Kommunikationsprogramme, Steuerungssoftware und Entwicklerwerkzeuge.
+
+Wie in anderen Ingenieurdisziplinen zählt der Nutzen für den Menschen mehr als die Eleganz des Konzepts. Wenn wissenschaftliche Erkenntnisse fehlen, greift man auf Intuition, Erfahrung und Versuch-und-Irrtum zurück. Das führt zu vielen unterschiedlichen und teils widersprüchlichen Lösungen. Niklaus Wirth bemerkte: „Programme werden langsamer, schneller als Hardware schneller wird“, und oft ist Neuschreiben einfacher als Reparieren.
+
+> **Software-Engineering (Software engineering)**
+
+Die Anwendung ingenieurmäßiger Ansätze auf Software umfasst Architektur, Forschung, Entwicklung, Test, Bereitstellung und Wartung. Die Branche nutzt Hilfspraktiken, um Produkte verlässlich genug zu machen, um Gewinn zu bringen, aber nicht so perfekt, dass keine neuen Versionen nötig wären.
+
+„Die meisten Programme ähneln ägyptischen Pyramiden – Millionen Steine übereinander ohne strukturelle Geschlossenheit, bloß durch Kraft und unzählige Arbeiter errichtet.“ – Alan Kay
+
+> **Programmierung (Programming)**
+
+Programmierung ist die Kunst und das Ingenieurhandwerk, Aufgaben mit Rechentechnik zu lösen. Die Hardware beeinflusst stark, welche Paradigmen effizient sind – in Bezug sowohl auf Entwicklungsaufwand als auch auf Laufzeitressourcen.
+
+> **Codierung (Coding)**
+
+Beschränkt man sich auf das Schreiben von Quellcode nach einer fertigen Spezifikation, spricht man von **Codierung**. Entwicklung lässt sich in Entwurf und Codierung trennen; dennoch entsteht oft Code ohne Spezifikation – als Prototyp, MVP oder Pilot. Ihr Nutzen liegt in der Überprüfung von Hypothesen zu Anwendernutzen oder Wirtschaftlichkeit.
+
+Programmierer verwechseln manchmal Prototyp und Produkt: Man erhält entweder einen Prototyp, der wie ein Produkt gepflegt werden muss, oder ein Produkt, das prototypisch zusammengestrickt ist. Die Branche lebt dennoch von Enthusiasten:
+
+„Die meisten guten Programmierer programmieren nicht wegen Geld oder Anerkennung, sondern weil Programmieren Spaß macht.“ – Linus Torvalds
+
+> **Entwickler vs. Programmierer**
+
+Es gibt Befürworter für beide Bezeichnungen. Häufig ist die Selbstbezeichnung `Entwickler` oder `Programmierer` mit einem besonderen beruflichen Stolz verbunden, nicht selten sogar mit einer gewissen Überheblichkeit gegenüber den Anhängern der anderen Bezeichnung. Es wäre sinnvoll, diese Berufe ungefähr so zu unterscheiden, wie sich die Berufe von Fahrer und Kfz-Mechaniker unterscheiden haben. Natürlich kann der Mechaniker behaupten, dass Fahrer keine Ahnung von Fahrzeugen haben, aber im Alltag werden die Menschen von Fahrern transportiert.
+
+Ähnlich ist es in der IT: Der Programmierer sollte sich auf Abstraktionen und die Entwicklung von Softwarekomponenten konzentrieren, während sich der Entwickler auf die Anwendung fertiger Komponenten zur Lösung konkreter Aufgaben spezialisiert. Das erfordert wiederum andere Kenntnisse und Fähigkeiten außerhalb der Programmierung.
+
+> **Komplexität und Einfachheit**
+
+Streben wir nach Programmen, die für Anwender und für uns als Entwickler einfach zu verstehen sind. Wenn wir unter Zeitdruck ineffizienten oder schwer verständlichen Code schreiben müssen, sollten wir eine Überarbeitung, ein Refactoring und eine Optimierung einplanen, bevor wir die Struktur vergessen oder unsere Ideen zur Verbesserung verblassen. Die Ansammlung solcher Probleme im Code nennt man **technische Schuld**. Sie macht Programme nicht nur unflexibler und schwerer verständlich, sondern sorgt auch dafür, dass neue Kollegen beim Lesen des Codes schlechte Praktiken übernehmen. Die Einfachheit in der Lösung komplexer Aufgaben ist das Ziel eines guten Programmierers, das Verbergen dieser Komplexität hinter Abstraktionen ist die Methode eines erfahrenen Ingenieurs.
+
+„Ich habe mir immer gewünscht, mein Computer wäre so einfach zu bedienen wie mein Telefon. Mein Wunsch ist in Erfüllung gegangen: Jetzt weiß ich nicht mehr, wie ich mein Telefon bedienen soll.“ – Bjarne Stroustrup

content/de/1-5-Decomposition.md

@@ -0,0 +1,3 @@
+## 1.5. Декомпозиция и разделение ответственности
+
+No translation