C#

Dado que pasar de .NET Framework a .NET no suele ser tan sencillo como cambiar de objetivo, es interesante que la mayoría de los desarrolladores se hayan subido al tren de .NET (Core). Al mismo tiempo, es sorprendente que un porcentaje significativo de desarrolladores siga manteniendo proyectos con .NET Framework 4.6 y versiones anteriores. Tengo curiosidad por saber qué impide que estos proyectos pasen a la versión 4.8.

Me parece positivo que cada vez más desarrolladores utilicen la última versión de C#. Me pregunto si están trasladando más aplicaciones heredadas a la versión más reciente de .NET, o simplemente creando nuevas aplicaciones y sistemas y dejando atrás el antiguo código heredado.

C# sigue siendo el lenguaje indiscutiblemente preferido por los desarrolladores .NET. También se utilizan VB.NET y F#, pero lo más frecuente es C# y lenguajes de frontend como JS y TS.

Me sorprende un poco la cantidad de desarrolladores de C# que utilizan (también) macOS y Linux. En el caso de Linux, sería interesante desglosar esta cifra por máquinas (virtuales) Linux normales frente a WSL.

Como antiguo SDET, me parece decepcionante el porcentaje de desarrolladores de C# que no escriben ninguna prueba de unidad. Esperaba que a estas alturas hubiera un consenso sobre las ventajas de las pruebas de unidad en general. Sería interesante averiguar a qué se debe. ¿Los desarrolladores no creen en sus ventajas? ¿Es una cuestión de falta de formación o de cultura de ingeniería? ¿Se opone la dirección a las inversiones a corto plazo que requieren las pruebas de unidad?

Echando la vista atrás a mis 20 años en este campo y comparando mi experiencia personal con las cifras que aparecen aquí, tengo que llegar a la conclusión de que el análisis y la mejora del rendimiento son a menudo un punto ciego hoy en día, aunque realmente no deberían serlo. En muchos sentidos, hemos cerrado el círculo. Mientras que en los viejos tiempos los problemas eran la memoria y los recursos de CPU limitados, hoy en día escribimos código de forma rutinaria para que se ejecute en dispositivos móviles donde la duración de la batería es un problema, así como en soluciones en la nube que necesitan escalarse donde el uso ineficiente de los recursos informáticos significa rápidamente gastar miles de dólares más de lo necesario cada mes.

Creo que la generación regular de perfiles va unida a la idea del interés compuesto. Como usted sabe, al igual que en la jubilación, se aporta una pequeña cantidad de dinero a lo largo del tiempo de manera constante, lo que finalmente conduce hasta el punto en que acumula una suma significativa. Lo mismo ocurre con la generación de perfiles: incluso un pequeño segmento de tiempo para observar el rendimiento se traduce en grandes mejoras en general, si lo hace de forma constante y persistente a lo largo del tiempo. Así que no aspiro a enormes mejoras masivas de golpe. Son excelentes cuando nos ponemos a ello, iteración tras iteración.