Was ich diese Woche gelernt habe (Woche 34/2013)

Jede Woche schreibe ich einen Blogbeitrag, der beschreibt, was ich in dieser Woche gelernt habe. Ich schreibe diese Blogbeiträge aus zwei Gründen.

Zuerst , ich möchte meine persönliche Entwicklung im Auge behalten, und das Schreiben regelmäßiger Blogbeiträge ist eine großartige Möglichkeit, dies zu tun.

Zweiter , ich möchte meine Erkenntnisse mit Ihnen teilen. Ich hoffe, dass Sie einige davon in Ihrer täglichen Arbeit verwenden können.

Fangen wir an und finden heraus, was ich in Woche 34 gelernt habe.

Was ich in Woche 34 gelernt habe

Zuerst , Ein E-Mail-Posteingang ist keine To-Do-Liste (dies gilt für Mobiltelefone, soziale Medien und andere Messaging-Tools). Ich las Making Ideas Happen von Scott Belsky, als mir dieser Satz auffiel (Seite 61):

Es wird jedoch fast unmöglich, langfristige Ziele zu verfolgen, wenn Sie sich nur von der neuesten E-Mail in Ihrem Posteingang oder dem Anruf eines Kunden leiten lassen.

Wenn Sie sowohl Wartungs- als auch Produktentwicklung betreiben, müssen Sie wissen, wie es sich anfühlt, eine E-Mail oder einen Anruf wegen eines URGENT zu erhalten Problem, das so schnell wie möglich gelöst werden muss . Es ist wirklich einfach, alles, was Sie tun, zu stoppen und mit der Arbeit an diesem Problem zu beginnen. Das ist oft ein Fehler .

Bevor Sie alles fallen lassen, was Sie tun, und die Strafe für den Kontextwechsel bezahlen, sollten Sie sich diese Frage stellen:

Ist das eine Katastrophe oder nur ein kleines Ärgernis?

Oft stellen Sie fest, dass das Problem überhaupt nicht dringend ist, und Sie können es beheben, nachdem Sie Ihre aktuelle Aufgabe abgeschlossen haben. Ihr erstes Ziel ist es, Kontextwechsel um jeden Preis zu vermeiden, weil Menschen nicht gut darin sind.

Zweiter , Verweile nicht. Gesetz! Ich habe festgestellt, dass ich mir manchmal Sorgen mache, dass die Korrektur unerwünschte Auswirkungen auf andere Teile der Anwendung haben könnte, wenn ich ein Problem oder einen Fehler in meinem Code beheben muss. Dieser Ansatz hat zwei Probleme:

1. Es verbraucht viel Energie (und kann viel Zeit in Anspruch nehmen).
2. Es hilft mir nicht, das Problem oder den Fehler zu beheben.

Es ist klar, dass Wohnen fruchtlos und unproduktiv ist. Da wir jedoch Menschen sind, neigen einige von uns sowieso dazu, zu verweilen. Ich habe festgestellt, dass ich dies vermeiden kann, indem ich diesen einfachen Schritten folge:

1. Erstellen Sie einen fehlgeschlagenen Testfall.
2. Beheben Sie das Problem. Sie wissen, dass Sie es behoben haben, wenn der fehlgeschlagene Testfall besteht.
3. Alle Tests ausführen.
4. Wenn alle Tests bestehen, sind Sie fertig.

Das funktioniert, weil es mir hilft, das Problem (oder den Fehler) in umsetzbare Schritte umzuwandeln und darauf zu vertrauen, dass meine Testsuite sicherstellt, dass mein Fix nichts kaputt macht. Wenn Sie keine Tests haben, lesen Sie Working Effectively with Legacy Code von Michael Feathers.

Dritter , können Sie mit JUnit parametrisierte Tests schreiben. Früher dachte ich, dass die Verwendung von TestNG die einzige Möglichkeit wäre, Parameter an meine Testmethoden zu übergeben. Diese Woche bin ich auf eine Bibliothek namens JUnitParams gestoßen. Wenn Sie parametrisierte Tests mit JUnit schreiben möchten, sollten Sie JUnitParams eine Chance geben.

Vierter , Die Bereitstellung für die Produktion sollte keine große Sache sein. Ich habe festgestellt, dass einige Leute denken, dass eine Bereitstellung in einer Produktionsumgebung eine so wichtige Aufgabe ist, dass jede Bereitstellung zu einem geplanten Datum erfolgen muss. Leider führt dies dazu, dass die Produktionsumgebung nicht sehr oft aktualisiert wird. Zwischen den Bereitstellungen können Monate (in manchen Fällen sogar Jahre) liegen.

Natürlich möchte niemand die Produktionsumgebung durcheinanderbringen. Deshalb müssen wir vorbereitet sein und jeden Einsatz sehr sorgfältig planen. Wir müssen sicherstellen, dass wir alle Situationen abgedeckt haben, bevor wir das Update durchführen können. Macht Sinn, oder?

FALSCH!

Wenn jemand die Produktionsumgebung stört, ist das eine gute Sache. Dies bedeutet, dass Ihr Bereitstellungsprozess fehlerhaft ist und Sie ihn beheben können.

Ich habe in dieser Woche zwei Bereitstellungen in der Produktionsumgebung durchgeführt. Ich hatte null Probleme. Ich hatte meine Zweifel bezüglich der kontinuierlichen Bereitstellung, aber diese Woche wurde mir klar, dass ich nie Probleme habe, wenn ich kleine Änderungen (eine Funktion, wenige Fehlerkorrekturen usw.) in der Produktionsumgebung bereitstelle.

Ich denke, das hat etwas damit zu tun, dass kleine Deployments nicht so viele bewegliche Teile haben wie die großen. Dadurch ist es einfacher, mehrere kleinere Bereitstellungen anstelle einer großen Bereitstellung durchzuführen.

Ich muss ein Geständnis ablegen. Ich habe diese Bereitstellungen manuell durchgeführt. Deshalb muss ich auf bewegliche Teile achten. Dies ist natürlich nicht der beste Weg, da es Raum für menschliche Fehler lässt. Das Gute ist, dass ich es immer besser machen kann.

Vielleicht habe ich Angst, dass Continuous Deployment funktionieren könnte, aber ich weiß, dass es an der Zeit ist, es herauszufinden.

Fünfter , Das Erstellen von Dummy-Daten kann einfach sein und Spaß machen. Ich hasse es, Dummy-Daten zu generieren. Es ist langweilig und umständlich. Sicher, ich kann Drehbücher schreiben, die mir die Arbeit abnehmen, aber ich habe immer noch das Gefühl, dass ich meine Zeit verschwende.

Diese Woche bin ich auf generateata.com gestoßen. Es ist ein Dienst, der Dummy-Daten generiert. Alles, was Sie tun müssen, ist

1. Geben Sie die Struktur der generierten Daten an.
2. Wählen Sie das bevorzugte Exportformat und geben Sie an, wie viele Zeilen Sie generieren möchten.
3. Klicken Sie auf die Schaltfläche Generieren.

Dieser Service ist eine Zeitersparnis! Probieren Sie es aus.

Was hast du diese Woche gelernt?

Teilen Sie Ihre Lernerfahrungen oder andere Kommentare im Kommentarbereich.