Was ich diese Woche gelernt habe (Woche 49/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.

Zweite , 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 49 gelernt habe.

Hinweis: Diese Woche mache ich nur vier Punkte, weil wir am Freitag unseren Unabhängigkeitstag gefeiert haben.

Was ich in Woche 49 gelernt habe

Zuerst , TDD stellt sicher, dass Sie daran denken, alle Anforderungen zu implementieren.

Ich habe einen Blogbeitrag geschrieben, in dem es um TDD und Webanwendungen geht. Diese Woche ist mir aufgefallen, dass ich nicht immer praktiziere, was ich predige.

Manchmal "vergesse" ich TDD zu verwenden und falle auf meine alte Praxis zurück (zuerst Code schreiben und danach testen). Diese Woche habe ich genau das getan.

Rate, was passiert ist? Eine Anforderung hätte ich fast vergessen!

Glücklicherweise erinnerte ich mich an diese Anforderung, bevor der Code für die Produktion bereitgestellt wurde, aber ich bin mir ziemlich sicher, dass dies nicht passiert wäre, wenn ich TDD verwendet hätte.

Die Idee von TDD ist, dass Sie wirklich überlegen müssen, was Sie implementieren müssen, bevor Sie Code schreiben . Ich habe das nicht getan. Stattdessen habe ich mich entschieden, auf Autopilot zu programmieren, und habe einen Fehler gemacht.

Dieses Mal hat es mir nicht geschadet, weil das implementierte Feature so einfach war, dass ich keine großen Änderungen an meinem Code vornehmen musste. Das Hinzufügen der fehlenden Anforderung ging also recht schnell.

Das ist nicht immer der Fall .

Es ist klar, dass ich in Zukunft disziplinierter sein muss. Vielleicht sollte ich neben meinem Bildschirm eine Haftnotiz anbringen, damit ich daran denke, Tests zu schreiben, bevor ich den Code schreibe.

Zweite , Es ist nicht immer ratsam zu automatisieren.

Ich hasse es, Arbeit zu erledigen, die automatisiert werden könnte. Das Problem ist, dass es nicht ratsam ist, alles zu automatisieren. Betrachten wir das folgende Beispiel:

• Wir haben eine Aufgabe, die zwei Stunden dauert, und wir müssen sie einmal im Jahr erledigen.
• Einen Code zu schreiben, der dasselbe tut, würde zwei Tage (18 Stunden) dauern.

Wenn ich diese Arbeit manuell mache, kostet es meinen Kunden doppelt so viel. Wenn ich diese Aufgabe automatisieren würde, würde es meinen Kunden das 18-fache kosten. Mit anderen Worten, mein Kunde würde im zehnten Jahr Geld sparen. Die Automatisierung dieser Aufgabe ist sinnvoll, wenn die Lebensdauer der Software länger als neun Jahre ist.

Wenn dies nicht der Fall ist, automatisieren Sie es nicht.

Ihre Aufgabe ist es nicht, Ihren Kunden abzuzocken. Ihre Aufgabe ist es, den Wert, den Sie Ihren Kunden bieten, zu maximieren.

Dritter , #NoEstimates zielt darauf ab, einen Mehrwert zu schaffen.

Diese Woche habe ich zwei Blogbeiträge gelesen, in denen es um #NoEstimates und Budgetierung ging. Diese Blogbeiträge sind:

• Verwenden Sie #NoEstimates, um Optionen zu schaffen und zuverlässig Wert zu liefern
• Können wir lernen, unsere Arbeit auf ein Budget zu beschränken?

Mir ist aufgefallen, dass es einen entscheidenden Unterschied zwischen #NoEstimates und dem traditionellen Festpreisangebot gibt, das auf Arbeitsschätzungen basiert:

#NoEstimates zielt darauf ab, den Wert des Kunden zu maximieren. Der traditionelle Ansatz ist ein Budgetierungstool und sein Ziel ist es, die Kosten eines Softwareprojekts zu minimieren.

Das größte Problem, das ich mit #NoEstimates hatte, war, dass ich keine Ahnung hatte, wie ich dem Kunden gegenüber argumentieren könnte, dass Festpreisangebote, die auf Arbeitsschätzungen basieren, schädlich sind. Ich frage mich, was Kunden antworten würden, wenn ich ihnen diese Frage stellen würde:

Möchten Sie Ihr Budget minimieren oder den Wert maximieren, den wir Ihnen liefern?

Die Antwort auf diese Frage erscheint mir wie ein Kinderspiel, aber meine Erfahrung hat mich gelehrt, dass ich vielleicht eine Antwort bekomme:

Beide

Schade, dass es so einfach nicht funktioniert.

Vierter , Wartung ist ein großartiger Entwickler.

Wartung ist nicht sexy und wird als viel weniger spaßig angesehen als die Arbeit in einem Greenfield-Projekt. Um ehrlich zu sein, hat die Softwarewartung einen wirklich schlechten Ruf. Es wird als unkreative und langweilige Grunzerarbeit angesehen, und deshalb machen es „die besten Entwickler“ des Unternehmens oft nicht.

Das ist schade, denn ich finde, wenn man ein großartiger Softwareentwickler werden will, muss man Wartungsarbeiten machen! Ich denke so, denn wenn Sie Wartungsarbeiten durchführen,

• Du musst mit den Entscheidungen leben, die du in der Vergangenheit getroffen hast. Wenn Sie schlechte Entscheidungen getroffen haben, werden Sie den Schmerz erfahren, der durch Ihre Entscheidungen verursacht wird.
• Du lernst, wie man bestehenden Code ändert, ohne ihn in einen nicht mehr wartbaren Scheißhaufen zu verwandeln. Wenn Sie Ad-hoc-Lösungen treffen, ohne über die Konsequenzen Ihrer Entscheidungen nachzudenken, werden Sie später den Schmerz spüren, der durch diese Entscheidungen verursacht wird.
• Du wirst lernen, geduldig zu sein. Software-Wartung ist kein Hundert-Meter-Lauf. Es gleicht eher einem Marathon. Wenn Sie es beenden wollen, müssen Sie Entscheidungen treffen, die langfristig von Vorteil sind.

Die Softwarewartung ist eine äußerst wichtige und wertvolle Aufgabe, da die gewartete Software eines der wichtigsten Vermögenswerte Ihres Kunden ist und der Großteil der Lebenszykluskosten der Software in der Wartungsphase aufgewendet wird.

Ein Wartungsentwickler ist nicht „nur“ ein Wartungsentwickler. Er hat eine große Verantwortung und die Möglichkeit, nützliche Fähigkeiten zu erlernen.

Schlagen Sie diese Gelegenheit nicht aus, nur weil Sie der Meinung sind, dass Sie zu gut für die Softwarewartung sind. Du bist nicht .

Was hast du diese Woche gelernt?

Teilen Sie Ihre Lernerfahrungen oder andere Kommentare im Kommentarbereich.