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

Hinweis: Ich werde am kommenden Sonntag kein neues Lerntagebuch veröffentlichen, da ich in den Weihnachtsferien bin. Ich wünsche Ihnen allen frohe Weihnachten (oder schöne Feiertage, wenn Sie Weihnachten nicht feiern) und ein gutes neues Jahr!

Was ich in Woche 51 gelernt habe

Zuerst , Richtige Fehlerbehandlung implementieren.

Manchmal, wenn wir ein Feature implementieren, schenken wir der Fehlerbehandlung nicht genug Aufmerksamkeit. Das ist ein leichter Fehler, weil es irgendwie natürlich ist, zuerst über den glücklichen Weg nachzudenken.

Ist das nicht schließlich das, was unser Kunde will?

Nein. Das ist es nicht. Unser Kunde möchte, dass wir ein funktionierendes Feature liefern, das über eine ordnungsgemäße Fehlerbehandlung verfügt.

Was ist dann die richtige Fehlerbehandlung? Das hängt von der Anwendung ab, aber ich bin mir ziemlich sicher, dass das Anzeigen einer allgemeinen Fehlermeldung für jeden möglichen Fehler nicht das ist, was eine angemessene Fehlerbehandlung bedeutet.

Natürlich gibt es Situationen, in denen wir keine andere Wahl haben, als eine allgemeine Fehlermeldung anzuzeigen, aber wir sollten auch verstehen, dass diese Fehler sehr selten sind. Meistens können (und sollten) wir eine entsprechende Fehlermeldung anzeigen, die das eigentliche Problem beschreibt.

Wenn wir erst dann über die Fehlerbehandlung nachdenken, wenn wir begonnen haben, Funktionen zu unserer Anwendung hinzuzufügen, sind wir wahrscheinlich schon zu spät. Wir hätten einen gemeinsamen Fehlerbehandlungsmechanismus entwerfen sollen, der in unserer gesamten Anwendung verwendet wird.

Dies gewährleistet eine konsistente Benutzererfahrung, und was noch wichtiger ist:

Es spart uns Zeit (und Nerven), weil wir nicht jedes Mal unsere Protokolldateien untersuchen müssen, wenn ein Benutzer unsere allgemeine Fehlermeldung sieht.

Zweiter , Demontiere immer.

Wenn Sie agile Softwareentwicklungsmethoden verwenden, ist Ihnen wahrscheinlich bekannt, dass Sie am Ende eines Sprints in einem Sprint-Review-Meeting zusammenkommen, um zu zeigen, was Sie während des Sprints getan haben.

Wenn Sie dem Product Owner die neuen Funktionen zum ersten Mal vorführen, entscheidet der Product Owner manchmal, dass er mit dem Ergebnis nicht zufrieden ist. Dies bedeutet, dass einige Änderungen vorgenommen oder sogar einige Funktionen (oder Funktionen) neu geschrieben werden müssen. Mit anderen Worten:Anstatt einen Mehrwert zu schaffen, haben Sie Verschwendung hinzugefügt.

Soll Agilität so funktionieren?

Nein. Ich denke, dass eines der Grundprinzipien der agilen Softwareentwicklung darin besteht, Verschwendung zu minimieren.

Der beste Weg, dies zu tun, ist, dem Product Owner die neue Funktion so schnell wie möglich zu zeigen und um Feedback zu bitten. Wenn Sie auf dem richtigen Weg sind, können Sie weitermachen. Wenn der Product Owner jedoch sieht, dass etwas geändert werden muss, können Sie diese Änderung sofort vornehmen, wenn es einfach und schnell geht.

Wenn Sie dies regelmäßig tun, werden Sie feststellen, dass die Anzahl der Änderungen, die nach einem Frühjahrs-Review-Meeting vorgenommen werden, abnimmt, da die meisten Änderungen während des Sprints vorgenommen wurden. Das bedeutet, dass Sie die während des Sprints hinzugefügte Abfallmenge erfolgreich reduziert haben.

Herzlichen Glückwunsch.

Dritter , Sie sind ein Experte. Benimm dich so.

Seien Sie nicht der Typ/die Frau, die Angst davor hat, Ihrem Kunden das Wort nein zu sagen. Und wenn Sie diese Person sind, denken Sie über Folgendes nach:

Wenn Sie nur das tun, worum Ihr Kunde Sie bittet, sind Sie sehr leicht zu ersetzen. Es gibt viele Entwickler da draußen, die dasselbe billiger machen können als Sie.

Natürlich kann man immer denken, dass man nicht ersetzt werden kann, weil man guten Code schreibt. Wenn Sie so denken, habe ich Neuigkeiten für Sie:

Jeder Entwickler denkt, dass sein Code etwas Besonderes ist.

Sind Sie wirklich sicher, dass Ihr Code speziell genug ist?

Sind Sie sicher, dass Ihr Kunde guten Code mehr schätzt als einen günstigeren Preis?

