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

Was ich in Woche 39 gelernt habe

Zuerst , Integrationen sind schwierig. Jedes Mal, wenn ich den Satz hörte:„Diese Integration ist ziemlich einfach“, weiß ich, dass in 99 Prozent der Fälle der Sprecher keine Ahnung hat, wovon er spricht.

Obwohl es stimmt, dass einige Integrationen einfach und unkompliziert sein können, befinden Sie sich oft in einer Situation, in der eine „einfache Integration“ Wochen oder Monate gedauert hat, bevor sie richtig funktioniert.

Eines der größten Probleme ist, dass die Anforderungen an die Integration oft nur den glücklichen Weg abdecken. Wenn Sie dies nicht beachten, könnten Sie glauben, dass die Arbeit getan ist, wenn Sie alle Anforderungen implementiert haben.

Erraten Sie, was? Es ist einfach ein guter Anfang!

Die eigentliche Arbeit beginnt, wenn Sie mit dem Testen der Integration beginnen, oder so denken Sie. Ein weiteres Problem ist, dass man oft niemanden findet, der beide Systeme kennt und Zeit hat, die Integration zu testen. Oft bedeutet dies, dass nur der Happy Path getestet wird, bevor die Integration in der Produktion bereitgestellt wird.

Dann bricht die Hölle los.

Sie stellen fest, dass der glückliche Weg für 99 % der Anwendungsfälle gilt, aber es gibt immer Ausnahmen , und aus irgendeinem Grund hat niemand diese erwähnt, als Sie die Integration implementiert haben. Sie müssen diese Ausnahmen einzeln beheben. Es kann frustrierend sein, aber ich habe gelernt, damit zu rechnen.

Sie können Ihr Leben viel einfacher machen, indem Sie diese Regeln befolgen:

1. Geben Sie niemals ein Festpreisangebot / eine Arbeitsschätzung für eine Integration ab.
2. Gehen Sie niemals davon aus, dass die ursprünglichen Anforderungen die einzigen sind, die Sie implementieren müssen. Beginnen Sie zu graben und stellen Sie Fragen. Versuchen Sie, die Ausnahmen zu identifizieren, bevor Sie mit der Implementierung beginnen. Das macht Ihren Code viel sauberer.

Natürlich ist es unrealistisch zu erwarten, dass diese Regeln alle Integrationsprobleme lösen. Trotzdem habe ich sie in meiner täglichen Arbeit als nützlich empfunden.

Zweiter , Annahmen können gefährlich sein. Wenn ich an einer Aufgabe arbeite, folge ich jedes Mal den gleichen Schritten. Aus irgendeinem Grund bin ich davon ausgegangen, dass alle anderen auch die gleichen Schritte befolgen. Das ist natürlich ein bisschen narzisstisch, und letzte Woche habe ich gemerkt, dass das falsch war.

Letzte Woche habe ich an einer Sitzung teilgenommen, bei der alle Entwickler in Gruppen eingeteilt wurden und jede Gruppe die gleiche Liste von Szenarien bekam, die sie lösen mussten. Es war eine lehrreiche Erfahrung, weil ich bemerkte, dass verschiedene Gruppen unterschiedliche Lösungen für einige der Szenarien hatten. Als wir über die Lösungen diskutierten, wurde mir klar, dass ich vieles für selbstverständlich halte.

Diese Diskussion hat mir wirklich die Augen geöffnet.

Es ist offensichtlich, dass jeder Entwickler seine eigenen Routinen hat, die er in seiner täglichen Arbeit verwendet.

Es ist offensichtlich, dass verschiedene Personen unterschiedliche Wege haben, Probleme zu lösen.

Ich habe keine Ahnung, wie ich so dumm sein konnte, dass ich diese beiden Tatsachen vergessen hatte. Diese Erfahrung hat mich definitiv daran erinnert, wie wichtig offene Diskussionen sind.

Tappen Sie nicht in dieselbe Falle wie ich. Sprechen Sie mit Ihren Teammitgliedern . Fragen Sie, ob sie Ideen zur Verbesserung der Arbeitsweise haben.

Wenn ja, implementieren Sie sie .

Dritter , Es ist möglich, einen Ajax-ähnlichen Dateidownload zu implementieren. Letzte Woche musste ich eine Datei-Download-Funktion in eine Single-Page-Webanwendung implementieren. Anfangs habe ich mir die Haare ausgerissen, weil ich keine Ahnung hatte, wie ich das sauber umsetzen könnte. Dann fand ich ein jQuery-Plugin namens jQuery.fileDownload.

