Be Good – was ein guter Entwickler können muss

Kürzlich wurde ich von einem Junior ganz am Anfang seiner Karriere als Entwickler gefragt: “Wie wird man ein guter Entwickler?”

Jeder halbwegs professionelle Entwickler hat sich diese Frage selbst schon mehrfach gestellt, aber so direkt gefragt bleibt zunächst nur Stottern und Stammeln.

“Ja, klar, äh, ganz einfach, du lernst.. Dingens.. Patterns, hier Visitor und Observer, kennst du ja. Auf jedenfall auch testen, ja, testen ist ganz wichtig. Ja, jetzt weiß ich auch nicht, mehr fällt mir jetzt nicht ein… ich muss weg…”.

Jetzt in aller Ruhe nochmal strukturiert die 4 wichtigesten Punkte, die ein Entwickler verstehen muss:

Kenne deine Domäne

Kaum etwas ist so wichtig, wie tatsächlich zu verstehen, was eigentlich benötigt wird und deswegen gebaut werden soll. Was ist das Geschäftsmodell? Womit verdient dein Kunde / deine Firma ihr Geld? Was sind die Geschäftsregeln und Prozesse? Finden sich diese auch im Code? Gibt es eine gemeinsame Sprache zwischen Fachbereich und Technik? Kannst du dich mit jemandem vom Fachbereich unterhalten ohne dass dieser den vielsagenden 1000 Yard-Blick bekommt und verträumt aus dem Fenster sieht? Verstehst du, wenn jemand aus dem Fachbereich mit dir über Requirements spricht oder muss immer jemand übersetzen?

Du als Entwickler solltest mindestens so gut über die Domäne bescheid wissen wie die Fachbereiche, denn um die Regeln in Software zu gießen musst du meist viel mehr wissen, als wenn du sie nur anwendest.

Verstehe das Problem

Warum stellt der Fachbereich ein Requirement? Und warum genau jetzt? Sollen vielleicht die Sales-Zahlen verbessert werden? Gibt es ein konkretes Problem beim Absatz eines Produktes? Sollen manuelle Schritte automatisiert werden um Geld, Zeit und nerven zu sparen? Was genau soll erreicht werden.

Eine Anforderung kannst / darfst / sollst du hinterfragen und zwar so lange / so oft bis du verstanden hast, was eigentlich das Grundproblem ist. Aus dem Toyota-Production-System gibt es das Prinzip der 5Ys. (Frage 5x Warum um auf die Ursache / die Wurzel eines Problems vorzustossen).

Auch die Fachbereiche profitieren von den Fragen aus der Technik, denn manchmal ist es auf den ersten Blick wirklich schwer, ein Problem zu erfassen.

Technologie ist unwichtig

Natürlich ist es als Enwickler wichtig, sich auf dem aktuellen Stand der Technik zu halten. Es sollte aber unnötig sein, das hier zu erwähnen – überlege jetzt sofort – wann hast du das letzte Mal etwas neues gelernt (Sprache, Konzepte, Pattern, Techniken?). Solltest du mehr als 15 Sek. überlegen müssen oder lautet die Antwort auf irgendetwas was mehr als 2 Wochen her ist solltest du dringend ein Buch aus der Liste unten kaufen und lesen..

Natürlich arbeiten Entwickler auch gerne mit den neuesten Technologien – damit sind wir produktiver, effizienter, besser, stärker, schneller und…

Grundsätzlich ist es aber tatsächlich so, dass die Technik eher eine untergeordnete Rolle spielt. Natürlich arbeitet niemand gerne mit Legacy-Software und hat bei jedem Commit Angst, etwas kaputt zu machen (weil man üblicherweise auch mit jedem Commit etwas kaputt macht, ob man es  wohl merkt oder nicht).

