Cargando…
Clean Coder : Verhaltensregeln für professionelle Programmierer /
Erfolgreiche Programmierer haben eines gemeinsam: Die Praxis der Software-Entwicklung ist ihnen eine Herzensangelegenheit. Auch wenn sie unter einem nicht nachlassenden Druck arbeiten, setzen sie sich engagiert ein. Software-Entwicklung ist für sie eine Handwerkskunst. In Clean Coder stellt der leg...
| Clasificación: | Libro Electrónico |
|---|---|
| Autor principal: | |
| Otros Autores: | |
| Formato: | Electrónico eBook |
| Idioma: | Alemán Inglés |
| Publicado: |
Heidelberg :
mitp,
2014.
|
| Edición: | 1. Auflage. |
| Colección: | mitp Professional.
|
| Temas: | |
| Acceso en línea: | Texto completo (Requiere registro previo con correo institucional) |
Tabla de Contenidos:
- Cover; Titel; Impressum; Inhaltsverzeichnis; Vorwort; Einführung; Danksagungen; Über den Autor; Auf dem Titelbild; Kapitel 1: Professionalität; 1.1 Seien Sie vorsichtig, wonach Ihnen verlangt; 1.2 Verantwortung übernehmen; 1.3 Erstens: Richte keinen Schaden an; 1.3.1 Beschädige nicht die Funktion; 1.3.2 Beschädige nicht die Struktur; 1.4 Arbeitsethik; 1.4.1 Sie sollten sich in Ihrem Bereich auskennen; 1.4.2 Lebenslanges Lernen; 1.4.3 Praxis; 1.4.4 Teamwork; 1.4.5 Mentorenarbeit; 1.4.6 Sie sollten sich in Ihrem Arbeitsgebiet auskennen
- 1.4.7 Identifizieren Sie sich mit Ihrem Arbeitgeber bzw. Kunden1.4.8 Bescheidenheit; 1.5 Bibliografie; Kapitel 2: Nein sagen; 2.1 Feindliche Rollen; 2.1.1 Was ist mit dem Warum?; 2.2 Hoher Einsatz; 2.3 Ein »Teamplayer« sein; 2.3.1 Versuchen; 2.3.2 Passive Aggression; 2.4 Die Kosten eines Ja; 2.5 Code unmöglich; Kapitel 3: Ja sagen; 3.1 Verbindliche Sprache; 3.1.1 So erkennt man mangelnde Selbstverpflichtung; 3.1.2 Wie echte Selbstverpflichtung klingt; 3.1.3 Zusammenfassung; 3.2 Lernen, wie man »Ja« sagt; 3.2.1 Die Kehrseite von »Ich versuch's mal«; 3.2.2 Der Disziplin verpflichtet
- 3.3 SchlussfolgerungKapitel 4: Programmieren; 4.1 Bereit sein; 4.1.1 Code um drei Uhr früh; 4.1.2 Sorgencode; 4.2 Der Flow-Zustand; 4.2.1 Musik; 4.2.2 Unterbrechungen; 4.3 Schreibblockaden; 4.3.1 Kreativer Input; 4.4 Debugging; 4.4.1 Zeit zum Debuggen; 4.5 Die eigene Energie einteilen; 4.5.1 Wann man den Stift weglegen muss; 4.5.2 Die Heimfahrt; 4.5.3 Die Dusche; 4.6 In Verzug sein; 4.6.1 Hoffnung; 4.6.2 Sich beeilen; 4.6.3 Überstunden; 4.6.4 Unlautere Ablieferung; 4.6.5 Definieren Sie »fertig und erledigt«; 4.7 Hilfe; 4.7.1 Anderen helfen; 4.7.2 Hilfe annehmen; 4.7.3 Mentorenarbeit
- 4.8 BibliografieKapitel 5: Test Driven Development; 5.1 The Jury is in; 5.2 Die drei Gesetze des TDD; 5.2.1 Die Litanei der Vorteile; 5.2.2 Die professionelle Option; 5.3 Was TDD nicht ist; 5.4 Bibliografie; Kapitel 6: Praktizieren und Üben; 6.1 Etwas Hintergrund übers Üben; 6.1.1 22 Nullen; 6.1.2 Durchlaufzeiten; 6.2 Das Coding Dojo; 6.2.1 Kata; 6.2.2 Waza; 6.2.3 Randori; 6.3 Die eigene Erfahrung ausbauen; 6.3.1 Open Source; 6.3.2 Ethisch handeln; 6.4 Schlussfolgerung; 6.5 Bibliografie; Kapitel 7: Akzeptanztests; 7.1 Anforderungen kommunizieren; 7.1.1 Verfrühte Präzisierung
- 7.2 Akzeptanztests7.2.1 Die »Definition of Done«; 7.2.2 Kommunikation; 7.2.3 Automatisierung; 7.2.4 Zusätzliche Arbeit; 7.2.5 Wer schreibt die Akzeptanztests und wann?; 7.2.6 Die Rolle des Entwicklers; 7.2.7 Verhandlungen über die Tests und passive Aggression; 7.2.8 Akzeptanz- und Unit-Tests; 7.2.9 GUIs und andere Komplikationen; 7.2.10 Andauernde Integration; 7.3 Schlussfolgerung; Kapitel 8: Teststrategien; 8.1 Für die Qualitätssicherung sollte nichts übrig bleiben; 8.1.1 Die Qualitätssicherung gehört zum Team; 8.2 Die Pyramide der Testautomatisierung; 8.2.1 Unit-Tests