Als Entwickler haben wir gute Ideen und weniger gute. Manchmal ist es aber gar nicht so einfach, diese voneinander zu unterscheiden. Oder wir haben das Gefühl, dass etwas gut oder schlecht ist, haben aber Schwierigkeiten, dieses zu erklären. Hier helfen Softwareentwicklungsprinzipien. Diese in schlaue Sprüche gegossene Entwicklererfahrung hilft, Argumente zu finden und zu kommunizieren. Darüber hinaus lassen sich Prinzipien untereinander verknüpfen. Dabei entstehen Prinzipiensprachen, die helfen, Entwurfsentscheidungen systematisch zu treffen und zu begründen. Im Rahmen einer Gastvorlesung an der Uni Stuttgart wurden Prinzipien und Prinzipiensprachen vorgestellt und an Beispielen erläutert.
2. Organisatorisches
Folien enthalten nur wenig Text
Besser für Präsentation
Zusätzlich ausführlichere Vortragsnotizen online
Die Vortragsnotizen geben nicht notwendigerweise 1:1 den Vortrag wieder
Feedback erwünscht
Bei Fragen
Fragen!
Wenn kurze Antworten möglich sind, gleich
Ansonsten zum Ende eines Kapitels
® 1&1 Internet AG 2013
2
3. Vorstellung – Wer erzählt das hier alles eigentlich?
Christian Rehn, 25 Jahre, Softwareentwickler
Informatikstudium an der TU Kaiserslautern
Seit Mai im 1&1 Source Center
Blog: http://www.christian-rehn.de
Wiki: http://www.principles-wiki.net
E-Mail: christian.rehn@1und1.de
® 1&1 Internet AG 2013
3
13. Was unterscheidet gute Lösungen von schlechten?
Bewertung, nicht Generierung von Lösungen
Nicht: „Wie komme ich auf eine Lösung?“
Irgendwelche Lösungen zu finden, ist oft gar nicht das Problem
Sondern: „Wie weiß ich, ob das gut ist?“
® 1&1 Internet AG 2013
13
15. Prinzip: Definition
Ein Prinzip ist eine Daumenregel, die
gute von schlechten Lösungen
unterscheidet – in Bezug auf einen
Entwurfsaspekt.
® 1&1 Internet AG 2013
15
19. Murphy‘s Law (ML)
“If there’s more than one possible
outcome of a job or task, and one of
those outcomes will result in disaster
or an undesirable consequence, then
somebody will do it that way.”
® 1&1 Internet AG 2013
19
21. Murphy‘s Law (ML)
Aussage
Alles was schief gehen kann, wird irgendwann schiefgehen. Also ist eine
Lösung dann besser, wenn sie weniger Möglichkeiten zulässt, dass etwas
schiefgeht.
Begründung
Menschen machen Fehler und das wird sich nie grundlegend ändern.
Statistisch gesehen wird also auf lange Sicht, eine Fehler-Möglichkeit
auch zu einem Fehler führen.
Beispiel
Date date1 = new Date(2013, 01, 12);
® 1&1 Internet AG 2013
21
24. Keep It Simple Stupid (KISS)
“There are two ways of constructing a
software design: One way is to make it so
simple that there are obviously no
deficiencies, and the other way
is to make it so complicated that there are
no obvious deficiencies.” – Tony Hoare
® 1&1 Internet AG 2013
24
25. Keep It Simple Stupid (KISS)
Aussage
Einfache Lösungen sind besser als komplizierte.
Begründung
Wenn etwas einfacher ist, kann man es einfacher verstehen und ändern.
Wenn etwas einfacher ist, macht man weniger Fehler.
Beispiel
Eine Lösung ohne komplizierte Sprachfeatures wie polymorphe Enums,
innere Klassen und tiefe Vererbungshierarchien, …
® 1&1 Internet AG 2013
25
26. Generalization Principle (GP)
Aussage
Mächtige, allgemein anwendbare Lösungen sind besser als
Speziallösungen.
Begründung
Allgemeine Lösungen sind wiederverwendbar
Wenn sich die Anforderungen ändern, muss man spezielle Lösungen eher
ändern
Beispiel
Funktionen mit Parametern, wiederverwendbare Klassen, Generics, …
® 1&1 Internet AG 2013
26
31. Principle of Separate Understandability (PSU)
Aussage
Jedes Modul sollte separat verständlich sein.
Begründung
Andere Module lesen und verstehen zu müssen kostet unnötig Zeit und ist
fehleranfällig.
Beispiel
… folgt auf den nächten Folien …
® 1&1 Internet AG 2013
31
32. Principle of Separate Understandability (PSU)
// Anforderung:
printStatistics('d', 0); // „There are 0 ds“
printStatistics('d', 1); // „There is 1 d“
printStatistics('d', 25); // „There are 25 ds“
® 1&1 Internet AG 2013
32
33. Principle of Separate Understandability (PSU)
private void printStatistics(
} else {
number =
char ch, int count) {
String number; String verb;
Integer.toString(count);
String pluralModifier;
verb = "are";
if (count == 0) {
pluralModifier = "s";
number = "no";
}
verb = "are";
String message =
String.format("There %s %s
pluralModifier = "s";
%s%s", verb, number, ch,
} else if (count == 1) {
pluralModifier);
number = "1";
verb = "is";
pluralModifier = "";
® 1&1 Internet AG 2013
System.out.println(message);
}
33
34. Principle of Separate Understandability (PSU)
class StatisticsMessage {
private String number;
private String verb;
private String pluralModifier;
…
public String make(
char ch, int count) {
createMessageParts(count);
return String.format(
"There %s %s %s%s",
verb, number, ch,
private void createMessageParts(
int count) {
if (count == 0)
thereAreNoLetters();
else if (count == 1)
thereIsOneLetter();
else
thereAreManyLetters(count);
}
private void thereAreNoLetters() {
number = "no";
verb = "are";
pluralModifier = "s";
}
…
pluralModifier);
}
® 1&1 Internet AG 2013
34
35. Principle of Separate Understandability (PSU)
private String composeStatistics(char candidate, int count) {
Number number = requiresPluralForm(count) ?
PLURAL : SINGULAR;
return "There "
+ thirdFormOfToBe(number) + " "
+ countToString(count) + " "
+ declineLetter(candidate, number));
}
® 1&1 Internet AG 2013
35
36. Principle of Separate Understandability (PSU)
private boolean requiresPluralForm(int count) {
return count != 1;
}
private String thirdFormOfToBe(Number number) {
return number == SINGULAR ? "is" : "are";
}
private String countToString(int count) {
return count == 0 ? "no" : Integer.toString(count);
}
private String declineLetter(char letter, Number number) {
return number == SINGULAR ?
Character.toString(letter) : letter + "s";
}
® 1&1 Internet AG 2013
36
40. Bindung und Kopplung
Cohesion/Bindung
Maß für den Zusammenhalt eines Moduls
Coupling/Kopplung
Maß für die Abhängigkeiten zwischen den Modulen
® 1&1 Internet AG 2013
40
41. HC, LC und Abstraktionsstufen
® 1&1 Internet AG 2013
41
42. Low Coupling (LC)
Aussage
Die Kopplung zwischen Modulen sollte lose sein.
Begründung
Eine starke Kopplung zwischen den Modulen A und B bedeutet, dass
o.B.d.A. Modul A viele Annahmen über Modul B macht. Durch
Weiterentwicklung werden manche der Annahmen falsch werden. Es
entstehen Ripple Effects. Je weniger Annahmen/Abhängigkeiten da sind,
desto geringer ist die Wahrscheinlichkeit, dass Ripple Effects auftreten.
Beispiel
###ToDo: beispiel
® 1&1 Internet AG 2013
42
43. High Cohesion (HC)
Aussage
Die Bindung in einem Modul sollte stark sein.
Begründung
Eine schwache Bindung würde bedeuten, dass gewisse Teile des Moduls
„thematisch“ dort nicht hingehören. Zum einen verschlechtert das die
Lesbarkeit. Zum anderen bedeutet das ja auch, dass eine Änderung in
dem Modul sich auf Teile auswirken kann, die thematisch gar nicht
betroffen sein müssten. Auch das sind Ripple Effects.
Beispiel
###ToDo: beispiel
® 1&1 Internet AG 2013
43
46. Entwurfsentscheidungen
Modularisierung
Welche Artefakte, Klassen, Methoden, etc.
Modulkommunikation
Methodenaufrufe: wann, welche Klasse mit welcher anderen
Schnittstellen
Methodensignaturen, Parameter, …
…
® 1&1 Internet AG 2013
46
74. Fazit
Prinzipien
Sind wiederverwendbare von Erfahrung
Unterscheiden gute von schlechten Lösungen
Prinzipiensprachen
Vernetzen Prinzipien
Zeigen weiterführende Aspekte auf
Bilden ein Vokabular
www.principles-wiki.net
® 1&1 Internet AG 2013
74
75. Ausblick
Das Wiki wird ständig erweitert und ausgebaut
Weitere
Prinzipien
Prinzipiensprachen
Vernetzung von Patterns mit Prinzipien
Mitarbeit willkommen
® 1&1 Internet AG 2013
75
76. Ausblick: Ideen
Prinzipiensprachen für
Andere Programmierparadigmen
Prozedurale, funktionale, dynamische, 4GL etc. Programmierung
Andere Abstraktionsstufen
Architektur, Coding, Anforderungsanalyse, …
Andere Arten von Design
GUI Design, Webdesign, Mobile UI Design, …
DB-Entwurf, API Design, Communication Protocol Design, …
Nicht-Funktionale Anforderungen
Security, Performance, Usability, …
Spezielle Domänen
Embedded Systems, Enterprise Information Systems, Spiele, …
Medizin, Finanzen, Automotive, …
® 1&1 Internet AG 2013
76
77. Zeit für Fragen…
Vielen Dank für Ihre Aufmerksamkeit
Karriere bei 1&1
Speziell für Entwickler
Unternehmen kennenlernen
klassisch via
jobs.1und1.de
Kontaktnetzwerk knüpfen
Optimalen Job finden
77
78. Source Center
Wie funktioniert das Source Center?
Einarbeitung (Technologien, Prozesse, Kultur)
Teameinsatz (~6 Monate produktiver Einsatz)
Fach-/Technologische Spezifika kennenlernen
Soziales Netzwerk aufbauen
Standort übergreifender Einsatz möglich (finanziert AG)
Wechsel in dauerhafte Position jederzeit möglich (Gegenseitigkeit)
® 1&1 Internet AG 2013
81. Beispiel: Rahmenbedingungen
Rahmenbedingungen:
Eine Software verwendet intern Exceptions
An der Schnittstelle werden aber auch technischen Gründen (REST)
Fehlercodes erwartet
Anforderung: Exceptions in HTTP Response Codes übersetzen
® 1&1 Internet AG 2013
81
82. Beispiel: Lösung 1 – alles fangen
public Response doSomethong() {
try {
…
} catch (SomeException e) {
return Response.status(NOT_FOUND).build();
} catch (OtherException e) {
return Response.status(BAD_REQUEST).build;
}
}
® 1&1 Internet AG 2013
82
83. Beispiel: Lösung 2 – Exception Mapper pro Exception
public class SomeExceptionMapper implements
ExceptionMapper<SomeException> {
public Response toResponse(SomeException exception) {
return Response.status(NOT_FOUND).build();
}
}
® 1&1 Internet AG 2013
83
84. Beispiel: Lösung 3 – Ein Exception Mapper
public class BaseExceptionMapper implements
ExceptionMapper<BaseException> {
public Response toResponse(BaseException exception) {
return Response.status(exception.getStatus()).build();
}
}
® 1&1 Internet AG 2013
84