5 häufige C#-Fehler, die Ihre Software unwartbar machen - erklärt von Derek Comartin

1. Fehlendes Eigentum am Zustand

Derek beginnt damit, den Fehler zu benennen, der darin besteht, dass mehrere Grenzen oder Dienste gemeinsam genutzte Daten ohne klare Eigentumsverhältnisse aktualisieren können. Er verwendet ein Beispiel, bei dem das Abrechnungssystem in einen anderen Teil der Anwendung eingreift und den Zustand ändert. Dies führt zu Problemen mit der Datenkonsistenz, insbesondere wenn sich das Objekt an einem anderen Ort im System befindet.

Diese Art des freien Vorgehens führt zu Fehlern, bei denen die Entwickler fragen: "Warum sind diese Daten falsch?" oder "Wer hat sie geändert?" Derek betont, dass Sie die Verantwortlichkeiten festlegen müssen. Jeder Teil des Systems sollte eine klar definierte API oder Methode bereitstellen, die für die Verwaltung des Zustands verantwortlich ist.

Anstatt jedem Teil der Anwendung zu erlauben, gemeinsame Daten zu ändern, schlägt Derek vor, explizite Befehle und Abfragen zu erstellen. Wenn Sie zum Beispiel eine Lieferung aktualisieren möchten, geben Sie einen Befehl über eine spezielle Schnittstelle aus. Dies sorgt für Struktur und vermeidet Ressourcenverluste durch nicht nachvollziehbare Änderungen.

2. impliziter Code vs. explizite Workflows

Laut Derek verlassen sich viele Systeme stark auf CRUD-Operationen (Create, Read, Update, Delete), was jedoch zu impliziten Arbeitsabläufen führt. Der Code ist technisch funktionsfähig, aber es fehlt ihm an Klarheit über seine Funktion. Wenn Ihre Klasse nur generische Operationen unterstützt, bleibt der eigentliche Geschäftsablauf verborgen.

Nehmen wir folgendes Beispiel: Ein Fahrer holt ein Paket ab, und ein Frachtbrief wird erstellt. Wenn das System nur UpdateShipment ausführt, ist es unklar, ob die Änderung der Zeichenfolge (wie die BOL-Nummer) auf eine Abholung oder eine Korrektur zurückzuführen ist. Derek weist darauf hin, dass wir vage Aktualisierungen durch eindeutige Operationen wie PickupStopLoaded ersetzen sollten.

Dies führt zu besser lesbarem Code. Sie hilft auch bei der Behandlung von Ausnahmen, denn wenn eine Ausnahme auftritt, zeigt der Stack-Trace deutlich an, welcher Vorgang fehlgeschlagen ist. Explizite Methoden unterstützen auch bessere Codierungsstandards, da jede Funktion eine einzige Verantwortung hat.

3. nutzlose Indirektion hinzufügen

Derek geht auf die Indirektion ein - das Einfügen unnötiger Ebenen zwischen Aufrufer und Zielmethode. Er veranschaulicht dies anhand von Datenbankverbindungen. Ein Controller könnte einen Dienst aufrufen, der einen Helfer aufruft, der einen weiteren Dienst aufruft, der schließlich die Abfrage über Entity Framework ausführt.

Diese Pyramide von Abstraktionen erschwert die Rückverfolgung von Problemen und die Verbesserung der Leistung. Obwohl die Schaffung von Abstraktionen nützlich sein kann, wie z. B. das Wrapping von IDisposable-Schnittstellen für eine bessere Ressourcenverwaltung, warnt Derek davor, es zu übertreiben. Fragen Sie sich, ob Ihre Abstraktion die API vereinfacht oder ob sie nur eine Abhängigkeit von einem Drittanbieter verbirgt, die nur an einer Stelle existiert.

Anstatt Schichten um der Schichten willen zu bilden, schlägt Derek vor, die Kopplung direkt zu verwalten. Übermäßige Indirektion macht Ihren Code nicht nur unübersichtlich, sondern erhöht auch das Potenzial für Speicherlecks und schwächt die Vorteile der Garbage Collection.

4. das "Was-wäre-wenn-Spiel" spielen

Der nächste Fehler, den Derek identifiziert, ist die Vorbereitung auf hypothetische Anwendungsfälle, die vielleicht nie eintreten werden - was er das "Was-wäre-wenn-Spiel" nennt Viele C#-Entwickler schreiben flexible Klassen und Funktionen, um zukünftige Anforderungen zu berücksichtigen. Ein Beispiel: "Was, wenn wir zwei Sprachen unterstützen müssen?" oder "Was, wenn wir die Technologie wechseln müssen?"