Selbst mit Technologien wie EJB und JSF lässt sich “gute” Software machen, wenn die Umgebung stimmt. Wenn ich die Wahl habe würde ich JSF natürlich nicht mit der Kneifzange anfassen, aber Technik ist meiner Ansicht nach nicht so wichtig wie eine interessante Domäne.

Daten und Verhalten ist nicht dasselbe

Der Einzige Punkt der sich direkt um Entwicklung dreht. Was die meisten Entwickler am Anfang ihrer Karriere nicht verstehen ist, Daten und Verhalten sind zwei paar Stiefel.

Beispiel folgende Klasse

public class Customer {
private String name;
private int age;
private List paymentTypes;
}

Ein unerfahrener Entwickler drückt sofort die ihm bestens bekannte Tastenkombination “Generate Getters + Setters” mit folgendem Resultat.

public class Customer {
private String name;
private int age;
private List paymentTypes;

public String getName() {
return name;
}

public void setName(String name) {
this.name = name;
}

//....

}

Folgende Probleme ergeben sich hierbei (die jeder erfahrene Entwickler kennt und hasst).

Der State des Kunden wird nach aussen hin sichtbar. Business-Regeln werden dadurch üblicherweise so abgebildet.

public void submitOrder(Order order, Customer customer) {
   
        List<Payment> paymentTypes = customer.getPaymentTypes();
        boolean paymentAccepted = false;
        for(Payment payment : paymentTypes) {
            if(payment.getType().equals(order.getPaymentType()) {
               paymentProvider.billCustomer(order.getPrice(), customer);
               paymentAccepted = true;
            }
        }
        if(!paymentAccepted) {
           throw new IllegalStateException("Payment not accepted - but code sucks...");
        }
    
}

Du findest den Code ok? Es gibt noch was zu lernen…

Eigentlich könnte der Code so aussehen:

public void submitOrder(Order order, Customer customer) {
    if(!customer.supportsPayment(order.getPaymentType()) {
       throw new PaymentNotAcceptedException("Customer does not accept Payment", customer, order);
    }
    paymentProvider.billCustomer(order.getPrice(), customer);
}

Du findest selbst diesen Code schlecht? Ich kann von Dir was lernen…

Der Kunde hat eine Liste von unterstützen PaymentTypes (Kreditkarte, PayPal, Bankeinzug oder Bar). Das sind die Daten des Kunden. Ob ein Kunde jetzt eine bestimmte Zahlung unterstützt ist wiederum Verhalten des Kunden. Um zu wissen, welche Zahlungsarten ein Kunde unterstützt muss aber nicht die Liste von Zahlungsarten nach aussen bekannt sein. Idealerweise fragen wir den Kunden einfach – was kannst du denn?

customer.supportsPayment?

Vorteil – kommt eine weitere  Zahlungsart hinzu funktioniert die Anwendung weiterhin, denn supportsPayment funktioniert für beliebig viele Zahlungsarten.

Hier geht es tatsächlich eigentlich um das Stichwort Objektorientierung. Es wurde und wird viel darüber geschrieben. Folgende Bücher empfehle ich hierzu.

Practical Object-Oriented Design in Ruby: An Agile Primer – Hier geht es eigentlich nicht um Ruby sondern um Objektorientierung

Domain Driven Design – Pflichtlektüre für jeden Entwickler

CQRS – The Example – Ein schönes Beispiel für eine alternative Architektur mit Hilfe von CQRS.

 

Effective Trainings & Consulting - Martin Dilger



Hat Ihnen dieser Blog-Eintrag gefallen? Ich stelle in diesem Blog Informationen über Tools, Frameworks und Werkzeuge zur Verfügung, die mich produktiver machen. Vielleicht kann ich auch Ihnen helfen, produktiver zu werden.


Ich unterstütze Sie als freier Mitarbeiter bei der Entwicklung von Software-Projekten, Agiler Arbeit sowie Schulungen / Fortbildungen.


Jeden Tag ein bisschen produktiver - ab heute