Beim Pair Programming sitzt man also mit einem Paar (gewöhnlich 2) Programmierern an einem Rechner und bearbeitet den gleichen Code. Und das soll sinnvoll sein? … Wir Programmierer im Shopoffice-Team finden: Jawohl! Wir schreiben besseren Code, produzieren weniger Bugs, sind konzentrierter bei der Arbeit und am allerwichtigsten: Wir haben mehr Spaß bei der Arbeit. Klar verwenden wir Pair Programming hier im Team schon sehr ausgiebig – aber es gibt immer etwas zu verbessern. Warum also nicht mal jemanden ins Team holen, der über mehr Praxis in diesem Bereich verfügt und Erfahrungen mit Pairing in verschiedenen Projekten gemacht hat? Wir haben uns für Thomas Much entschieden, der uns für einen Sprint lang bei der Arbeit begleiten sollte. Thomas war als Java- und Pair Programming-Coach schon in zahlreichen Projekten unterwegs und genau davon wollten wir profitieren.

In vielen Projekten erfolgt die Entwicklung von neuen Features in dem einen oder anderen Branching Modell wie zum Beispiel Git Flow: Features werden zunächst auf einem separaten Branch entwickelt und erst nach „Fertigstellung“ des Features wieder integriert. Beim Mergen der Änderungen kommt es dann gelegentlich zu Konflikten und wenn man Pech hat, landet man in der „Merging Hell“. Moderne VCS wie GIT machen Branching + Merging zwar deutlich einfacher, ändern aber auch nichts daran, dass es gelegentlich schwierig ist, konkurrierende Änderungen zu einem lauffähigen Deployment zu integrieren.

Das Hauptproblem mit Feature Branches ist aber ein anderes: Wann ist ein Feature „fertig“, kann also integriert werden? Erfolgt die Abnahme einer Story auf Basis des Feature Branches, muss nach der Integration eine weitere Qualitätssicherung erfolgen – denn sonst könnten sich Fehler in der Kombination mit parallel entwickelten Features einschleichen. Erfolgt die Qualitätssicherung erst nach der Integration auf einem Release Branch, könnte sich herausstellen, dass das Feature eben doch nicht fertig ist, weil die eine oder andere Anforderung nicht erfüllt ist.

Continuous Integration verfolgt daher einen anderen Weg: die Entwicklung erfolgt auf dem HEAD und jeder Commit wird direkt automatisiert integriert. Jenkins, TeamCity oder andere Tools helfen dabei, regelmässig alle paar Minuten einen aktuellen Build zu erstellen und auf einen CI Server zu deployen. Die Abnahme der Feature erfolgt entweder auf dem CI Server oder einer separaten Stage der Build Pipeline.

Teile und herrsche: Kleine Systeme für grosse Architekturen
von Stephan Kraus, Guido Steinacker, Oliver Wegner

Ein System = ein Team, wenige Richtlinien und viel Freiheit, Eigenverantwortung statt Governance, schlanke Integration über den Web-Standard REST, das Teilen eines großen Problems in viele kleine Probleme sowie permanente Veränderung, statt Angst vor dem großen Release.

In der Ausgabe September/Oktober 2013 des Magazins OBJEKTspektrum haben wir zum Schwerpunktthema „leichtgewichtige Architekturen“ einen Artikel über unsere neue E-Commerce-Plattform LHOTSE geschrieben.

Eines der Ziele, die wir uns für die Lhotse Plattform gesetzt haben ist Continous Delivery: Änderungen sollen nicht nur kontinuierlich integriert, sondern auch rasch in Produktion genommen werden, sobald die Abnahme erfolgt ist. Wie wir das in der Praxis erreichen wollen, ist ein anderes Thema. Damit wir aber prinzipiell in der Lage sind, jederzeit eine neue Version live zu stellen, muss das System in der Lage sein, ohne Unterbrechung auf ein neues Release umzuschalten.

