Merge pull request #408 from damoasda/master

Refactoring verwenden

Author: damoasda

src/SUMMARY.md

@@ -63,7 +63,7 @@
 - [Ein E/A-Projekt: Ein Kommandozeilenprogramm erstellen](ch12-00-an-io-project.md)
   - [Kommandozeilenargumente entgegennehmen](ch12-01-accepting-command-line-arguments.md)
   - [Eine Datei einlesen](ch12-02-reading-a-file.md)
-  - [Refaktorierung um die Modularität und Fehlerbehandlung zu verbessern](ch12-03-improving-error-handling-and-modularity.md)
+  - [Refactoring, um die Modularität und Fehlerbehandlung zu verbessern](ch12-03-improving-error-handling-and-modularity.md)
   - [Funktionalität mit testgetriebener Entwicklung hinzufügen](ch12-04-testing-the-librarys-functionality.md)
   - [Mit Umgebungsvariablen arbeiten](ch12-05-working-with-environment-variables.md)
   - [Fehler zur Standardfehlerausgabe umleiten](ch12-06-writing-to-stderr-instead-of-stdout.md)

src/ch05-02-example-structs.md

@@ -70,7 +70,7 @@ und überschaubarer, Breite und Höhe zusammenzufassen. Eine Möglichkeit dazu
 haben wir bereits im Abschnitt [„Der Tupel-Typ“][the-tuple-type] in Kapitel 3
 vorgestellt: Der Einsatz von Tupeln.
 
-### Refaktorierung mit Tupeln
+### Refactoring mit Tupeln
 
 Listing 5-9 zeigt eine weitere Version unseres Programms, die Tupel verwendet.
 
@@ -108,7 +108,7 @@ herauszufinden und im Kopf zu behalten, wenn sie unseren Code verwenden würden.
 Da wir die Bedeutung unserer Daten nicht in unseren Code übertragen haben, ist
 es jetzt einfacher, Fehler zu machen.
 
-### Refaktorierung mit Strukturen
+### Refactoring mit Strukturen
 
 Verwenden wir Strukturen, um durch die Benennung der Daten deren Bedeutung
 anzugeben. Wir können das verwendete Tupel in eine Struktur mit einem Namen

src/ch12-03-improving-error-handling-and-modularity.md

@@ -1,4 +1,4 @@
-## Refaktorierung um die Modularität und Fehlerbehandlung zu verbessern
+## Refactoring, um die Modularität und Fehlerbehandlung zu verbessern
 
 Um unser Programm zu verbessern, werden wir vier Probleme beheben, die mit der
 Struktur des Programms und dem Umgang mit potenziellen Fehlern zu tun haben.
@@ -38,7 +38,7 @@ Wenn sich der gesamte Fehlerbehandlungscode an einer Stelle befindet, wird auch
 sichergestellt, dass wir Meldungen ausgeben, die für unsere Endbenutzer
 aussagekräftig sind.
 
-Lass uns diese vier Probleme angehen, indem wir unser Projekt refaktorieren.
+Lass uns diese vier Probleme mittels Refactoring angehen.
 
 ### Trennen der Zuständigkeiten in Binärprojekten
 
@@ -575,15 +575,14 @@ Großartig! Diese Ausgabe ist viel benutzerfreundlicher.
 
 ### Extrahieren von Logik aus `main`
 
