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

Was ich in Woche 40 gelernt habe

Zuerst , Issue Tracker kann als Spezifikationstool verwendet werden.

Ich habe bereits darüber geschrieben, dass E-Mails keine gute Möglichkeit sind, Informationen auszutauschen. Damals schlug ich vor, dass wir mithilfe eines Wikis eine FAQ erstellen sollten. Obwohl dies eine gute Möglichkeit ist, Informationen auszutauschen, besteht das Problem darin, dass diese FAQ-Einträge geschrieben werden, nachdem die Software implementiert wurde. Dies verursacht ein weiteres Problem.

FAQs sind eine großartige Möglichkeit, um zu beschreiben, wie die Software funktioniert und wie sie erstellt wurde. Das Problem ist, dass häufig gestellte Fragen oft nicht auf die interessanteste Frage antworten:

Warum ist die Software so aufgebaut?

Früher habe ich in einem Projekt gearbeitet, wo wir zwei Regeln hatten:

1. Für jede Aufgabe wurde ein neues Jira-Problem erstellt. Die Spezifikation der Aufgabe wurde in die Beschreibung des Problems geschrieben.
2. Alle Diskussionen zu dieser Aufgabe mussten in Jira stattfinden.

Damals kam mir das etwas zu bürokratisch vor, und ich hörte mit dieser Praxis auf, als ich anfing, für ein anderes Unternehmen zu arbeiten.

Das war ein Fehler!

Diese Woche habe ich festgestellt, dass das Halten der Diskussion an einem Ort (Jira-Problem) die folgenden Vorteile hat:

• Wenn wir weitere Informationen zu einer bestimmten Funktion benötigen, wissen wir, dass wir sie im Issue Tracker finden können. Wir müssen uns nicht auf die Erinnerungen des Entwicklers verlassen, der es implementiert hat. Wir müssen keine Informationen aus unseren Posteingängen suchen. Das kann uns viel Frust ersparen.
• Wenn wir unserer Wiki-Dokumentation Links zu den relevanten Jira-Problemen hinzufügen, können wir eine bessere Dokumentation erstellen, die beschreibt, wie eine Funktion implementiert wird und warum sie auf diese Weise implementiert wurde.

Das klingt ziemlich gut. Richtig?

Zweiter , HR kann nützlich sein. Diese Woche hatte ich eine 1-2-1-Diskussion, in der wir über meine Träume in Bezug auf die Softwareentwicklung diskutierten. Ich weiß, das klingt nach typischem HR-Bullshit und vor meiner 1-2-1-Diskussion hätte ich wahrscheinlich genauso gedacht.

Allerdings habe ich dieses Mal eine ganz andere Erfahrung gemacht. Als das Gespräch vorbei war, fühlte ich mich energiegeladen und motiviert. Das war ein bisschen seltsam, denn normalerweise waren diese Diskussionen nett, aber sie haben nicht wirklich etwas geändert.

Ich verbrachte einige Zeit damit und stellte fest, dass diese 1-2-1-Diskussion aus zwei Gründen nützlich war:

1. Ich habe meinen Traum vor dem Treffen beschrieben. Ich musste keine Vorlage verwenden und die einzige Einschränkung war, dass ich die Beschreibung vor dem Meeting an meinen Teamleiter zurückgeben musste.
2. Während des Treffens haben wir die beiden wichtigsten Dinge auf meiner Liste ausgewählt, die ersten Schritte identifiziert, die mir helfen, meinen Traum zu verwirklichen, und eine Frist für diese Schritte festgelegt.

Also, was können Sie aus meiner Erfahrung lernen? Ich werde diese Frage mit einer anderen Frage beantworten.

Wann haben Sie das letzte Mal über Ihren Traum nachgedacht?

Wenn Sie dies noch nie getan haben, denken Sie einige Zeit darüber nach und schreiben Sie Ihre Gedanken auf ein Blatt Papier. Sie werden überrascht sein, was Sie lernen werden, wenn Sie nur diese einfache Übung machen.

Aber hören Sie hier nicht auf. Identifizieren Sie die Schritte, die Ihnen helfen, Ihren Traum Wirklichkeit werden zu lassen, und legen Sie für jeden Schritt eine Frist fest.

Und dann… können Sie Ihre Träume wahr werden lassen.

Dritter , Das Schreiben von Informationen in eine Protokolldatei reicht nicht aus. Diese Informationen müssen wir auch auswerten können.

Ich weiß, dass Sie mit standardmäßigen *nix-Befehlszeilentools viel erreichen können, aber ich bin kein großer Fan dieses Ansatzes. Diese Tools eignen sich gut zum Suchen von Informationen in den Protokolldateien, wenn Sie ein Problem lösen oder nach einem Fehler in Ihrem Code suchen.

