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

Was ich in Woche 44 gelernt habe

Zuerst , Echte Architektur ist wichtig.

Das Wort Architektur erzeugt oft mentale Bilder über komplexe Diagramme, die die Architektur der implementierten Software veranschaulichen. Obwohl diese Diagramme gut und professionell aussehen, garantieren sie nicht, dass die Implementierung der Anwendung der angegebenen Architektur folgt. Die eigentliche Architektur findet sich im Quellcode .

Vielleicht sagen Entwickler deshalb manchmal, dass eine Software zwei Architekturen hat:die geplante und die reale.

Sie können diese Situation jedoch vermeiden, indem Sie sich gut um die tatsächliche Architektur Ihrer Software kümmern. Sie ist wichtiger als die geplante Architektur, denn wenn man sie ignoriert, kann man Fehler machen, die in der Wartungsphase viel Geld (und Zeit) kosten.

Außerdem können Fehler in der Entwicklungsphase dazu führen, dass Sie bestimmte Funktionen nicht implementieren können, da die Implementierung zu viel Zeit und Geld kosten würde.

Verbringen Sie nicht zu viel Zeit damit, diese gut aussehenden Diagramme zu zeichnen, denn manchmal (oft?) haben sie nichts mit der Realität zu tun.

Denken Sie daran, dass die Architektur nicht in Ihrem Diagrammeditor erstellt wird. Es wird in Ihrer IDE erstellt .

Zweite , Fordern Sie eine zweite Meinung an.

Ich habe bereits über die Bedeutung von Code-Reviews geschrieben, aber in letzter Zeit habe ich festgestellt, dass es manchmal ratsam ist, eine zweite Meinung einzuholen. Ich glaube immer noch, dass Code-Reviews, die von Ihren Teammitgliedern durchgeführt werden, wichtig sind und Sie sie regelmäßig durchführen sollten.

Ich habe jedoch festgestellt, dass die Codebasis Sie (und Ihre Teammitglieder) manchmal für Probleme "blind" machen kann, die für andere Entwickler offensichtlich sind. Das Problem ist, dass, wenn Sie über einen längeren Zeitraum mit derselben Codebasis arbeiten, diese für Sie normal aussieht. In diesem Fall ist es wirklich einfach, die in der Codebasis gefundenen "Fehler" zu multiplizieren.

Das ist natürlich ein Fehler, aber es ist auch eine sehr menschliche Sache .

Die Lösung für dieses Problem ist einfach:

Sie müssen einen Entwickler bitten, der die Codebasis nicht kennt, sich diese anzusehen. Dadurch erhalten Sie eine zweite Meinung von einem Entwickler, der den Kuriositäten der Codebasis nicht blind gegenübersteht. Auf diese Weise erhalten Sie wertvolles Feedback, das Ihnen hilft, die Qualität Ihres Codes zu verbessern.

Hinweis: Dieses Whitepaper hilft Ihnen dabei, Peer-Code-Reviews in einen agilen Prozess zu verwandeln.

Dritter , Akzeptieren Sie Ihre Fehler, anstatt sie zu verstecken.

Ich muss ein Geständnis machen:

Ich mache Fehler (selbst grundlegende).

Fühle ich mich deswegen schlecht? Natürlich tue ich das, aber ich denke auch, dass Fehler unvermeidlich sind. Ich sehe das so, dass ich zwei Möglichkeiten habe:

1. Ich kann mich selbst bemitleiden.
2. Ich kann weitermachen und herausfinden, wie ich die Dinge richtig machen kann.

Ich werde jedes Mal die zweite Option wählen.

Haben Sie auch keine Angst, dass Ihre Kollegen denken, Sie seien kein Profi, wenn Sie Ihre Fehler eingestehen.

Jeder macht Fehler .

Wenn jemand sagt, dass er niemals leichte Fehler macht, lügt er entweder oder er ist eine Art Supermensch.

Welche Option ist wahrscheinlicher?

Vierter , Sie sind dafür verantwortlich, Ihren Code wartungsfreundlich zu gestalten.

Die meisten Entwickler, die ich kenne, wollen keine Software warten, weil sie denken, dass es scheiße ist. Obwohl ein Teil dieses Widerstands wahrscheinlich mit der Tatsache zusammenhängt, dass diese Leute keinen Code pflegen wollen, der von anderen Leuten geschrieben wurde, sollten Sie Ihren Code dennoch leicht wartbar machen.

Der einfachste (auf lange Sicht weniger zeitaufwändige) Weg, dies zu tun, besteht darin, Tests für Ihren Code zu schreiben. Wenn Sie keine Komponententests schreiben möchten, schreiben Sie Integrationstests, die beschreiben, wie jede Funktion funktionieren soll. Denken Sie daran, dass, wenn Ihre Anwendung keine umfassende Testsuite hat, die Entwickler, die sie warten, das korrekte Verhalten herausfinden müssen, indem sie den Quellcode lesen und ihn mit der Dokumentation vergleichen.

Das kostet viel Zeit und Geld und ist einer der Hauptgründe, warum Softwarewartung als Scheißjob angesehen wird.

Der Großteil der Lebenszykluskosten von Software entfällt auf die Softwarewartung. Das bedeutet, dass der Kunde bei einem schwer zu wartenden Code mehr Geld bezahlen muss, um die gleichen Ergebnisse zu erzielen, als bei einem einfach zu wartenden Code.

Die Pflege Ihres Codes ist der beste Gefallen, den Sie Ihren Kollegen und Kunden erweisen können .

Einfach das Richtige tun. Es wird auch Wunder für Ihren Ruf bewirken.

Fünfter , Die Verarbeitung großer Datensätze mit Hibernate ist langsam, wenn Sie normale Hibernate-Sitzungen verwenden.

Diese Woche ist mir aufgefallen, dass die Verarbeitung großer Datensätze mit Hibernate sehr langsam ist, wenn ich regelmäßige Hibernate-Sitzungen verwende. Als ich die Anwendung profilierte, bemerkte ich das

1. Die Ausführung der Datenbankabfrage, die 15.000 Zeilen zurückgab, dauerte 45 Millisekunden.
2. Es dauerte 20 Sekunden, um Entitäten aus der Ergebnismenge zu erstellen.

Ich habe einen Fix implementiert, der die Ergebnisse in kleineren Stapeln abgerufen hat. Dieses Wochenende habe ich etwas recherchiert und festgestellt, dass das Ersetzen der regulären Sitzung durch eine zustandslose Sitzung mir helfen könnte, die Leistung dieser Funktion zu verbessern.

Hinweis: Weitere Informationen zu zustandslosen Sitzungen:

• Umgang mit großen Datensätzen mit JPA (oder zumindest mit Hibernate)
• Zustandslose Sitzung

Ich werde dies am Montag versuchen und die Ergebnisse in diesem Blogbeitrag aktualisieren, wenn ich alle Details kenne.

Was hast du diese Woche gelernt?

Teilen Sie Ihre Lernerfahrungen oder andere Kommentare im Kommentarbereich.