-Da wir mit dem Refaktorieren des Konfigurations-Parsers nun fertig sind, wollen
-wir uns der Logik des Programms zuwenden. Wie wir in [„Trennen der
-Zuständigkeiten in Binärprojekten“][trennen-der-zustaendigkeiten] erklärt
-haben, werden wir eine Funktion namens `run` extrahieren, die die gesamte Logik
-enthält, die sich derzeit in der Funktion `main` befindet und nicht mit dem
-Aufsetzen der Konfiguration oder dem Behandeln von Fehlern zu tun hat. Wenn wir
-fertig sind, wird die Funktion `main` übersichtlich und leicht zu verifizieren
-sein. Zudem werden wir in der Lage sein, Tests für all die andere Logik zu
-schreiben.
+Da wir mit dem Refactoring des Konfigurations-Parsers fertig sind, wollen wir
+uns der Logik des Programms zuwenden. Wie wir in [„Trennen der Zuständigkeiten
+in Binärprojekten“][trennen-der-zustaendigkeiten] erklärt haben, werden wir eine
+Funktion namens `run` extrahieren, die die gesamte Logik enthält, die sich
+derzeit in der Funktion `main` befindet und nicht mit dem Aufsetzen der
+Konfiguration oder dem Behandeln von Fehlern zu tun hat. Wenn wir fertig sind,
+wird die Funktion `main` übersichtlich und leicht zu verifizieren sein. Zudem
+werden wir in der Lage sein, Tests für all die andere Logik zu schreiben.
 
 Listing 12-11 zeigt die extrahierte Funktion `run`. Im Moment machen wir nur
 die kleine, inkrementelle Verbesserung durch Extrahieren der Funktion. Wir sind

src/ch12-04-testing-the-librarys-functionality.md

@@ -14,7 +14,7 @@ Softwareentwicklungstechnik folgt diesen Schritten:
 1. Schreibe einen Test, der fehlschlägt, und führe ihn aus, um sicherzustellen,
    dass er aus dem von dir erwarteten Grund fehlschlägt.
 2. Schreibe oder modifiziere gerade genug Code, um den neuen Test zu bestehen.
-3. Refaktoriere den Code, den du gerade hinzugefügt oder geändert hast, und
+3. Refactoring des Codes, den du gerade hinzugefügt oder geändert hast, und
    stelle sicher, dass die Tests weiterhin bestanden werden.
 4. Wiederhole ab Schritt 1!
 
@@ -330,13 +330,13 @@ test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; fini
 
 Unser Test war erfolgreich, also wissen wir, dass der Code funktioniert!
 
-An diesem Punkt könnten wir Möglichkeiten für eine Refaktorierung der
-Implementierung der Suchfunktion in Betracht ziehen, während die Tests
-weiterlaufen, um die gleiche Funktionalität zu erhalten. Der Code in der
+An diesem Punkt könnten wir Möglichkeiten zum Refactoring der
+Suchfunktion-Implementierung in Betracht ziehen, während die Tests weiter
+funktionieren und die gleiche Funktionalität sicherstellen. Der Code in der
 Suchfunktion ist nicht allzu schlecht, aber er macht sich einige nützliche
 Funktionen der Iteratoren nicht zunutze. Wir kehren zu diesem Beispiel in
-[Kapitel 13][ch13-iterators] zurück, wo wir Iteratoren im Detail untersuchen
-und uns ansehen, wie man sie verbessern kann.
+[Kapitel 13][ch13-iterators] zurück, wo wir Iteratoren im Detail untersuchen und
+uns ansehen, wie man sie verbessern kann.
 
 Jetzt sollte das gesamte Programm funktionieren! Lass es uns ausprobieren,
 zunächst mit einem Wort, das genau eine Zeile aus dem Emily-Dickinson-Gedicht

src/ch12-06-writing-to-stderr-instead-of-stdout.md

@@ -52,14 +52,13 @@ landen. Das werden wir ändern.
 
 ### Fehler auf der Standardfehlerausgabe ausgeben
 
-Wir werden den Code in Listing 12-24 verwenden, um zu ändern, wie
-Fehlermeldungen ausgegeben werden. Aufgrund der Refaktorierung, die wir früher
-in diesem Kapitel vorgenommen haben, befindet sich der gesamte Code, der
-Fehlermeldungen ausgibt, in einer einzigen Funktion, nämlich der Funktion
-`main`. Die Standardbibliothek stellt das Makro `eprintln!` zur Verfügung, das
-in die Standardfehlerausgabe schreibt. Lass uns also die beiden Stellen, an
-denen wir `println!` aufgerufen haben, um Fehler auszugeben, ändern und
-stattdessen `eprintln!` verwenden.
+Wir werden den Code in Listing 12-24 verwenden und abändern, wie Fehlermeldungen
+ausgegeben werden. Aufgrund unseres Refactorings früher in diesem Kapitel
+befindet sich der gesamte Code, der Fehlermeldungen ausgibt, in einer einzigen
+Funktion, nämlich der Funktion `main`. Die Standardbibliothek stellt das Makro
+`eprintln!` zur Verfügung, das in die Standardfehlerausgabe schreibt. Lass uns
+also die beiden Stellen, an denen wir `println!` aufgerufen haben, um Fehler
+auszugeben, ändern und stattdessen `eprintln!` verwenden.
 
 <span class="filename">Dateiname: src/main.rs</span>
 