Es gibt einen "einfachen" Weg, sich schwerer ersetzbar zu machen. Sie können beginnen, indem Sie diese Regeln befolgen:

• Wenn Sie der Meinung sind, dass es eine Möglichkeit gibt, die Verwendung einer Funktion zu vereinfachen, melden Sie sich.
• Wenn Sie der Meinung sind, dass nicht alle erforderlichen Funktionen benötigt werden, melden Sie sich.
• Wenn Sie der Meinung sind, dass der Anwendung wichtige Funktionen fehlen, melden Sie sich.

Sei nicht nur ein Programmierer.

Wenn Sie Ihrem Kunden helfen, das bestmögliche Produkt zu schaffen, sind Sie kein austauschbares Rädchen mehr. Sie sind jetzt ein wertvolles Mitglied des Produktentwicklungsteams.

Vierter , Jeder ist irgendwann ein Neuling.

Da ich einen technischen Blog schreibe, bekomme ich viele Fragen, die man als „Anfängerfragen“ kategorisieren könnte. Ich werde jeden von ihnen beantworten, aber natürlich muss ich manchmal einiges erledigen.

Warum mache ich das?

Ich tue es nicht, weil ich ein Heiliger bin. Es gibt Zeiten, in denen ich sehr frustriert bin, wenn ich eine "Neulingsfrage" sehe. Es ist normal. Schließlich bin ich nur ein Mensch.

Der Grund, warum ich das mache, ist, dass ich mich noch daran erinnere, wie es war, Programmieren ohne Internet zu lernen.

Es war schwer. Es war so hart, dass ich es nicht geschafft habe, alle meine Probleme zu lösen. Ich habe entweder eine Problemumgehung gefunden oder meine Idee aufgegeben. Das ist "normal", wenn Sie nicht über die erforderlichen Fähigkeiten verfügen, um Ihre Ideen in die Realität umzusetzen.

Vor ein paar Jahren bemerkte ich die Begeisterung für Rockstar-Entwickler. Ein Rockstar-Entwickler ist ein Übermensch, der hundertmal schneller als ein Normalsterblicher Code schreiben und Probleme lösen kann, die unmöglich zu lösen scheinen.

Ich glaube nicht an diesen Bullshit.

Ich schätze Zusammenarbeit und Lernen mehr als Märchen über Superhelden, die ein zum Scheitern verurteiltes Softwareprojekt im Alleingang retten können.

Ich glaube, dass jeder große Softwareentwickler erkennt, dass die Leute, die "Neulingsfragen" stellen, nicht dumm sind. Sie stellen Fragen, weil sie versuchen zu lernen, und es liegt in unserer Verantwortung, unser Wissen weiterzugeben.

Haben wir nicht schließlich von anderen Entwicklern gelernt, die bereit waren, ihr Wissen mit uns zu teilen?

Fünfter , Gut geplant ist noch lange nicht getan.

Wir haben hier in Finnland ein Sprichwort, das so lautet:

Gut geplant ist halb gemacht

Ich stimme dem nicht zu. Obwohl es viele Bereiche im Leben gibt, in denen eine angemessene Planung erforderlich ist, um Katastrophen zu verhindern, gehört die Softwareentwicklung nicht dazu.

Bei der Softwareentwicklung besteht das Ziel der "richtigen" Planung darin, das Unbekannte zu eliminieren, bevor irgendein Code geschrieben wird. Das ist eine unmögliche Aufgabe und vielleicht sind deshalb alle Projekte, die mit einer Vorausplanung beginnen, sehr, sehr SEHR TEUER .

Denken wir über die Phasen eines imaginären Softwareprojekts nach:

1. Du musst einen perfekten Plan erstellen. Da es sehr schwierig ist, alles zu berücksichtigen, kostet die Erstellung des Plans viel Zeit und Geld.
2. Sie müssen die Software implementieren, indem Sie Ihrem perfekten Plan folgen. Das Problem ist, dass Sie, weil Sie während der Planungsphase nicht alles berücksichtigen können, ein bürokratisches Change-Management-Verfahren (und ein Change-Management-Budget) haben müssen. Auch hier verbrennt man viel Zeit und Geld.
3. Wenn die Software fertig ist, merkt man, dass sich die Anforderungen geändert haben und man neu planen muss.

Ich sage nicht, dass Planung nicht sinnvoll ist, aber man sollte es auch nicht übertreiben. Wenn Sie sich nicht sicher sind, wann eine Planung sinnvoll ist, befolgen Sie diese „Regeln“:

• Wer nur plant, weil er einen schriftlichen Plan schreiben muss, bewegt sich auf dünnem Eis. Planung ist sinnvoll. Pläne sind es nicht.
• Wenn Sie nicht beschreiben können, warum Sie planen, ohne Fachjargon zu sprechen (auch bekannt als Bullshit ), fügen Sie Verschwendung hinzu. HÖREN SIE AUF, ES ZU TUN!

Was hast du diese Woche gelernt?

Teilen Sie Ihre Lernerfahrungen oder andere Kommentare im Kommentarbereich.