Auf dem Weg zu Unwartbarkeit - Die besten Strategien für den sicheren Erfolg!Benjamin Schmid
Auf dem Weg zu Unwartbarkeit - Die besten Strategien für den sicheren Erfolg!
Eine süffisante, praxisnahe Reise durch die Fallstricke der Softwareentwicklung
This document outlines 50 essential content marketing hacks presented by Matt Heinz, President of Heinz Marketing Inc. at CMWorld. It provides an agenda for the presentation and covers topics such as content planning, measurement, formats, distribution, influencer engagement, repurposing content, and getting sales teams to leverage content. The goal is to provide new tools, tricks and best practices to help convert readers into customers through effective content marketing.
Auf dem Weg zu Unwartbarkeit - Die besten Strategien für den sicheren Erfolg!Benjamin Schmid
Auf dem Weg zu Unwartbarkeit - Die besten Strategien für den sicheren Erfolg!
Eine süffisante, praxisnahe Reise durch die Fallstricke der Softwareentwicklung
This document outlines 50 essential content marketing hacks presented by Matt Heinz, President of Heinz Marketing Inc. at CMWorld. It provides an agenda for the presentation and covers topics such as content planning, measurement, formats, distribution, influencer engagement, repurposing content, and getting sales teams to leverage content. The goal is to provide new tools, tricks and best practices to help convert readers into customers through effective content marketing.
Slides für meinen Workshop bei der BASTA Spring 2014 in Darmstadt. Hier eine Beschreibung des Workshopinhalts: Es ist schwierig genug, die Anforderungen der Kunden und Kollegen im Alltag zu erfüllen. Da bleibt nicht immer genug Zeit, um auch noch up to date zu bleiben was Neuerungen in C# betrifft. Wenn Ihnen dieses Problem bekannt vorkommt, kann dieser Workshop helfen. Wir widmen einen ganzen Tag besserem C#. Rainer Stropek, bekannter BASTA!-Speaker und Microsoft MVP, zeigt Ihnen, was C# mittlerweile leisten kann. Der Schwerpunkt im Workshop liegt diesmal auf folgenden Themen:
Coding und Design Guidelines – Best und Worst Practices, um besseren C#-Code zu schreiben.
Deep Dive in Lambdas und Linq – was hinter den Kulissen geschieht, wo sie helfen und wo sie mehr schaden als zu nützen.
Parallele und asynchrone Programmierung mit Task Parallel Library (TPL) und async/await – praktische Anwendung am Server und im Full-Client
Modularisierung von .NET-Anwendungen mit NuGet, MEF und Portable Class Libraries (PCL)
Neuerungen in Visual Studio 2013 für C#-Entwickler – alle Beispiele werden mit Visual Studio 2013 gezeigt. Sie erfahren dabei, was VS2013 an Verbesserungen für C#-Entwickler bringt.
Rainer Stropek setzt bei den Teilnehmern C#-Wissen zumindest auf dem Level von Version 2, idealerweise auch ein wenig Version 3, voraus. Ein eigener Laptop ist nicht Voraussetzung. Alle Konzepte werden anhand vieler Live-Coding-Beispiele erklärt. Zusätzlich erhalten alle Teilnehmer eine umfangreiche Präsentation als Zusammenfassung der gezeigten Themen.
Was macht Clean Code aus? Wie kann man seinen Code verbessern? Welche Regeln helfen einem Programmierer, um zu sauberen Code zu gelangen? Welche Tipps und Tricks gibt es, mit denen man sich noch verbessern kann? Gibt es Patterns bzw. Muster, die zum Erfolg führen? Oder ist Clean Code nur Zeitverschwendung in Projekten unter Zeitdruck?
Wer das legendäre Buch 'Clean Code' noch nicht gelesen hat, oder eine Auffrischung gebrauchen kann, ist zu diesem Live-Stream gerne willkommen. Um es praxisnah zu halten, werden viele Code-Schnipsel gezeigt, die wir zusammen analysieren und verbessern.
Clean Code - A Handbook of Agile Software Craftsmanship: Englische Ausgabe
https://amzn.to/3pXpCOS
Clean Code - Refactoring, Patterns, Testen und Techniken für sauberen Code: Deutsche Ausgabe
https://amzn.to/3cNO55B
Diese Videobeschreibung enthält Amazon Affiliate Links, mit denen ihr mich beim Kauf unterstützen könnt, ich erhalte eine kleine Provision während ihr nichts extra zahlt für euren Amazon-Einkauf!
http://www.opitz-consulting.com/go/3-4-11
Größere Oracle Forms Applikationen sind nicht denkbar ohne den Einsatz von Frameworks. Im einfachsten Fall sind es ein paar selbst geschriebene Libraries, die man in seiner Applikation nutzt. Auf der anderen Seite des Spektrums steht der Einsatz von PL/SQL- und Objekt-Libraries, Referenztemplates und Datenbank-API’s. Entwicklungs-Handbücher, z.B. für einen Style Guide, Namenskonventionen oder eine Versionierungsdokumentation, sollten ebenfalls nicht fehlen.
In seinem Vortrag bei der DOAG Konferenz 2014 beschrieb unser Forms Experte Gerd Volberg, wie man alle diese Teile eines Frameworks selbst konzipieren kann, worauf man achten sollte und wie man ggf. ein neues Framework in eine bestehende Forms Landschaft integrieren kann. Source-Code-Beispiele illustrierten dabei jeden einzelnen Bereich und wurden zusammen mit der Vortragsdokumentation auf der offiziellen Konferenz-Website veröffentlicht.
--
Über uns:
Als führender Projektspezialist für ganzheitliche IT-Lösungen tragen wir zur Wertsteigerung der Organisationen unserer Kunden bei und bringen IT und Business in Einklang. Mit OPITZ CONSULTING als zuverlässigem Partner können sich unsere Kunden auf ihr Kerngeschäft konzentrieren und ihre Wettbewerbsvorteile nachhaltig absichern und ausbauen.
Über unsere IT-Beratung: http://www.opitz-consulting.com/go/3-8-10
Unser Leistungsangebot: http://www.opitz-consulting.com/go/3-8-874
Karriere bei OPITZ CONSULTING: http://www.opitz-consulting.com/go/3-8-5
Java Code Quality: Gute Software braucht guten Code - Regeln für verständlich...GFU Cyrus AG
Kurzbeschreibung
Softwarequalität ist keine Spracheigenschaft. In jeder noch so guten Programmiersprache kann man schlechte Programme schreiben – sogar in Java. Herr Seekamp, Senior Consultant bei der GEDOPLAN GmbH, macht in diesem Vortrag anhand von Fallbeispielen aus seinen Projekten deutlich, was verständlichen und wartbaren Code ausmacht, welche Regeln man dafür beherzigen sollte und welche Analysewerkzeuge dabei unterstützen können.
Inhalt
Regeln für guten Java-Code
Statische Code-Analyse
Refactoring
Werkzeuge zur Sicherung der Qualität
Am 27. April 2011 referiert Informatik-Student Marcus Riemer zu seiner Evaluierung der C++-Algorithmenbibliothek LEDA. Der Vortrag startet um 17 Uhr in Hörsaal 5.
Die Algorithmenbibliothek LEDA (Library of Efficient Data types and Algorithms) entstand am Max-Planck-Institut für Informatik in Saarbrücken unter der Leitung von Prof. Kurt Mehlhorn. Sie wird seit Jahren kommerziell vertrieben. Der Referent studiert an der FH Wedel Informatik und hat mehrjährige C++-Erfahrung. Er führte eine ausführliche Evaluierung durch und vergleicht die Ergebnisse mit der C++-Standardbibliothek und der Open-Source-Bibliothek Boost.
#SpeakRoslyn - Die Microsoft .NET Compiler PlattformRobin Sedlaczek
This are the slides from my talk about the Microsoft .NET Compiler Platform. I traveled around the .NET User Groups in Germany and showed them the .NET Compiler Platform aka Project Roslyn and how Visual Studio 2015 was partly reimplemented to make use of Roslyn.
The Lotus Code Cookbook - Ulrich Krause
Tipps, Tipps, Tipps ... Die Session behandelt kein zentrales Thema. In loser Folge werden Tipps und Tricks aus allen Bereichen der Programmierung in Lotus Notes / Domino vorgestellt. @Formula, LotusScript, Java, JavaScript, LS2CApi.
Zielgruppe sind Alle, die sich mit Applikationsentwicklung beschäftigen. Anfänger und "alte Hasen"; es ist für jeden etwas dabei.
Diese Präsentation gibt einen umfassenden Überblick über die Programmiersprache Dart und ihre Konzepte. Um diesen Überblick schnell erfassen zu können, ist es hilfreich eine Programmiersprache wie bspw. Java zu beherrschen sowie die Konzepte der Objektorientierung zu kennen.
Im Teil I wird die Sprache Dart an sich dargestellt. Es wird ein Überblick über die optionale Typisierung, Datentypen, Funktionen, Operatoren, OO-Möglichkeiten sowie Generics in Dart gegeben.
Teil II wird sich dem Library System von Dart sowie der asynchronen Programmierung, der IO Programmierung, der DOM-Tree Programmierung, server- und clientseitiger Programmierung sowie der Konvertierung von Datenformaten widmen.
Slides für meinen Workshop bei der BASTA Spring 2014 in Darmstadt. Hier eine Beschreibung des Workshopinhalts: Es ist schwierig genug, die Anforderungen der Kunden und Kollegen im Alltag zu erfüllen. Da bleibt nicht immer genug Zeit, um auch noch up to date zu bleiben was Neuerungen in C# betrifft. Wenn Ihnen dieses Problem bekannt vorkommt, kann dieser Workshop helfen. Wir widmen einen ganzen Tag besserem C#. Rainer Stropek, bekannter BASTA!-Speaker und Microsoft MVP, zeigt Ihnen, was C# mittlerweile leisten kann. Der Schwerpunkt im Workshop liegt diesmal auf folgenden Themen:
Coding und Design Guidelines – Best und Worst Practices, um besseren C#-Code zu schreiben.
Deep Dive in Lambdas und Linq – was hinter den Kulissen geschieht, wo sie helfen und wo sie mehr schaden als zu nützen.
Parallele und asynchrone Programmierung mit Task Parallel Library (TPL) und async/await – praktische Anwendung am Server und im Full-Client
Modularisierung von .NET-Anwendungen mit NuGet, MEF und Portable Class Libraries (PCL)
Neuerungen in Visual Studio 2013 für C#-Entwickler – alle Beispiele werden mit Visual Studio 2013 gezeigt. Sie erfahren dabei, was VS2013 an Verbesserungen für C#-Entwickler bringt.
Rainer Stropek setzt bei den Teilnehmern C#-Wissen zumindest auf dem Level von Version 2, idealerweise auch ein wenig Version 3, voraus. Ein eigener Laptop ist nicht Voraussetzung. Alle Konzepte werden anhand vieler Live-Coding-Beispiele erklärt. Zusätzlich erhalten alle Teilnehmer eine umfangreiche Präsentation als Zusammenfassung der gezeigten Themen.
Was macht Clean Code aus? Wie kann man seinen Code verbessern? Welche Regeln helfen einem Programmierer, um zu sauberen Code zu gelangen? Welche Tipps und Tricks gibt es, mit denen man sich noch verbessern kann? Gibt es Patterns bzw. Muster, die zum Erfolg führen? Oder ist Clean Code nur Zeitverschwendung in Projekten unter Zeitdruck?
Wer das legendäre Buch 'Clean Code' noch nicht gelesen hat, oder eine Auffrischung gebrauchen kann, ist zu diesem Live-Stream gerne willkommen. Um es praxisnah zu halten, werden viele Code-Schnipsel gezeigt, die wir zusammen analysieren und verbessern.
Clean Code - A Handbook of Agile Software Craftsmanship: Englische Ausgabe
https://amzn.to/3pXpCOS
Clean Code - Refactoring, Patterns, Testen und Techniken für sauberen Code: Deutsche Ausgabe
https://amzn.to/3cNO55B
Diese Videobeschreibung enthält Amazon Affiliate Links, mit denen ihr mich beim Kauf unterstützen könnt, ich erhalte eine kleine Provision während ihr nichts extra zahlt für euren Amazon-Einkauf!
http://www.opitz-consulting.com/go/3-4-11
Größere Oracle Forms Applikationen sind nicht denkbar ohne den Einsatz von Frameworks. Im einfachsten Fall sind es ein paar selbst geschriebene Libraries, die man in seiner Applikation nutzt. Auf der anderen Seite des Spektrums steht der Einsatz von PL/SQL- und Objekt-Libraries, Referenztemplates und Datenbank-API’s. Entwicklungs-Handbücher, z.B. für einen Style Guide, Namenskonventionen oder eine Versionierungsdokumentation, sollten ebenfalls nicht fehlen.
In seinem Vortrag bei der DOAG Konferenz 2014 beschrieb unser Forms Experte Gerd Volberg, wie man alle diese Teile eines Frameworks selbst konzipieren kann, worauf man achten sollte und wie man ggf. ein neues Framework in eine bestehende Forms Landschaft integrieren kann. Source-Code-Beispiele illustrierten dabei jeden einzelnen Bereich und wurden zusammen mit der Vortragsdokumentation auf der offiziellen Konferenz-Website veröffentlicht.
--
Über uns:
Als führender Projektspezialist für ganzheitliche IT-Lösungen tragen wir zur Wertsteigerung der Organisationen unserer Kunden bei und bringen IT und Business in Einklang. Mit OPITZ CONSULTING als zuverlässigem Partner können sich unsere Kunden auf ihr Kerngeschäft konzentrieren und ihre Wettbewerbsvorteile nachhaltig absichern und ausbauen.
Über unsere IT-Beratung: http://www.opitz-consulting.com/go/3-8-10
Unser Leistungsangebot: http://www.opitz-consulting.com/go/3-8-874
Karriere bei OPITZ CONSULTING: http://www.opitz-consulting.com/go/3-8-5
Java Code Quality: Gute Software braucht guten Code - Regeln für verständlich...GFU Cyrus AG
Kurzbeschreibung
Softwarequalität ist keine Spracheigenschaft. In jeder noch so guten Programmiersprache kann man schlechte Programme schreiben – sogar in Java. Herr Seekamp, Senior Consultant bei der GEDOPLAN GmbH, macht in diesem Vortrag anhand von Fallbeispielen aus seinen Projekten deutlich, was verständlichen und wartbaren Code ausmacht, welche Regeln man dafür beherzigen sollte und welche Analysewerkzeuge dabei unterstützen können.
Inhalt
Regeln für guten Java-Code
Statische Code-Analyse
Refactoring
Werkzeuge zur Sicherung der Qualität
Am 27. April 2011 referiert Informatik-Student Marcus Riemer zu seiner Evaluierung der C++-Algorithmenbibliothek LEDA. Der Vortrag startet um 17 Uhr in Hörsaal 5.
Die Algorithmenbibliothek LEDA (Library of Efficient Data types and Algorithms) entstand am Max-Planck-Institut für Informatik in Saarbrücken unter der Leitung von Prof. Kurt Mehlhorn. Sie wird seit Jahren kommerziell vertrieben. Der Referent studiert an der FH Wedel Informatik und hat mehrjährige C++-Erfahrung. Er führte eine ausführliche Evaluierung durch und vergleicht die Ergebnisse mit der C++-Standardbibliothek und der Open-Source-Bibliothek Boost.
#SpeakRoslyn - Die Microsoft .NET Compiler PlattformRobin Sedlaczek
This are the slides from my talk about the Microsoft .NET Compiler Platform. I traveled around the .NET User Groups in Germany and showed them the .NET Compiler Platform aka Project Roslyn and how Visual Studio 2015 was partly reimplemented to make use of Roslyn.
The Lotus Code Cookbook - Ulrich Krause
Tipps, Tipps, Tipps ... Die Session behandelt kein zentrales Thema. In loser Folge werden Tipps und Tricks aus allen Bereichen der Programmierung in Lotus Notes / Domino vorgestellt. @Formula, LotusScript, Java, JavaScript, LS2CApi.
Zielgruppe sind Alle, die sich mit Applikationsentwicklung beschäftigen. Anfänger und "alte Hasen"; es ist für jeden etwas dabei.
Diese Präsentation gibt einen umfassenden Überblick über die Programmiersprache Dart und ihre Konzepte. Um diesen Überblick schnell erfassen zu können, ist es hilfreich eine Programmiersprache wie bspw. Java zu beherrschen sowie die Konzepte der Objektorientierung zu kennen.
Im Teil I wird die Sprache Dart an sich dargestellt. Es wird ein Überblick über die optionale Typisierung, Datentypen, Funktionen, Operatoren, OO-Möglichkeiten sowie Generics in Dart gegeben.
Teil II wird sich dem Library System von Dart sowie der asynchronen Programmierung, der IO Programmierung, der DOM-Tree Programmierung, server- und clientseitiger Programmierung sowie der Konvertierung von Datenformaten widmen.
4. Gibt es guten und schlechten Code?
Software muss funktional korrekt sein
Software muss effizient bearbeitbar sein
Ist (fast) nie fertig
Wird (meist) im Team entwickelt
Teams ändern sich über die Zeit
unterschiedliche Berufserfahrung, Programmierstile, …
Software muss verständlich sein
Gute Zeilen, schlechte Zeilen
4
5. Richtlinien
… helfen
bei der Einarbeitung in fremde Software
bei der (Weiter-) Entwicklung
Low Level: Namen, Formatierung …
Grundlegendes Klassendesign
Code-Komplexität
Anwendungsstruktur
Gute Zeilen, schlechte Zeilen
5
6. Statische Code-Analyse
Matching des Codes gegen Regelsätze
Einfache (Text-)Pattern … strukturelle Pattern
Checkstyle
Gute Zeilen, schlechte Zeilen
6
7. Dokumentation
Javadoc für API
Klassen, Interfaces,
Methoden, Variablen
public, protected
Kontrolle bspw. per Checkstyle
Javadoc Comments
Prüft per Default auch private
scope = protected
Getter/Setter-Doku meist überflüssig
allowMissingPropertyJavadoc = true
Gute Zeilen, schlechte Zeilen
7
8. Dokumentation
API-Dokumentation
veröffentlichen
Source-Jars erzeugen,
z. B. mit Maven
ermöglicht Unterstützung durch
die IDE
Gute Zeilen, schlechte Zeilen
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-source-plugin</artifactId>
<inherited>true</inherited>
<executions>
<execution>
<id>attach-sources</id>
<phase>verify</phase>
<goals>
<goal>jar-no-fork</goal>
</goals>
</execution>
</executions>
</plugin>
8
9. Dokumentation
Erklärungsbedürftige Codesequenzen
/*
* Fahrstrassen innerhalb von Fahrstrassen expandieren, d. h. durch ihre Elemente
* ersetzen. Dies geschieht in einer Schleife solange, bis alle Expansionen
* erledigt sind oder kein Fortschritt mehr erzielt wird.
*/
int letzteAnzahlFahrstrassenFahrstrassen = 0;
int anzahlFahrstrassenFahrstrassen = 0;
while (true)
{
for (Fahrstrasse fahrstrasse : this.fahrstrassen)
…
Trivialdokumentation ist überflüssig
// Neue Weichenstellung protokollieren
this.logger.trace(this + ": setStellung(" + stellung + ")");
Gute Zeilen, schlechte Zeilen
9
10. Namen
Klassen, Variablen, Methoden entsprechend ihrer Aufgabe benennen
spart umfangreiche Dokumentation
Well-Known Names nicht umdeuten!
Anschauungsbeispiel: "Nothalt-Funktion"
public void setAnlagenstatus()
{
Anlagenstatus.getInstance().changeAnlagenstatus();
Anlagenstatus ist zu generell
Methode setzt den Status nicht, sondern toggelt
setXyz ist well-known mit anderer Bedeutung
Gute Zeilen, schlechte Zeilen
10
11. Namen
Keine Präfixnotation für Typen, Sichtbarkeit etc.:
Instanzvariable
Name beginnt mit m_
Variable vom Typ List<Integer>
Name beginnt mit lI_
Interface
Name beginnt mit I
…
…
Präfixnamen tendieren zur Unlesbarkeit
this. ist aussagekräftiger (OO) als m_
Unterscheidung Klasse vs. Interface zweitrangig
werden durch IDE-Unterstützung mehr als ersetzt
Gute Zeilen, schlechte Zeilen
11
12. Namen
CS kann Namenskonventionen prüfen
(Module group Naming Conventions)
IDE-Komfort nutzen!
Quick fix: Namensvorschläge (Variablen, Konstanten ..)
Save actions: Member mit this. qualifizieren
…
Gute Zeilen, schlechte Zeilen
12
13. Formatierung
Code sollte im Team einheitlich formatiert sein
Einrückung (Tab/Blanks, wie viele?)
Platzierung von {
…
Vorteile
Code liest sich leichter
kleinere Change Sets im SCM
Lässt sich mit IDE-Komfort leicht erreichen
Save action: Format code
Überprüfung durch Code Checker eher zweitrangig
Gute Zeilen, schlechte Zeilen
13
14. equals, hashCode
Jedes Geschäftsobjekt sollte equals und hashCode definieren
IDEs bieten gute Unterstützung
Achtung bei equals in Basisklassen
public class BadEquals
{
public boolean equals(Object obj)
{
…
if (getClass() != obj.getClass())
// if (!(obj instanceof BadEquals)) // unsymmetrisch, wenn Subklasse überschreibt
// if (obj.getClass() != BadEquals.class) // funktioniert nicht für Subklassen
{
…
Gute Zeilen, schlechte Zeilen
14
15. equals, hashCode
equals definieren hashCode definieren
nicht nur equals(MyType)
Codeanalyse:
CS: Equals and Hashcode, Covariant Equals
FB: Class defines equals and uses Object.hashCode
Gute Zeilen, schlechte Zeilen
15
20. Komplexität
Klassen / Methoden nicht zu lang
Anzahl Methodenparameter nicht zu groß
CS: Maximum Method Length, Maximum Parameters,
Maximum File Length,
Cyclomatic Complexity
(Anwendung im
Team diskutieren!)
Gute Zeilen, schlechte Zeilen
20
21. Einfach machen
Einfache Lösungen sind gute Lösungen
Vorsicht bei:
Reflection
extrem schlecht lesbar
Refactoring problematisch
hochgradig konfigurierbaren Klassen
schwer nutzbar (bspw. GridBagConstraints)
übermäßigem Einsatz von Typparametern
Gute Zeilen, schlechte Zeilen
21
22. Einfach machen
Anschauungsbeispiel: Entity Editor
Generischer Editor für Geschäftsobjekte
Steuerung per Annotation @Editable
Remote funktionsfähig ( kein EntityManager)
Hochgradige Nutzung von Reflection
Umfangreiche Konfiguration von Services etc.
Einsatzfall BDE-System
ca. 35 Entities
Gute Zeilen, schlechte Zeilen
22
23. Klassen sparen lohnt nicht
Anschauungsbeispiel "Wachdienst":
Gebäudekontrolle durch Prüfung aller Räume
Räume sind auf Etagen verteilt
Kontrollierte Räume
werden abgehakt
Gute Zeilen, schlechte Zeilen
23
24. Klassen sparen lohnt nicht
Anschauungsbeispiel "Wachdienst"
1. Ansatz: Keine Klasse für Etage
Dialogaufbau unnötig kompliziert
(~ Gruppenwechsel)
Kein Platz für zukünftige Erweiterung
um Etagen-Daten
Gute Zeilen, schlechte Zeilen
24
25. Klassen sparen lohnt nicht
Anschauungsbeispiel "Wachdienst"
Besser: Zusätzliche Ebene für Etagen
Klares Konzept
Real World Klasse
Gute Zeilen, schlechte Zeilen
25
26. Wohin mit der Logik?
Gute Zeilen, schlechte Zeilen
26
27. Wohin mit der Logik?
Anschauungsbeispiel "Modellbahnsteuerung":
Reservieren einer Fahrstraße
=Stellen der betroffenen
Weichen und Signale
Fahrstrasse liegt als
Geschäftsobjekt vor
Anforderung als Webservice
Gute Zeilen, schlechte Zeilen
27
28. Wohin mit der Logik?
Anschauungsbeispiel "Modellbahnsteuerung":
1. Ansatz: Iteration über Fahrstraßenelemente im Webservice
Nachteile:
nicht wiederverwendbar, da
im Webservice
"Polymorphie
für Arme"
(instanceof
~ goto der OO)
Gute Zeilen, schlechte Zeilen
@POST
@Path("/fahrstrasse/{bereich}/{name}/reserviert")
public Response setFahrstrassenreservierung(...)
{
Fahrstrasse fahrstrasse = …
for (FahrstrassenElement fe
: fahrstrasse.getElemente())
{
Fahrwegelement fwe = fe.getFahrwegelement();
if (fwe instanceof Weiche)
{
Weiche w = (Weiche) fwe;
w.setStellung(…);
}
…
28
29. Wohin mit der Logik?
Anschauungsbeispiel "Modellbahnsteuerung":
Besser: Platzierung der Logik in Fahrstrasse,
abstrakte Methode statt expliziter Typabfrage
@Path("{bereich}/{name}/reserviert")
@POST
public Response setReserviert(…)
{
Fahrstrasse fahrstrasse = …
fahrstrasse.setReserviert(reserviert);
}
public void setReserviert(boolean reserviert)
{
for (FahrstrassenElement element : this.elemente)
element.setReserviert(reserviert);
public abstract void setReserviert(boolean reserviert);
Gute Zeilen, schlechte Zeilen
29
30. Wohin mit der Logik?
Geschäftslogik in Geschäftslogik-Schicht
CDI, EJB, JPA, …
Präsentationslogik bspw. in JSF-Beans
CDI-Models, Managed Beans
Boundary-Code in EJBs, Webservices etc.
Saubere Schichtung
erhöht Wiederverwendbarkeit
macht den Code übersichtlicher
Gute Zeilen, schlechte Zeilen
30
31. In Objekten denken
Anschauungsbeispiel: 1:n-Relation (JPA)
@Entity
public class Book
{
@Id @GeneratedValue Integer
id;
@ManyToOne
Publisher publisher;
@Entity
public class Publisher
{
@Id @GeneratedValue
Integer
id;
@OneToMany(mappedBy = "publisher") List<Book> books;
…
Query "Suche Books eines Publishers"
(Warum so kompliziert?):
Publisher publisher = …;
… em.createQuery("select b from Book b where b.publisher.id=:publisherId", Book.class)
.setParameter("publisherId", publisher.getId())
.getResultList();
Gute Zeilen, schlechte Zeilen
31
33. Anekdoten
Offensichtlich komplett falsche Vorstellung
von Objekten und Referenzen darauf
String name = new String();
name = "Hugo";
instanceof
if (val != null && ("" + val.getClass().getName()).equals("java.lang.String"))
Sind die Labels nicht Texte? Warum dann Set<Object>?
Wenn unterschiedliche Typen erlaubt: Set<?>
Set<String> texte = …;
Set<Object> labels = new TreeSet<>();
labels.addAll(texte);
Integer.toString(adr)
int adr = …;
String adrAsString = new Integer(adr).toString();
Gute Zeilen, schlechte Zeilen
33
34. Anekdoten
setRueckwaerts(!isRueckwaerts())
public static final Anlagenstatus
public void changeRichtung()
= new Anlagenstatus()
{
if (isRueckwaerts())
Noch besser: enum-Singleton
setRueckwaerts(false);
else
setRueckwaerts(true);
}
public class Anlagenstatus
{
private static Anlagenstatus anlagenstatus = null;
private Anlagenstatus() { }
public static Anlagenstatus getInstance()
{
if (anlagenstatus == null)
anlagenstatus = new Anlagenstatus();
return anlagenstatus;
}
Gute Zeilen, schlechte Zeilen
34
35. Anekdoten
@POST
@Path("artikel/{artNr}/menge")
public Response setSpeed(@PathParam("artNr") String adrNr,
@FormParam("menge") String menge)
{
try
{
int mengeInt = Integer.parseInt(menge);
…
}
catch (NumberFormatException e)
{
int menge
Auto car1 = ...;
Auto car2 = ...;
if (car1.getId().getValue().equals(car2.getId().getValue()))
{
...
if (car1.equals(car2))
Gute Zeilen, schlechte Zeilen
35
37. Unit Tests
Test der funktionalen Korrektheit
auf Unit-Ebene
einzelne Klasse
isoliert von ihrer Umgebung, ggf. mittels Mock-Objekten
als Integrationstests
während der Entwicklung
als nachträglich Absicherung
oder als Vorgehensweise (Test Driven Development)
als Qualitätssicherungsmaßnahme
automatisiert
regelmäßig
Gute Zeilen, schlechte Zeilen
37
38. Unit Tests
nicht aufwändiger als Main-Programm zum „Ausprobieren“
public class WaehrungServiceUnitTest
{
private static WaehrungService WAEHRUNG_SERVICE = new WaehrungService();
@Test
public void testUmrechnenUSD()
{
double actual = WAEHRUNG_SERVICE.umrechnen(100.0, "USD");
assertThat("Euro-Betrag", actual, is(83.41));
}
public class WaehrungServiceMain
{
private static WaehrungService
WAEHRUNG_SERVICE = new WaehrungService();
public static void main(String [] args)
{
BigDecimal actual = WAEHRUNG_SERVICE.umrechnen(100.0, "USD");
System.out.println("100 USD = " + actual + " EUR");
}
Gute Zeilen, schlechte Zeilen
38
39. Unit Tests
Testwissen wird explizit gemacht
als Einstiegsdokumentation / Tutorial geeignet
automatisch, unbedient ausführbar
Continuous Integration (Hudson, Jenkins, …)
regelmäßige Ausführung aller Tests effizient möglich
dauerhafte Qualitätssicherung
unverzichtbar für Refactoring und Weiterentwicklung
Absicherung gegen „Verschlimmbesserung“
Gute Zeilen, schlechte Zeilen
39
40. Continuous Integration
Manuelle Ausführung reicht nicht
belastet den Entwicklungsprozess
keine (einheitliche) Veröffentlichung der Ergebnisse
keine (einheitliche) Eskalation bei Fehlern
An dem Teil habe ich
nichts gemacht!
Bei mir läuft's!
Gute Zeilen, schlechte Zeilen
Oh, sorry – das habe
ich noch nicht
eingecheckt.
40