Das Problem ist, dass Protokolldateien viele nützliche Informationen enthalten und die Analyse dieser Informationen in vielerlei Hinsicht von Vorteil ist. Zum Beispiel können wir

• Finden Sie heraus, wie oft bestimmte Funktionen unserer Anwendung verwendet werden.
• Finden Sie heraus, welches die häufigste Ausnahme ist, die von unserer Anwendung ausgelöst wird.
• Sammeln Sie Statistiken über die Antwortzeit unserer Anwendung.

Grundsätzlich können wir alles analysieren, was in den Logfiles gefunden wird, und das Gute daran ist, dass wir das nicht von Grund auf neu implementieren müssen. Zu diesem Zweck können wir eines der folgenden Tools verwenden:

• Splunk Light ist ein Dienst, mit dem Sie die in Ihre Protokolldateien geschriebenen Informationen analysieren und visualisieren können.
• Logstash ist ein Open-Source-Tool zum Verwalten von Ereignissen und Protokollen. Sie können ziemlich tolle Sachen damit machen, wenn Sie es mit ElasticSearch kombinieren.

Wenn Sie eine Idee haben, welche Art von Informationen ich aus meinen Protokolldateien sammeln sollte, hinterlassen Sie bitte einen Kommentar zu diesem Blogbeitrag!

Vierter , Open Source hat auch technische Schulden. Diese Woche bin ich auf einen Blogbeitrag mit dem Titel Don’t Let Somebody Else’s Technical Debt Take You Under gestoßen. Es hat mich wirklich dazu gebracht, über meine Einstellung zu technischen Schulden nachzudenken.

Ich bin besessen von technischen Schulden. Das Problem ist, dass ich von meinen eigenen technischen Schulden besessen bin . Ich muss gestehen, dass ich den technischen Schulden von Open-Source-Bibliotheken und -Frameworks, die in meinen Projekten verwendet werden, nicht viel Aufmerksamkeit geschenkt habe. Jim Bird half mir zu erkennen, dass dies unverantwortlich ist. Außerdem gibt er gute Tipps, wie man dieses Problem lösen oder vermeiden kann.

Hier ist mein Tipp:

Wenn Sie Maven verwenden, können Sie das Versions Maven-Plugin verwenden, um herauszufinden, für welche Abhängigkeiten oder Plugins neuere Versionen verfügbar sind. Führen Sie das Plugin einmal pro Woche aus und aktualisieren Sie die veralteten Abhängigkeiten und Plugins. Ich weiß, das klingt nicht nach viel, aber es ist ein guter Anfang .

Fünfter , Die Zeit der eigenständigen Diagrammeditoren ist vorbei. Diese Woche habe ich mit einer Aufgabe begonnen, die wohl allen Softwareentwicklern recht vertraut ist. Ich wollte einen preiswerten Diagrammeditor für OS X finden. Obwohl ich ein paar ziemlich gute Optionen gefunden habe (eine davon war Diagrammix), wurde mir klar, dass es auch viele webbasierte Alternativen gibt (Danke an alle, die ihre Meinung unter Facebook).

Diese Alternativen sind:

• Kreativ
• Gliffy
• Lucidchart

Als ich diese Anwendungen evaluierte, stellte ich fest, dass sie alle die Funktionen haben, die ich brauche. Mit anderen Worten, anstatt eigenständige Anwendungen zu bewerten, habe ich über diese Frage nachgedacht:

Hat eine eigenständige Anwendung Vorteile gegenüber einer webbasierten Anwendung?

Der einzige "Vorteil", den ich herausfinden konnte, war, dass eine eigenständige Anwendung möglicherweise eine bessere Benutzeroberfläche hat als eine webbasierte Anwendung.

War das genug für mich? Nein. Ich habe mich letztendlich aus zwei Gründen für Creately entschieden:

1. Die Benutzeroberfläche ist wirklich einfach.
2. Ihre Preise sind wirklich attraktiv und der persönliche Plan hat die gleichen Funktionen wie die anderen Pläne (mit Ausnahme der Teamverwaltung natürlich).

Es war interessant zu sehen, dass Cloud-basierte Anwendungen immer besser werden. Ich bin gespannt, wann ich das erste brauchbare sehen werde Cloud-basierte IDE (die IntelliJ-Idee hat die Messlatte für mich ziemlich hoch gelegt).

Was hast du diese Woche gelernt?

Teilen Sie Ihre Lernerfahrungen oder andere Kommentare im Kommentarbereich.