Tag Archives: Software Craftsmanship

Hypothesis-Driven Development

tl;dr

Ein gutes Werkzeug um Personen und Organisationen in der Softwareentwicklung (Teams, Management, etc) effektiver zu machen, ist sich auf die Dinge zu konzentrieren, die am meisten Wert für den Kunden haben. Um schnell Feedback zu bekommen etabliert man Continuous Delivery und damit man besser mit Unsicherheit umgehen kann hilft Hypothesis-Driven Development.

Man formuliert die Hypothesen nach folgendem Muster (Siehe auch: Quellen unten):

Wir glauben das <wenn wir diese Funktion bauen> 
für
<diese Personen>
liefert es  
<dieses Ergebnis>
Wir haben das Vertrauen fortzufahren, wenn wir (bis <Datum>) folgendes <messbare Signal sehen>.

Continue reading

Test-Säulen und Test-Treppe (Test-Pillars and Test-Stairs)

Wer sich mit Continuous Delivery und Testen auseinandersetzt kommt früher oder später an der Testpyramide vorbei. Die Mehrheit aller Tests sind Unit Test’s, darauf aufbauend wird auf Stufe Komponenten oder Services getestet und ganz oben auf der Pyramide wird die Gesamtheit des Systems getestet. Nach oben wird die Anzahl der Tests kleiner.

In diesem Artikel möchte ich einen Weg beschreiben, bei dem die Tests der oberen Stufen auch in den Tests der unteren Stufen ausgeführt werden und um weitere Tests auf jeder Stufe ergänzt werden. Das Ergebnis ist eher eine Stufenpyramide und das Vorgehen führt erstaunlich einfach an Domain Driven Design heran. Continue reading

Veränderungen

in letzter Zeit gab es bei mir einige Veränderungen. Angefangen hat es damit, dass ich überlegt habe, was ich wohl in nächster Zeit gern machen würde.

Über die Jahre habe ich von Programmierung, über Projektmanagement und Teamleitung bis hin zur Infrastruktur in vielen Bereich gearbeitet, mich weitergebildet und Erfahrungen gesammelt. Mich interessiert die Softwareentwicklung und ich bin froh, diesem Interesse auch beruflich nachgehen zu können. Insbesondere faszinieren mich die kleinen Dinge. Bausteine die je nach Problemstellung flexibel zusammengesetzt werden können Dazu gehören natürlich die Grundlagen der Softwareentwicklung (Test Driven Development, Software Craftsmanship) auch moderne methodische Ansätze (agile, lean, Domain Driven Design, Continuous Delivery), kleine Tools (vert.x, Ratpack, Spring BootGradle – ich benutze meist Java/JVM) und offene Herangehensweisen. Im Kern geht es mir darum, die Geschwindigkeit bei der Umsetzung zu erhöhen, ohne das wirklich Stress entsteht. Deshalb halte ich den Zeitpunkt für wichtig, wann etwas gemacht wird. Auch schnelle Iterationen über Ideen und nicht erst über die Umsetzung halte ich für zielführend.  Damit verbunden ist eine enge Zusammenarbeit von Fachbereich,  Entwicklungsabteilung und möglichst auch des Benutzers. Die schnelle Verifikation dieser Ideen ist wichtig – möglichst im Tagesrhythmus,  wenn nicht gar schneller –  um den wirklichen Nutzen eines Produktes zu finden. Interdisziplinäre Teams (Business/Development/Operating/QA  – vielleicht BusDevOps 🙂 ) sind dafür äusserst hilfreich.

Seit einigen Jahren halte ich nun Vorträge (Docker, Microservices, Component Management) und gebe Workshops (Coderetreat, Continuous Delivery). Ich engagiere mich in der Entwicklergemeinschaft und bin Präsident der Java User Group Switzerland geworden. Meine Frau und ich haben zusammen die Weiterbildungstagung “Open Source an Schulen 2015” organisiert. Zusammen mit Geza (aka @infinitary)  bereite ich den  SoCraTes Day Switzerland vor.

Der grösste Schritt war aber sicherlich, mich selbstständig zu machen: 2015 habe ich die Nautsch Gmbh gegründet. Wir sind interessiert an Kunden, die mit uns in einem partnerschaftlichen Verhältnis an Lösungen erarbeiten möchten und dabei an neuen Sichtweisen interessiert sind. Die Grösse des Unternehmens spielt eine untergeordnete Rolle. Ich persönlich habe Erfahrungen sowohl im Start-Up Umfeld als auch in sehr grossen Unternehmen gesammelt. Wenn Sie also einen Partner für die Umsetzung einer Idee suchen, intern ein Team aufbauen wollen und einen Trainer suchen, oder einfach technische Unterstützung benötigen,  helfe ich gern weiter! Sie erreichen mich am besten per E-Mail:

info@nautsch.com

Understanding JavaScript via TDD

I got interested in JavaScript via the book “Seven Languages in Seven Weeks” by Bruce Tate. I read it one year ago. The chapter about the prototyping nature of the language “Io” was an eye opener. The book itself is worth to write about – but not today.

As every developer I used JavaScript a little bit. But really understanding whats going on is definitely another thing. The last weeks I wrote a little shopping list as a client for my vert.x experiments. It is a single page app and uses knockout.js, jquery and bootstrap for the UI. I use Java as my general purpose programming language since 1997 and I think I know Java quite well. So, I was a little bit frustrated that I don’t understand every construct in JavaScript. After playing with some frameworks and CoffeeScript I decided to build up a comparable Test Driven Environment as I use when I developing in Java. I wanted to use a xUnit like test framework. But there are so many test frameworks that it was difficult to decide which one to use. After looking at several post and at stackoverflow I got the feeling that js-test-driver or QUnit are good candidates.

Then I found this really good book: “Test-Driven JavaScript Development” by Christian Johansen. Christian uses js-test-driver in his book. The main goal for js-test-driver is to be the runner for the tests. It has also assertions but I wanted to have more readable tests. I heard about Jasmine and a friend (thanks to Patric) also mentioned it. The integration was done in 10 minutes and the tests are better to read now. I really like this BDD style.

After a while I thought about a better way to connect a browser to the driver. I didn’t want to start a browser every time and press the connect link because I’m writing “Understand Tests” mostly.  Robert C. Martin describes this kind of tests in his book “Clean Code“. These tests are very handy to understand a framework, a library or as in my case also language features. I wanted to start the js-test-driver together with something like a headless browser. PhantomJS is such a thing. js-test-driver-phantomjs starts the driver and the headless browser with one simple command. This setup is also very useful for Continuous Integration! Intellij IDEA has also a nice plugin for js-test-driver.

Of course, I can write a test in the console of some browser, but if I close the browser the tests are gone. The tests are inside my project now and I can look at the tests as often as I like. And testing the JavaScript-part of my application works the same way as I know it from the Java-World.