Es ist einfach zu bedienen und hat zwei großartige Funktionen:

• Sie können ein Popup anzeigen, wenn die angeforderte Datei heruntergeladen wird.
• Sie können mit Fehlern elegant umgehen.

Wenn Sie nach einer Möglichkeit suchen, eine Datei-Download-Funktion in einer Webanwendung zu implementieren, empfehle ich Ihnen, dieses jQuery-Plugin zu verwenden.

Vierter , Arbeitsschätzungen sind Vermutungen. Jedes Mal, wenn ich einen Arbeitsvoranschlag für etwas abgeben muss, läuft der Prozess folgendermaßen ab:

1. Ich lese und analysiere die Anforderungen.
2. Ich nehme an einer Besprechung teil, bei der ein Team die Anforderungen bespricht und Arbeitsschätzungen für jede Anforderung abgibt.

Dies scheint ziemlich einfach zu sein. Richtig?

Lass mich dir etwas erzählen. Die Arbeitsschätzungen werden unter Verwendung der Stetson-Harrison-Methode angegeben.

WIR RATEN!

Bedeutet das, dass wir keine Ahnung haben, wie lange es dauert, eine bestimmte Anforderung umzusetzen?

Nein. Wir haben oft eine ziemlich genaue Vorstellung davon, wie groß die Aufgabe ist (klein, mittel, groß). Das ist das Beste, was wir tun können. Das Lustige ist, dass Kunden oft Festpreisangebote wünschen, weil sie das finanzielle Risiko, das sie eingehen, reduzieren möchten.

Weißt du was?

Das funktioniert in beide Richtungen!

Auch der Subunternehmer will sein Risiko reduzieren. Aus diesem Grund ist ein Festpreisangebot oft teurer als ein Stundenpreis.

Schätzen ist sinnlos? Nein. Die Diskussionen sind oft sehr hilfreich .

HINWEIS :Wenn Sie mehr wissen möchten, empfehle ich Ihnen, zunächst diesen Blogbeitrag von Neil Killick zu lesen. Es ist der erste Aufsatz in einer Reihe von Aufsätzen, also denken Sie daran, auch den Rest der Reihe zu lesen.

Fünfter , Technologien sind keine Religionen. Sie sind nur Werkzeuge.

Die Leute, die mich kennen, wissen wahrscheinlich schon, dass ich neuen Technologien gegenüber eher konservativ eingestellt bin. Ich verwende keine neue Technologie, nur weil sie neu und cool ist. Ich benutze es nur, wenn es mein Leben einfacher machen kann .

Ich bin mir auch vollkommen bewusst, dass die meisten meiner Vorbehalte durch meine persönlichen Abwehrmechanismen verursacht werden. Mit anderen Worten, ich möchte in meiner Komfortzone bleiben. So zu fühlen ist menschlich, aber es ist wichtig zu verstehen, dass diese Abwehrmechanismen mich daran hindern könnten, objektive Entscheidungen zu treffen.

Ich habe dieses Problem gelöst, indem ich dieser Regel gefolgt bin:

Wenn sich eine Programmiersprache (oder Technologie) X beschissen anfühlt, muss ich sie ausprobieren!

Das gibt mir Erfahrungen aus erster Hand mit der Technologie und hilft mir, meine irrationalen Einwände zu überwinden. Natürlich fällt mir manchmal auf, dass die Programmiersprache (oder Technologie) X Mist ist. Das ist auch gut.

Diese Woche habe ich eine Diskussion gelesen, in der sich Entwickler darüber beschwert haben, dass es unmöglich ist, eine langfristige Karriere in der Softwareentwicklungsbranche aufzubauen, weil die Lebensdauer von Technologien zu kurz ist.

Ich stimme diesen Leuten zu. Ich stimme zu, dass jemand, der nur die Technologie X oder die Syntax der Programmiersprache Y beherrschen möchte, wahrscheinlich keine Software schreiben sollte, um seinen Lebensunterhalt zu verdienen.

Diese Leute sollten einen richtigen Job bekommen.

Was hast du diese Woche gelernt?

Teilen Sie Ihre Lernerfahrungen oder andere Kommentare im Kommentarbereich.