Als PDF, PPTX herunterladen
Hochgeladen vonStephan Partzsch
Social Games und ihr Clean Code
Das Dokument thematisiert die Entwicklung von sozialen Spielen und deren Anforderungen an sauberen Code. Es beschreibt agile Arbeitsweisen, Wartbarkeit und Einheitlichkeit in der Softwareentwicklung sowie Methoden wie Pair Programming und Continuous Integration. Außerdem werden Werkzeuge vorgestellt, die zur Verbesserung der Produktivität und Flexibilität in den Entwicklungsteams beitragen.
Social Games und ihr Clean Code
- 1. Social Games und ihrClean Code
- 2.
- 3. 30.11 Mio. http://www.vgchartz.com/gamedb/?name=Call+of+Duty%3A+Modern+Warfare+3 ||http://www.alextv.de/2011/11/10/call-of-duty-modern-warfare-3-review
- 4. Video Games =spezielle Interessen
- 5.
- 6. Social Games =Spiele für Jeden
- 7.
- 8. 2009 — 20Angestellte
- 9. Heute — 250Mitarbeiter
- 10.
- 11.
- 12.
- 13.
- 14.
- 15.
- 16.
- 17.
- 18.
- 19.
- 20.
- 21.
- 22.
- 23.
- 24.
- 25.
- 26.
- 27.
- 28.
- 29.
- 30.
- 31.
- 32.
- 33.
- 34.
- 35.
- 36. Namensgebung •Sprechende Namen •Keine Abkürzungen •1Begriff pro Konzept Einheitlichkeit
- 37.
- 38.
- 39.
- 40.
- 41.
- 42.
- 43.
- 44.
- 45.
- 46.
- 47.
- 48.
- 49. Formatierung •Einrückungen •Klammernumbrüche •Variablen immer zuerst •ÖffentlicheMethoden zuerst Einheitlichkeit
- 50.
- 51.
- 52.
- 53.
- 54.
- 55. Kommentare •Vermeiden wenn möglich •Nutzungsszenarien ‣Warnungen Einheitlichkeit
- 56. Kommentare •Vermeiden wenn möglich •Nutzungsszenarien ‣Warnungen ‣ Vereinfachte Erklärungen Einheitlichkeit
- 57.
- 58.
- 59.
- 60.
- 61.
- 62.
- 63.
- 64.
- 65.
- 66.
- 67.
- 68.
- 69.
- 70. Methoden •Möglichst klein •1 Abstraktionslevel •1Funktionalität Wartbarkeit
- 71.
- 72.
- 73.
- 74.
- 75.
- 76. Klassen •1 Grund fürVeränderung (SRP) Wartbarkeit
- 77. Klassen •1 Grund fürVeränderung (SRP) •Wenige Instanzvariablen Wartbarkeit
- 78. Klassen •1 Grund fürVeränderung (SRP) •Wenige Instanzvariablen •Hohe Kohäsion Wartbarkeit
- 79.
- 80.
- 81.
- 82.
- 83.
- 84.
- 85.
- 86.
- 87. •Train Wrecks vermeiden •DataTransfer Objects nutzen Datenstrukturen Wartbarkeit
- 88. •Train Wrecks vermeiden •DataTransfer Objects nutzen •Erzeugung und Nutzung von Systemen trennen Datenstrukturen Wartbarkeit
- 89.
- 90.
- 91.
- 92.
- 93.
- 94.
- 95.
- 96. •Vermeiden von Wissensinseln PairProgramming Agilität
- 97. •Vermeiden von Wissensinseln •Integrationneuer Teammitglieder Pair Programming Agilität
- 98. •Vermeiden von Wissensinseln •Integrationneuer Teammitglieder •Kollektive Verantwortung Pair Programming Agilität
- 99.
- 100.
- 101.
- 102. •Stetige Verbesserungen •The BoyScout Rule (Robert C. Martin) Regelmäßiges Refactoring Agilität
- 103.
- 104.
- 105.
- 106.
- 107.
- 108.
- 109.
- 110. •Softwareartefakte früh nutzbar KontinuierlicheIntegration Agilität
- 111. •Softwareartefakte früh nutzbar •Erwartungenüberprüfbar Kontinuierliche Integration Agilität
- 112. •Softwareartefakte früh nutzbar •Erwartungenüberprüfbar •Probleme schnell absehbar Kontinuierliche Integration Agilität
- 113.
- 114.
- 115.
- 116.
- 117. •Pair Programming •Regelmäßiges Refactoring •Unit-Tests •KontinuierlicheIntegration Agilität Agilität
- 118.
- 119.
- 120.
- 121.
- 122.
- 123.
- 124.
- 125. Hohe Produktivität über langenZeitraum http://www.flickr.com/photos/stephenbegin
- 126.
- 127. Clean Code als gemeinsameSprache
- 128.
- 129.