Effizientes Programmieren
Heutige Themen:
1) Agile Softwareentwicklung
2) Refactorings
Michaela Rindt
([email protected])
Effizientes Programmieren
Wie kann ein Entwicklungsteam effizient arbeiten?
●
m.a.W: flexibel und agil auf Änderungswünsche /
Probleme reagieren,
●
die Software-Qualität kontinuierlich steigern und
●
Wartungskosten und Einarbeitungszeiten reduzieren
Effizientes Programmieren
Welche Programmiertechniken sind effizient?
●
hinsichtlich Wartung und Pflege,
●
Geschwindigkeit beim Programmieren,
●
Kollaboration und
●
Aufdeckung und Vermeidung von Programmierfehlern
1.) Agile Softwareentwicklung
Bild-Quelle: http://imgkid.com/growing-plant-png.shtml
Agile Softwareentwicklung
agile = (engl.) beweglich / flexibel
●
●
●
Vorgehensmodell für Projektentwicklung
Philosophie (mit Werten, Prinzipien und Methoden)
●
●
●
Trend: ~ seit Jahrtausendwende
jungen, dynamischen Startup-Unternehmen
Wird zunehmend eingesetzt ingroßen, erfolgreichen Unternehmen
(u.a. Microsoft, Google, Symantec)
Bild-Quelle: http://imgkid.com/growing-plant-png.shtml
Agile Softwareentwicklung
●
Gegenbewegung zum klassischen
Vorgehensmodell in der Softwareentwicklung
(traditionell: V-Modell bzw. Wasserfallmodell)
●
Kennzeichnend:
(1) geringer bürokratischer Aufwand
(2) starker Fokus auf Ziele, technische und v.a. soziale Aspekte
Bild-Quelle: http://imgkid.com/growing-plant-png.shtml
Verschiedene Agile Vorgehensmodelle
●
Scrum
●
Kanban
●
eXtreme-Programming (XP)
●
Crystal
●
Feature Driven Development
●
Adaptive Software Development
●
u.v.m.
Der gemeinsame Nenner ist das 'Agile Manifest':
st
e
f
i
n
a
M
e
Das Agil
1) Menschen und Interaktionen sind wichtiger
als Prozesse und Werkzeuge.
2) Funktionierende Software ist wichtiger
als umfassende Dokumentation.
3) Zusammenarbeit mit dem Kunden ist wichtiger
als die ursprünglich formulierten Leistungsbeschreibungen.
4) Eingehen auf Veränderungen ist wichtiger
als Festhalten an einem Plan.
Die A
gilen
Prinz
ipien
1) Zufriedenstellung des Kunden durch frühe
und kontinuierliche Auslieferung von wertvoller Software
2) Agile Prozesse nutzen Veränderungen
(selbst spät in der Entwicklung) zum Wettbewerbsvorteil
des Kunden.
3) Lieferung von funktionierender Software in regelmäßigen,
bevorzugt kurzen Zeitspannen (wenige Wochen oder
Monate)
4) Nahezu tägliche Zusammenarbeit von Fachexperten
und Entwicklern während des Projektes
(Bsp.: Gemeinsamer Code-Besitz (Collective Code
Ownership)*)
*d.h. Code 'gehört' dem Team;
5) Bereitstellung des Umfeldes und
der Unterstützung, welche von motivierten Individuen
für die Aufgabenerfüllung benötigt wird**
6) Informationsübertragung nach Möglichkeit
im Gespräch von Angesicht zu Angesicht
...
Quelle: Wikipedia zu Agile Softwareetwicklung
(Stand 23.03.2015)
...
7) Als wichtigstes Fortschrittsmaß gilt
die Funktionsfähigkeit der Software
8) Einhalten eines gleichmäßigen
Arbeitstempos von Auftraggebern,
Entwicklern und Benutzern für
eine nachhaltige Entwicklung *
Die A
gilen
Prinz
ipien
*d.h. keine Überstunden!
9) Ständiges Augenmerk auf technische
Exzellenz und gutes Design
10) Einfachheit ist essenziell (KISS-Prinzip)**
**Keep-it-Short-and-Simple
11) Selbstorganisation der Teams bei
Planung und Umsetzung
12) Selbstreflexion der Teams über
das eigene Verhalten zur Anpassung
im Hinblick auf Effizienzsteigerung
Quelle: Wikipedia zu Agile Softwareetwicklung
(Stand 23.03.2015)
ilen
g
A
Die
n
e
d
o
h
Met
●
Paar-Programmierung
●
Test-Driven Development
●
Kontinuierliches Refactoring
Quelle:http://www.agilenutshell.com/test_driven_development
Quelle: http://www.itagile.de/wissen/methoden/scrum/
ilen
g
A
Die
●
n
e
d
o
h
Met
Story-Point Schätzungen
Aufgaben/Features werden zu 'stories'.
Aufwandsschätzung der Stories relativ zueinander
Punkte (pts=points) in Fibonacci-Folge.
Quelle:
http://www.agilenutshell.com/episodes/
3-estimation
ilen
g
A
Die
●
n
e
d
o
h
Met
Retrospektiven
Was ist in letzter Zeit geschehen?
Was war gut?
Was schlecht?
Welche Daten zur Qualität und
Produktivität liegen vor?
Quelle: https://hakanforss.wordpress.com/2012/04/25/agile-lego-toyota-kata-an-alternative-to-retrospectives/
comm
it
mi t
m
o
c
comm
it
baseline
nM
e
l
i
g
Die A
n
e
d
o
h
et
●
Continuous Integration
–
Versions Kontrolle durch Repository
–
Tagliche baseline commits
–
Automatisierte, schnelle Build-Prozesse
–
automatisierte Self-Tests
–
automatisiertes Deployment
–
Breaking Builds sofort für alle sichtbar,
automated build
and self-test
O.K.
Error
zur schnellen Fehlerbeseitigung
–
u.v.m.
Breaking-Build Bildquelle:
http://www.qubiz.com/continuous-integration-future-development/
ilen
g
A
Die
n
e
d
o
h
Met
Code-Reviews
–
Wechselnde Review-Partner
–
Wissensverteilung im gesamten Team
–
Gegenseitiger Respekt
Quelle: http://www.osnews.com/story/19266/WTFs_m
Offensichtliche logische Fehler?
Anforderungen vollständig implementiert?
Reichen die automatisierten Tests oder werden neue benögtigt für diesen Code?
Konform zu Stil-Konventionen?
Im Vergleich: alte vs. moderne Entwicklungs-Zyklen
Traditionelle Entwicklungs-Zyklen
Lange, autarke Phasen
(z.T. wiederkehrende
Iterationen)
Bild-Quelle: The Art of Agile Development
Im Vergleich: alte vs. moderne Entwicklungs-Zyklen
Agile Entwicklungs-Zyklen (hier: eXtreme Programming)
kurze, regelmäßig
wiederkehrende Iterationen
mit parallel laufenden
Prozessen
one „story“ (=feature)
per week
Bild-Quelle: The Art of Agile Development
Warum all der Wandel?
●
●
Traditionelles Verständnis einer erfolgreiche Software Lieferung
–
falls rechtzeitig,
–
im Budget und
–
entsprechend der Anforderung
Allerdings: steht häufig im Widerspruch zur Realität
–
unvollständiger Software → Hohe Umsätze
–
Konformität zu obigen Kriterien → ausbleibender Erfolg
Warum all der Wandel?
Tatsächlich ist Erfolg gegeben durch:
Quelle:
The Art of Agile Developement.
Denn:
● Ohne Persönlicher Erfolg
→ fehlt langzeitliche Motivation aller Angestellten
● Ohne technischen Erfolg
→ schlechte Wartbarkeit und Fehleranfälligkeit des Source-Codes
● Ohne Unternehmenserfolg
→ Angestellte fürchten um ihren Job
SCRUM
- ein agiles Vorgehensmodell -
SCRUM
●
●
●
agiles Vorgehensmodell für Projekt- u. Produktmanagement
Besonderheit: Scrum akzeptiert, dass der Entwicklungsprozess nicht
vorherzusehen ist
Klare Definition von Rollen und zeitlichen Abläufen:
SCRUM
Quelle: http://www.it-agile.de/wissen/methoden/scrum/
SCRUM
Transparenz des Fortschritts für alle:
„Burndown Chart of Agilo for Scrum“ von agile42 GmbH. Original uploader was Teckmx5 at de.wikipedia - Transferred from de.wikipedia; transferred to Commons using CommonsHelper.(Original text : agile42 GmbH).
Lizenziert unter Apache License 2.0 über Wikimedia Commons - http://commons.wikimedia.org/wiki/File:Burndown_Chart_of_Agilo_for_Scrum.png#/media/File:Burndown_Chart_of_Agilo_for_Scrum.png
SCRUM
Definition of 'Done' (DoD):
●
gemeinsames Verständnis eines Teams, unter welchen Bedingungen eine
Arbeit als fertig bezeichnet wurde. Beinhaltet
●
●
●
●
●
Qualitätskriterien
Einschränkungen
Erfüllung der Anforderungen
Vorhandensein von Kommentaren, Unit Tests, etc.
Definition wird zu Beginn eines Sprints festgelegt
SCRUM
Weitere Techniken (nicht Teil des SCRUM-Kerns)
●
●
User-Stories
wer
ry 12
User-Sto
Taskboard
was
e
de
Webseit
Als Kun h eine Intranet- n Firmennews.
ic
llung vo
te
möchte
s
r
a
D
nen
zur inter
warum
user-stories
To-Do
WIP
Done
SCRUM
Weitere Techniken (nicht Teil des SCRUM-Kerns)
●
Planungspoker
●
Impediment Backlog
Quelle:
http://www.personalisedplayingcards.com/playing
cards/planning-poker-cards.html
Neue Aufgaben
u. Hindernisse
Backlog
Schu
tz
Schild -
SCRUM Master
Working Team
Kanban
- ein agiles Vorgehensmodell -
Kanban
●
= (jap.) Signalkarte
●
agiles Vorgehensmodell zur Produktionsprozesssteuerung
(mit SCRUM kombinierbar)
●
Entspringt dem Toyota-Produktionssystem
●
Zweck: Begrenzung von parallel durchgeführter Arbeiten
→ dadurch veringerte Durchlaufzeiten von Aufgaben
→ Aufdeckung von Engpässen
Kanban
●
Besonderheiten:
–
Kanban-Board – zur Arbeitsfluss-Visualsierung
–
Kaizen - Kultur der kontinuierlichen Verbesserung:
● Standup Meetings
● Operations Review / Retrospektive
● Tracking (des Fortschritts) mit div. Diagrammen
Limitierte Anzahl
paralleler Arbeiten
pro Station
Kanban-Board
Pull-System – Reduzierte Parallelität von WIPs - Engpasserkennung
pulled-in tasks
Durchlauf
http://www.it-agile.de/wissen/methoden/kanban/
eXtreme Programming (XP)
- ein agiles Vorgehensmodell -
eXtreme Programming (XP)
●
Entspringt Entwicklungsprozessen von Daimler Chrysler
●
Agiles Vorgehensmodell bzw. Philosophie
●
Kann mit SCRUM kombiniert werden
●
Werte
„XP-Werte“ von Michael Hüttermann - Eigenes Werk. Lizenziert unter Gemeinfrei über Wikimedia Commons http://commons.wikimedia.org/wiki/File:XP-Werte.png#/media/File:XP-Werte.png
eXtreme Programming (XP)
●
Prinzipien
–
Rapid feedback
–
Assume simplicity
–
Incremental change
–
Embracing Change
–
Quality Work
eXtreme Programming (XP)
–
Teach Learning
–
Small Initial Investment
–
Play to win
–
Concrete Experiments
–
Open, honest Communication
eXtreme Programming (XP)
–
Work with people's insticts, not against them
–
Accepted Responsibility
–
Local Adaption
–
Travel light
–
Honest Measurement
Details nachlesbar auf:
http://www.scrum-kompakt.de/grundlagen-des-projektmanagements/extreme-programming-xp/
eXtreme Programming (XP)
●
Praktiken:
On-Site Customer: Kunde muss Ansprechpartner bereitstellen, der
in der Planungsphase und bei Fragen miteinbezogen wird.
Sonstige Praktiken:
„Xp-kreis“ von Michael Hüttermann - Eigenes Werk. Lizenziert unter Gemeinfrei über Wikimedia Commons http://commons.wikimedia.org/wiki/File:Xp-kreis.png#/media/File:Xp-kreis.png
2.) Refactoring
- Entwicklungsmethode -
Bild-Quelle: http://www.goldbachinteractive.com/aktuell/kurzbeitraege/next-step-of-evolution
Refactoring
●
… ist wesentlicher Bestandteil von Agiler Entwicklung (aber auch unabhängig davon)
●
... ist das Verbessern von vorhandenem Quellcode
●
... verändert nicht das äußere Verhalten eines Programmes, sondern nur seine
interne Struktur.
Bild-Quelle: http://www.goldbachinteractive.com/aktuell/kurzbeitraege/next-step-of-evolution
Refactoring
Positive Effekte:
–
Lesbarkeit und Nachvollziebarkeit des Codes wird verbessert
–
Leicht erweiterbarer Code, d.h. zukünftige Änderungen müssen nicht
umständliche 'gehackt' werden
–
Beseitigt bad smells und minimiert damit Wahrscheinlichkeiten für die
Entstehung neuer Bugs
–
Integrität und Qualität des Programmes wird langzeitlich gesichert
–
Aufwand für Ergänzungen und die Einarbeit neuer Mitarbeiter wird minimiert
Refactoring
Typische Änderungen im Refactoring-Prozess:
–
Reduktion oder auch Ergänzung von Kommentaren / Dokumentation
–
Variablen- und Methodennamen Anpassung entsprechend ihrer Funktion
–
Zusammenlegung oder auch Aufteilung oder Auslagern von Code-Fragmenten
–
Entfernen von Redundanzen (z.B. überflüssige Imports / unnötige Methoden
oder Variablen)
–
Strukturelle Verschiebungen von Code-Fragmenten
–
Testbarkeit von Funktionen ermöglichen
Beispiele für Refactorings
Alle folgenden Beispiele (u.v.m.) stammen
von Martin Fowler. Sie sind in diesem Buch
nachzuschlagen.
oder unter: http://refactoring.com/catalog/
Bedingungen mit
Polymorphismus ersetzen
Quelle: http://refactoring.com/catalog/replaceConditionalWithPolymorphism.html
Methoden nach oben ziehen
Quelle: http://refactoring.com/catalog/pullUpMethod.html
Geschachtelte Bedingungen
mit geschützten Klauseln
ersetzen
Quelle: http://refactoring.com/catalog/replaceNestedConditionalWithGuardClauses.html
Mehrere Bedingungen
konsolidieren
Alle
Bedingungen
liefern den
gleichen Wert
wenn true
Methoden vereinen
Quelle: http://refactoring.com/catalog/consolidateConditionalExpression.html
Code-Duplikate in einen
Ausdruck packen
Beide Fälle
Wenden gleiche
Methode an
Methode nach
'außen'
verfrachten
Quelle: http://refactoring.com/catalog/consolidateDuplicateConditionalFragments.html
Abfrage und Modifizierung
trennen
Quelle: http://refactoring.com/catalog/separateQueryFromModifier.html
Typ-Codierung mit Strategy
ersetzen
Codierung mit 0
oder 1 Werten
Typdefinition
mithilfe von
Klassen
Engineer
Salesman
Hinweis:
Fehler im original Bild:
Quelle: http://refactoring.com/catalog/replaceTypeCodeWithStateStrategy.html
Array mit Objekten ersetzen
Informationen an
festen Positionen
in statischem Array
Objekte mit get/setter für
feste Informationstypen
Quelle: http://refactoring.com/catalog/replaceArrayWithObject.html
Magische Nummern mit
symbolischen Konstanten
ersetzen
Wiederkehrende Zahlen
Verwendung von Konstanten
Quelle: http://refactoring.com/catalog/replaceMagicNumberWithSymbolicConstant.html
Konstructor-Zuweisungen
nach oben ziehen
Initialisieren von geerbten
Attributen
… kann an Konstrukter der
Oberklasse weitergereicht
werden.
Quelle: http://refactoring.com/catalog/pullUpConstructorBody.html
Weiterführende Literatur
●
●
●
●
„The Art of Agile Development“; Autoren:James Shore & Shane Warden, Verlag: O'Reilly.
„Essential Skills for the Agile Developer – A Guide to Better Programming and Design“;
Autoren: Alan Shalloway, Scott Bain, Ken Pugh, Amir Kolsky. Verlag: Addison-Wesley
„Practices of an Agile Developer“; Autoren: Venkat Subramaniam & Andy Hunt. Verlag:
The Pragmatic Programmers.
„Refactoring: Improving the Design of Existing Code“; Autoren: Martin Fowler; Verlag:
Booch Jacobson Rumbaugh.
–
●
Alternativ sind alle Refactorings online: http://refactoring.com/catalog/
Interessante Youtube Videos zu Refactorings:
https://www.youtube.com/playlist?list=PLGLfVvz_LVvSuz6NuHAzpM52qKM6bPlCV
(Kanal von Derek Banas)