src/ch16-00-concurrency.md

@@ -9,24 +9,23 @@ werden immer wichtiger, da immer mehr Computer die Vorteile mehrerer
 Prozessoren nutzen. In der Vergangenheit war die Programmierung in diesen
 Bereichen schwierig und fehleranfällig: Rust hofft, das ändern zu können.
 
-Ursprünglich dachte das Rust-Team, dass das Gewährleisten von
-Speichersicherheit (memory safety) und das Verhindern von
-Nebenläufigkeitsproblemen (concurrency problems) zwei separate
-Herausforderungen seien, die mit unterschiedlichen Methoden gelöst werden
-müssten. Im Laufe der Zeit entdeckte das Team, dass Eigentümerschaft
-(ownership) und Typsysteme ein leistungsstarkes Instrumentarium zur Bewältigung
-von Speichersicherheits- _und_ Nebenläufigkeitsproblemen sind! Durch das Nutzen
-der Eigentümerschaft und Typprüfung werden viele Nebenläufigkeitsfehler zu
-Kompilierzeitfehlern in Rust anstatt Laufzeitfehlern. Anstatt dass du viel Zeit
-damit verbringen musst, die genauen Umstände zu reproduzieren, unter denen ein
-Laufzeit-Nebenläufigkeitsfehler auftritt, wird der fehlerhafte Code nicht
-kompilieren und einen Fehler anzeigen, der das Problem erklärt. Dadurch kannst
-du deinen Code reparieren, während du daran arbeitest, und nicht möglicherweise
-erst, nachdem er in Produktion ausgeliefert wurde. Wir haben diesem Aspekt von
-Rust den Spitznamen _furchtlose Nebenläufigkeit_ (fearless concurrency)
-gegeben. Die furchtlose Nebenläufigkeit ermöglicht es dir, Code zu schreiben,
-der frei von subtilen Fehlern und leicht zu refaktorieren ist, ohne neue
-Fehler zu erzeugen.
+Ursprünglich dachte das Rust-Team, dass das Gewährleisten von Speichersicherheit
+(memory safety) und das Verhindern von Nebenläufigkeitsproblemen (concurrency
+problems) zwei separate Herausforderungen seien, die mit unterschiedlichen
+Methoden gelöst werden müssten. Im Laufe der Zeit entdeckte das Team, dass
+Eigentümerschaft (ownership) und Typsysteme ein leistungsstarkes Instrumentarium
+zur Bewältigung von Speichersicherheits- _und_ Nebenläufigkeitsproblemen sind!
+Durch das Nutzen der Eigentümerschaft und Typprüfung werden viele
+Nebenläufigkeitsfehler zu Kompilierzeitfehlern in Rust anstatt Laufzeitfehlern.
+Anstatt dass du viel Zeit damit verbringen musst, die genauen Umstände zu
+reproduzieren, unter denen ein Laufzeit-Nebenläufigkeitsfehler auftritt, wird
+der fehlerhafte Code nicht kompilieren und einen Fehler anzeigen, der das
+Problem erklärt. Dadurch kannst du deinen Code reparieren, während du daran
+arbeitest, und nicht möglicherweise erst, nachdem er in Produktion ausgeliefert
+wurde. Wir haben diesem Aspekt von Rust den Spitznamen _furchtlose
+Nebenläufigkeit_ (fearless concurrency) gegeben. Die furchtlose Nebenläufigkeit
+ermöglicht es dir, Code zu schreiben, der frei von subtilen Fehlern und mittels
+Refactoring leicht zu ändern ist, ohne neue Fehler zu erzeugen.
 
 > Anmerkung: Der Einfachheit halber werden wir viele der Probleme als
 > _nebenläufig_ bezeichnen, anstatt präziser zu sein, indem wir _nebenläufig