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

Was ich in Woche 45 gelernt habe

Zuerst , Ein guter Prozess muss Ihre Arbeit erleichtern und/oder beschleunigen.

Ich bin kein großer Fan der Textverarbeitung, weil sie viele schlechte Erinnerungen weckt. Wenn ich dieses Wort höre, verbinde ich es sofort mit etwas, das meine Arbeit schwerer oder/und langsamer macht.

Und doch verstehe ich, dass ein Team nur funktionieren kann, wenn alle seine Mitglieder demselben Arbeitsablauf folgen (ich denke, man kann das einen Prozess nennen).

Ein schlechter Prozess und ein guter Prozess haben jedoch einen entscheidenden Unterschied:

Schlechte Prozesse werden von Managern erfunden. Gute Prozesse werden im Team vereinbart.

Ein guter Prozess hat ein und nur ein Ziel:Er muss Sie einfacher und/oder schneller machen. Wenn der aktuelle Prozess dies nicht tut, ist er defekt und muss repariert werden. Das Problem ist, dass Sie, wenn Ihr aktueller Prozess von Ihren Managern erfunden wurde, eine Null-Prozent-Chance haben, ihn bald zu ändern.

Vielleicht haben deshalb so viele Unternehmen zwei Prozesse:den offiziellen Prozess und die Art und Weise, wie die Dinge wirklich erledigt werden. Das ergibt keinen Sinn .

Dies ist eine Nachricht an alle Manager da draußen:

Lassen Sie Ihr Team entscheiden, wie es seine Arbeit erledigen möchte. Sie können (und sollten wahrscheinlich auch) die Ziele festlegen, die erreicht werden müssen, aber wenn Sie möchten, dass sich Ihre Teammitglieder dazu verpflichten, diese Ziele zu erreichen, können Sie nicht vorschreiben, wie die eigentliche Arbeit erledigt werden soll.

Zweiter , Das Erstellen von Berichten aus der Betriebsdatenbank ist eine schreckliche Idee.

Wenn Ihre Berichte so einfach sind, dass Sie Daten aus mehreren Tabellen nicht kombinieren und komplexe Berechnungen durchführen müssen, ist es oft am besten, die Daten aus der Betriebsdatenbank abzurufen. Das Problem besteht darin, dass Sie nach der Implementierung dieser einfachen Berichte möglicherweise neue und komplexere Berichte implementieren müssen.

Was sollten Sie tun?

Ich verstehe, dass es schwierig sein kann, Ihren Chef oder Ihren Kunden davon zu überzeugen, Ihnen die Erlaubnis zu erteilen, eine separate Berichtsdatenbank zu erstellen. Es erfordert viel Arbeit, da Sie die Berichtsdatenbank entwerfen, Routinen erstellen müssen, die Daten aus der Betriebsdatenbank in die Berichtsdatenbank umwandeln, die aktuellen Berichte umschreiben und die neuen Berichte implementieren.

Trotzdem muss es getan werden .

Denken Sie daran

• Die Betriebsdatenbank ist normalisiert, um Redundanz zu minimieren.
• Die Berichtsdatenbank ist denormalisiert, um die beste Leistung für die Berichterstellung bereitzustellen.

Möglicherweise können Sie die erforderlichen Berichte für die Betriebsdatenbank für eine Weile implementieren. Wenn jedoch die Datenmenge wächst und/oder Ihre Berichte komplexer werden, wird die Generierung dieser Berichte immer langsamer.

Irgendwann stehen Sie vor einer Situation, in der Sie alles optimiert haben und die Berichte immer noch zu langsam sind. Ihnen ist klar, dass die einzige Möglichkeit, dies zu beheben, darin besteht, eine Berichtsdatenbank zu erstellen.

Wollen Sie wirklich in diese Situation geraten?

Dritter , Ein komplexes Benutzerberechtigungsschema ist nur auf dem Papier eine gute Idee.