Als in unserem Bereich die Ziele für einen neuen Onlineshop OTTO.de diskutiert wurden, war klar, dass die bestehenden Systeme der Produktdatenversorgung, sozusagen die Lebensader des Shops, „out-of-the-box“ nicht in der Lage sein würden, die nichtfunktionalen Ziele für den Shop mit zu erfüllen. Wieso? Unsere aktuelle Produktdatenversorgung exportiert auf Basis von Datenbanklinks massenhaft Daten, im wesentlichen als Vollexporte (Full Export), zwischen zwei Oracle-Datenbanken. Dabei wird zur Exportlaufzeit jede Menge Geschäftslogik („Business Rules“) ausgeführt, so zum Beispiel die Ermittlung, ob ein Artikel überhaupt exportierfähig für den Onlineshop ist, oder die Bestimmung von Anzeigereihenfolgen der Produkte auf unseren Produktlisten. Und das kostet Zeit.

Ich finde es immer wieder interessant, wie kreativ einige Fragestellungen lösbar sind. Ein Beispiel dafür sind die Tests für die in den Shop integrierte Recommendation Engine eines externen Herstellers. Natürlich wollen wir nicht nur wissen, ob die Integration technisch gelungen ist, sondern auch, ob die Performance und die Fachlichkeit stimmt. Zu diesem Thema hat mir Matthias aus meinem Team eine interessante Story erzählt, die ich Euch nicht vorenthalten möchte:

Mein aktuelles Spezialgebiet sind Produktempfehlungen. Damit meine ich vor allem Empfehlungen wie „Kunden interessiert auch“ oder „Wird zusammengekauft mit“. Meistens muss ich dann eine von zwei Fragen beantworten: „Warum sehe ich diese Empfehlung?“ und „Warum sehe ich diese Empfehlung nicht?“. Bei redaktionell gepflegten Empfehlungen ist das noch vergleichsweise einfach nachzuvollziehen. Schwieriger ist das bei Empfehlungen, die auf dem Klick- und Kaufverhalten der Kunden basieren. Aber auch das ist möglich.

The easiest way to crash your site.

With all the latest trends in the web such as “Social Sharing”, “Distributed marketing campaigns” or just simple website trackings, people tend to forget about one tiny simple fact:

Dependency on 3rd party vendors stability.

If your website is your sales channel or even your only product you must have the ambition to keep it running and fully functional 24/7 and with 99,99% uptime per year.

Auf unserem letzten Barcamp habe ich eine halbstündige Session „Pair-Programming for Non-Developers“ gehalten.

Warum das, …also, warum „for Non-Developers“?

Wir setzen hier bei Otto Pair Programming in der Softwareentwicklung ein und ich werde immer mal wieder gefragt warum wir das tun – vor allem auch von Nicht-Entwicklern. Deswegen habe ich mir eine Session überlegt, in der ich Pair Programming für Menschen fühlbar und erlebbar mache, die nicht aus der Softwareentwicklung stammen.

Der Begriff „Architektur“ bzw. „Software-Architekt“ hat in der Softwareentwicklung nicht den besten Ruf. Man denkt unwillkürlich an umfangreiche Konzepte, fehlenden Pragmatismus, Elfenbeintürme, Architektur-Reviews, merkwürdige UML-Diagramme voller Halbwahrheiten, „upfront design“, usw. usf. So ganz ohne Leitlinien geht es aber natürlich auch nicht…

Donnerstag, 28.2.2013: Livegang alpha.otto.de

Um 12:00 wurden die ersten paar tausend Einladungen an Kunden versendet, die ersten „echten“ Kunden trudeln ein: alpha.otto.de, ist live! Eine vollständig neu entwickelte Shop-Plattform, die ab Herbst die Grundlage für otto.de bilden wird.

Mit der Alpha Version wollen wir erste Erfahrungen in der freien Wildbahn sammeln, den Betrieb der Plattform üben und – vor allem – Feedback von Kunden für die Weiterentwicklung erhalten.