C#

Le passage de .NET Framework à .NET n'est généralement pas aussi simple que de changer de cible. Il est donc plutôt intéressant de constater que la plupart des développeurs n'ont au moins pas raté le train de .NET (Core). En revanche, je suis surpris qu'un pourcentage important de développeurs maintiennent encore des projets ciblant .NET Framework 4.6 et ses versions antérieures. Je me demande bien ce qui empêche ces projets de passer à la version 4.8.

Je trouve que c'est une bonne chose que davantage de développeurs utilisent la dernière version de C#. Je me demande s'ils transfèrent davantage d'applications héritées vers la dernière version de .NET ou s'ils créent simplement de nouvelles applications et de nouveaux systèmes et abandonnent l'ancien code hérité.

C# reste le langage de prédilection incontesté des développeurs .NET. VB.NET et F# sont également utilisés, mais le plus souvent, la préférence va à C# et aux langages de frontend tels que JS et TS.

Je suis un peu surpris par le nombre de développeurs C# qui utilisent (aussi) macOS et Linux. En ce qui concerne Linux, il serait intéressant de connaître la répartition entre machines (virtuelles) Linux ordinaires et WSL.

En tant qu'ancien ingénieur SDET, je suis déçu par le pourcentage de développeurs C# qui n'écrivent aucuns tests unitaires. Je pensais qu'aujourd'hui il y avait finalement un consensus sur les avantages des tests unitaires. Il serait intéressant de comprendre les causes de faible taux d'utilisation. Les développeurs ne sont-ils pas convaincus des avantages des tests unitaires? S'agit-il d'un manque de formation ou de culture en matière d'ingénierie ? Les managers cherchent-ils à éviter les investissements à court terme que requièrent les tests unitaires ?

En repensant à mes 20 ans d'expérience dans ce domaine et en les comparant aux chiffres présentés ici, j'en arrive à la conclusion que l'analyse et l'amélioration des performances tombent souvent dans l'angle mort de nos jours, alors que cela ne devrait pas être le cas. Alors que dans le passé, les problèmes étaient dus aux limitations de la mémoire et des ressources de l'unité centrale, aujourd'hui, nous écrivons régulièrement du code destiné à être exécuté sur des appareils mobiles, sur lesquels la durée de vie de la batterie pose problème, ainsi que sur des solutions cloud amenées à évoluer, pour lesquelles une utilisation inefficace des ressources informatiques entraîne rapidement des milliers de dollars de coût supplémentaire chaque mois qui pourraient être évités.

Effectuer un profilage régulier a selon moi le même effet que la capitalisation des intérêts dans un contexte financier. Pour préparer votre retraite, vous pouvez mettre régulièrement une petite somme d'argent de côté et en optant pour des placements à intérêts composés, parvenir à obtenir une somme conséquente. C'est la même chose avec le profilage : même en consacrant une toute petite partie de votre temps à l'analyse des performances, si vous le faites de manière pertinente et régulière, vous obtiendrez finalement des améliorations importantes. Je ne cherche pas à obtenir des améliorations extraordinaires en une seule fois, mais itération après itération.