Das wirkliche Leben ist voller Ausnahmen. Eine gute Möglichkeit, dies zu realisieren, besteht darin, ein Benutzerberechtigungsschema für eine Anwendung zu entwerfen. Die ursprünglichen Anforderungen mögen ziemlich einfach sein, aber die Chancen stehen gut, dass Sie, wenn Sie ein wenig tiefer graben, viele Ausnahmen finden.

Um die Sache noch schlimmer zu machen, erwartet Ihr Kunde, dass Sie diese Ausnahmen in das Benutzerberechtigungsschema aufnehmen.

Tu es nicht!

Eine komplexe und flexible Benutzerberechtigung sieht auf dem Papier gut aus, aber denken Sie daran, Sie müssen sie auch implementieren .

Komplexe Benutzerberechtigungsschemata haben zwei Probleme:

• Sie sind schwer zu implementieren und zu pflegen.
• Niemand versteht nicht wirklich, wie sie funktionieren.

Mit anderen Worten, oft (aber nicht immer) ist ein komplexes Benutzerberechtigungsschema die Mühe nicht wert. Ich habe ein Prinzip:

Software sollte die Dinge einfacher machen, nicht schwieriger.

Ein komplexes Benutzerberechtigungsschema verstößt gegen dieses Prinzip. Deshalb sollten Sie es um jeden Preis vermeiden.

Vierter , Entitäten sind teuer!

Diejenigen unter Ihnen, die mein Lerntagebuch regelmäßig lesen, erinnern sich vielleicht daran, dass ich meine Meinung bezüglich der Abfrage von Entitäten innerhalb einer Nur-Lese-Transaktion geändert habe. Ich hatte das Gefühl, dass die Rückgabe von DTOs anstelle von Entitäten schneller sein würde, aber ich hatte keine Ahnung, wie viel schneller es sein würde.

Ich sollte einige Leistungstests durchführen, aber ich war zu beschäftigt (faul), um es tatsächlich zu tun. Deshalb war ich sehr glücklich, als ich bemerkte, dass Blake Caldwell ein kleines Benchmark-Projekt erstellt hatte, das beweist, dass das Abfragen von DTOs dreimal schneller ist als das Abfragen von Entitäten, selbst wenn die ausgeführte Abfrage sehr einfach ist (keine Joins).

Vielleicht möchten Sie seinen neuesten Blogbeitrag zu diesem Thema lesen. Das eigentliche Benchmark-Projekt wird in diesem Blogbeitrag erläutert.

Fünfter , Egal was in deinem Leben vor sich geht, du kannst dich immer wehren.

Diese Woche sah ich mir eine finnische Talkshow an und der Moderator lud Pekka Hyysalo ein, seine Geschichte zu erzählen. Er ist ein finnischer Freestyle-Skifahrer, der auf dem Weg nach oben war, als er sich beim Dreh eines neuen Skivideos schwer verletzte. Er erlitt eine schwere Gehirnverletzung und verbrachte 17 Tage im Koma. Als er aufwachte, war er nicht in der Lage zu essen, zu sprechen oder sich zu bewegen.

Aber er gab nicht auf. Er beschloss, sich zu wehren.

Ich weiß, dass diese Geschichte nichts mit Softwareentwicklung zu tun hat, aber sie erinnerte mich daran, dass die meisten von uns zu viel für selbstverständlich halten .

Wir gehen davon aus, dass wir echte Probleme haben:

• Wir könnten denken, dass die von uns gepflegte Codebasis voller Spaghetti-Code ist.
• Wir sind sauer, weil unsere Kollegen vielleicht keine Unit-Tests schreiben wollen.
• Wir glauben, dass unser Lohn zu niedrig ist.

In Wirklichkeit ist keines dieser Probleme ein "echtes" Problem, und alle sind relativ einfach zu lösen.

Nicht alle Menschen haben so viel Glück!

Was hast du diese Woche gelernt?

Teilen Sie Ihre Lernerfahrungen oder andere Kommentare im Kommentarbereich.