Los avisos del compilador. Warnings. No son errores, sólo warnings. Puedes ignorarlos totalmente y olvidarte de ellos, verdad? Bueno, espero que no lo estés haciendo.
«¡Pero si incluso en el código estándar de Microsoft aparecen warnings!, podrías decir. Y eso es totalmente cierto, pero no es tu código, es el de Microsoft. Si una funcionalidad que usas se rompe porque Microsoft no tuvo cuidado de los warnings, puedes abrir un soporte y arreglarlo es el trabajo de Microsoft. Si tu código rompe alguna funcionalidad porque pasaste de los warnings, es tu trabajo arreglarlo, y tu cliente va a quererlo igual de rápido que tu querrías que Microsoft arreglara su error.
Por esto es por lo que deberíamos estar avisados de los warnings (badum tss). Ay… en inglés tenía «más gracia».
Warnings
Así que, ¿por qué deberíamos preocuparmos de los warnings? Porque nos avisan de que algo podría ir mal. El mejor ejemplo podrían ser las características obsoletas, métodos o metadatos:
After a period of at least 12 months, Microsoft might delete obsolete methods and metadata elements.
https://docs.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/migration-upgrade/deprecation-deletion-apis#cleanup-of-deprecated-elements
Este es un buen ejemplo. De todas formas si la telemetría de Microsoft muestra que se están usando esos métodos no los borrarán, sinó que tendrás un nuevo warning y deberías arreglarlo.
¿Y si me da igual? Podría darse la situación de que tu código compilase pero no funcionara como se espera. Hace mucho tiempo el método postTrans de la clase LedgerJournalCheckPost se marcó como obsoleto y lanzaba un warning diciendo que usaras el método postTransV2.
Esto me pasó. A mi. El cliente me dijo que algo dejó de funcionar. Comprobé la clase de extensión y todo parecía correcto, pero mi método de CoC nunca se llamaba. Miré la pila de llamada y vi que el estándar ahora llamaba al método V2 y que mi código no se ejecutaba. Compilaba pero no funcionaba.
Otros cambios en métodos o clases que pasan a ser internal también tienen que vigilarse. En algún punto el warning que se lanza se puede convertir en un error y entontes tu código sí dejará de compilar.
Un ejemplo (no tan) loco
A veces un ejemplo un poco extremo es la mejor forma de enseñar lo que quiero decir, porque es improbable y no debería ocurrir. O sí, miradnos ahora, nadie esperaba que tuvieramos esta situación…
Sé que MS dice que no borrarán código que se esté usando, pero IMAGINAD que no véis el warning de obsolescencia y pasado un año desaparece. La buena noticia es que seguro que implementamos una estrategía Dev ALM de Dynamics 365 correcta y lo vamos a detectar con el pipeline de CI de build (aunque estoy viendo un montón de proyectos que no lo usan así que…)
Ey, y con One Version y proyectos sin mantener ¡esto podría ocurrir perfectamente!
Ahora imaginad algo peor, el método no se borra pero su código si. Un método vacío con el atributo SysObsolete diciéndote que uses otro método. Y si no compruebas los warnings nunca lo verás y tus cambios dejarán de funcionar porque estaremos extendiendo un método obsoleto. Y este caso tampoco se detectaría con una estrategía bonita de Dev ALM…
Lo que intento decir con este ejemplo es que si continúas ignorando todos los warnings porque, «Tío, relájate, ¡que solo es un warning!«, acabarás teniendo tantos warnings que, un día, se te va a pasar el que era importante de verdad y el que va a joderte el código.
Warnings (menos) malvados
Pero bueno, lo que acabo de describir no debería ocurrir, y los warnings que te vas a encontrar van a ser normalmente casts que pierden precision, enums extensibles con valores numéricos y cosas así.
Y luego está el warning de la XBOX que nos aparece a todos cuando desarrollamos en X++:
Assembly 'Microsoft.Xbox.Experimentation.Contracts, Version=1.0.0.0, Culture=neutral, PublicKeyToken=d91bba2b903dc20f' failed to load because it was not found.¿Qué es esto? ¿Para qué usa un ERP ese namespace? ¿Van a gamificar Dynamics 365 para que los usuarios ganen puntos cuando usan bien el ERP? ¿Y qué harán cuando tengan puntos negativos?
Pero, chistes aparte, deberíamos intentar arreglar los warnings si podemos, porque eso hará de nuestro código más elegante y de mejor calidad. Y quizás si en el futuro alguien con un TOC tiene que modificar tu código, y tu ya no estás ahí, vas a querer que esa persona mantenga su salud mental. Hazlo, por favor.
Un poco de ayuda
Recordad que podemos usar el Application Checker para comprobar otras métricas de calidad de código.
También podéis leer este post de Vilmos Kintera sobre interpretar los resultados del compilador de VS usando PowerShell.