Derek warnt davor, dass diese Denkweise zu aufgeblähten Frameworks und übermäßig generischem Code führt. Er erwähnt, dass er auf String-Verkettungslogik und Referenztyp-Wrapper stößt, die niemand versteht, weil sie nur einen einzigen echten Anwendungsfall bedienen.

Anstatt sich auf das Unbekannte vorzubereiten, rät Derek, sich auf die tatsächlichen Anforderungen zu konzentrieren. Jede Methode und Variable sollte einem aktuellen, gerechtfertigten Zweck dienen. Ungenutzte Funktionen verursachen nur zusätzliche Wartungskosten. Wie Derek sagt, geht es nicht nur um die Entwicklungszeit, sondern auch um die Betriebskosten. Wenn Ihre öffentliche bool Equals-Implementierung zum Beispiel jeden denkbaren Randfall abdeckt, aber keinen, der tatsächlich vorkommt, haben Sie wertvolle Zeit verschwendet.

5. Arbeitsabläufe nicht richtig verwalten

Abschließend geht Derek auf den Fehler ein, Workflows als Verfahrensblöcke statt als modulare Schritte zu behandeln. Er verwendet ein Beispiel aus der Praxis: eine Online-Bestellung. Nachdem der Benutzer den Bestellvorgang abgeschlossen hat, belastet das System die Kreditkarte und sendet dann eine Bestätigungs-E-Mail.

Wie reagiert Ihr Code, wenn ein Schritt fehlschlägt, z. B. der Zahlungsvorgang? Machen Sie die Bestellung rückgängig? Einen Fehler anzeigen? Eine E-Mail mit einem Fehler senden? Derek erklärt, dass es zu einer unüberschaubaren Komplexität führt, wenn man alles in einen Block packt.

Er empfiehlt, Arbeitsabläufe als kleine, isolierte Einheiten zu gestalten, die über Nachrichten kommunizieren. Die Verwendung von asynchronen Task-Operationen und Yield-Return macht diese Schritte einfacher zu handhaben. Außerdem kann die Verwendung der using-Anweisung und des using-Blocks bei externen Ressourcen wie Dateizugriff oder Datenbankverbindungen helfen, Speicherlecks zu vermeiden.

So stellt beispielsweise ein using-Block um einen Stream sicher, dass dieser korrekt entsorgt wird - ein wichtiger Punkt bei der Arbeit mit IDisposable-Schnittstellen. Wenn Arbeitsabläufe komplexer werden, stellen diese Best Practices sicher, dass Ausnahmen abgefangen und effektiv behandelt werden, um die Leistung und Wartbarkeit zu erhalten.

Abschluss: Sauberen, wartbaren Code schreiben

Wie Derek in seinem Video bei 12:45 abschließt, reflektiert er diese Fehler nicht nur als Dinge, die er gesehen hat, sondern auch als Dinge, die er persönlich beim Aufbau großer Unternehmenssysteme gemacht hat. Dies sind Lektionen, die man aus Erfahrung gelernt hat, und er ermutigt die Zuschauer, ihre eigenen Fehler in den Kommentaren mitzuteilen.

Die Ratschläge von Derek gelten nicht nur für C#, sondern auch für viele andere Sprachen. Ganz gleich, ob Sie mit String-Vergleichen, Equals()-Methoden oder der Entwicklung neuer Funktionen arbeiten, der Schlüssel liegt in der Klarheit, der Absicht und der Wartbarkeit Ihres Codes.

Wenn Sie daran interessiert sind, Ihre C#-Kenntnisse zu verbessern und diese häufigen Fehler zu vermeiden, finden Sie auf Dereks Kanal viele kostenlose Ressourcen zu Systemarchitektur, Entwurfsmustern und Ratschlägen zu Programmiersprachen aus der Praxis. Wenn Sie nur einen dieser Fehler vermeiden, können Sie die Qualität Ihres Projekts erheblich verbessern.

Wenn Sie also das nächste Mal anfangen, Code zu schreiben, denken Sie an Dereks Worte und fragen Sie sich: "Mache ich das komplexer, als es sein muss?"

Weitere Inhalte dieser Art finden Sie auf dem CodeOpinion YouTube-Kanal von Derek Martin.