C#

Da der Wechsel vom .NET-Framework zu .NET in der Regel nicht mit einer einfachen Änderung des Kompilierungsziels getan ist, ist es interessant, dass die meisten Entwickler*innen zumindest bei .NET (Core) mit dabei sind. Gleichzeitig ist es erstaunlich, dass ein erheblicher Prozentsatz der Entwickler*innen immer noch Projekte für .NET Framework 4.6 und früher wartet. Ich möchte gerne wissen, was diese Projekte vom Umstieg auf 4.8 abhält.

Ich halte es für gut, dass mehr Entwickler*innen die neueste C#-Version verwenden. Ich frage mich, ob sie alte Anwendungen zunehmend auf die neueste .NET-Version umstellen oder nur neue Anwendungen und Systeme entwickeln und den alten Code einmotten.

C# ist nach wie vor die unangefochtene Sprache der Wahl für .NET-Entwickler*innen. VB.NET und F# werden zwar auch verwendet, aber nicht so häufig wie C# und Frontend-Sprachen wie JS und TS.

Ich bin etwas überrascht, wie viele C#-Entwickler*innen (auch) macOS und Linux nutzen. Bei Linux wäre es interessant, die Zahlen weiter in reguläre (virtuelle) Linux-Systeme und WSL aufzuschlüsseln.

Als ehemaliger SDET finde ich den Prozentsatz der C#-Entwickler*innen, die keine Unit-Tests schreiben, enttäuschend. Ich hatte gehofft, dass es inzwischen einen Konsens über die allgemeinen Vorteile von Unit-Tests geben würde. Es wäre interessant, den Grund dafür zu erfahren. Sind die Entwickler*innen nicht vom Nutzen überzeugt? Liegt es an einem Mangel an Ausbildung oder Entwicklungskultur? Gibt es Widerstand im Management gegen die kurzfristigen Investitionen, die Unit-Tests erfordern?

Wenn ich auf meine 20 Jahre in diesem Bereich zurückblicke und meine persönlichen Erfahrungen mit den Zahlen hier vergleiche, komme ich unweigerlich zum Schluss, dass die Leistungsanalyse und -verbesserung heute oft ein blinder Fleck ist, obwohl das eigentlich nicht sein dürfte. In vielerlei Hinsicht hat sich der Kreis geschlossen. Während es früher um begrenzte Arbeitsspeicher- und CPU-Ressourcen ging, schreiben wir heute routinemäßig Code für Mobilgeräte, bei denen die Akkulaufzeit ein Problem ist, sowie Cloud-Lösungen, die skalierbar sein müssen und wo eine ineffiziente Nutzung der Rechenressourcen leicht dazu führt, dass jeden Monat Tausende Dollar an vermeidbaren Mehrkosten entstehen.

Ich glaube, dass beim regelmäßigen Profiling die Idee der Zinseszinsen maßgeblich ist. Wie wir das bei der Altersvorsorge kennen: Wir sparen im Zeitverlauf kontinuierlich kleine Beträge an, bis wir schließlich einen Punkt erreichen, an dem wir eine bedeutende Summe besitzen. Dasselbe gilt für das Profiling: Selbst wenn wir nur einen winzigen Teil unserer Zeit in Performance-Auswertungen stecken, führt dies zu großen Verbesserungen auf breiter Front, wenn wir konsequent und beharrlich sind. Ich versuche daher nicht, riesige, massive Verbesserungen auf einmal zu erzielen. Wenn wir Iteration für Iteration vorankommen, ist das Ergebnis hervorragend.