¡Un Enfoque Simple pero Poderoso para el Código Limpio!

Hola a todos. Soy Clint Cameron, Gerente de Marketing de Productos en Solar Source. Y hoy, voy a demostrar lo fácil que es programar de manera más inteligente y aprovechar el poder de CleanCode en tus flujos de trabajo de DevOps. Ahora, permítanme comenzar con un flujo de trabajo tradicional y mostrar cómo puede desperdiciar una cantidad tremenda de tiempo de desarrollo. El código se escribe y se envía a la rama principal. Los auditores señalan posibles problemas y luego los desarrolladores vuelven al código para clasificar y separar los problemas reales de los falsos positivos. El resultado final es que hasta un 42% del tiempo de desarrollo se puede dedicar a rehacer y corregir código defectuoso.

En Solar Source, tenemos una mejor manera de agregar desarrollo, un enfoque de código limpio. Ponemos al desarrollador a cargo de la calidad del código y le brindamos las herramientas para escribir solo código limpio. Es ineficiente enviar problemas a tu rama principal o una rama de características solo para volver a visitar esos problemas más tarde. En su lugar, encontremos esos problemas tan pronto como ocurran y eliminémoslos incluso antes de que se confirmen por primera vez.

OK, podemos ver que el enfoque de código limpio es más eficiente. ¿Qué significa exactamente eso para ti y tu equipo? Bueno, significa la propiedad directa del código por parte del desarrollador y del equipo. Significa código eficiente y mantenible, código que es robusto y confiable cuando se ejecuta. Significa, por supuesto, código seguro para tus usuarios y para tu organización. Y finalmente, significa código que fomenta la innovación y mantiene a los desarrolladores felices.

OK, en un minuto, voy a demostrar cómo puedes agregar código limpio a tu flujo de trabajo utilizando SonarCloud y la Solución Sonar. Es 100% gratuito para proyectos públicos y puedes analizar tu código en minutos. Ahora, antes de demostrarlo, déjame explicarte rápidamente la solución. En mi demostración, mi proyecto está alojado en GitHub. También tenemos una integración estrecha con Azure, Bitbucket y GitLab. Todo comienza con una solicitud de extracción, que inicia un escaneo automático de tu código. Este escaneo automático se puede integrar fácilmente con tu sistema CI/CD existente. A partir del análisis, obtenemos un conjunto de métricas de calidad de código y una clara indicación de cualquier problema. Los resultados del análisis se sincronizan automáticamente con GitHub. Así que obtienes información valiosa justo donde tu equipo vive, come y respira. Ahora, pasemos a la demostración. Bien, aquí está nuestro código para la demostración. Lo primero es iniciar un análisis en sonarcloud.io. Nos autenticaremos utilizando nuestras credenciales de GitHub. Navegaremos para crear una nueva organización. Eso se importará automáticamente y lo seleccionaremos. Vamos a seleccionar un plan gratuito y obtener ese proyecto importado, y eso es todo. SonarCloud se encargará del resto. Se preparará para el análisis y luego ejecutará completamente ese análisis. Ahora, dependiendo del tamaño de tu proyecto, del número de líneas de código que contiene tu proyecto, podría llevar unos minutos ejecutarlo. Solo tengo unos siete minutos con ustedes, así que en aras del tiempo, pausaremos y retomaremos una vez que se complete el análisis.

De acuerdo, análisis completado. Echemos un vistazo. Navegamos a la rama principal y vemos que tenemos algunos problemas de confiabilidad, seguridad y mantenibilidad. Eso es

Es genial tener una comprensión básica de lo que está sucediendo en tu rama principal. Ahora, aparte de esas vulnerabilidades, esas deben corregirse, pero todo lo demás es agua pasada. Lo importante es comenzar a detectar problemas desde ahora. Iniciemos un proceso de código limpio desde ahora, para que estemos adelantándonos. Cuando ocurran cosas, detectémoslas lo antes posible y evitemos que lleguen siquiera cerca de la rama principal. Detectémoslas antes de que lleguen siquiera a una rama de características. Con ese fin, me gustaría hacer un análisis de una solicitud de extracción. Ya tengo una rama configurada en GitHub. Iniciaremos una nueva solicitud de extracción en esa rama. Eso es todo lo que se necesita. Se iniciará automáticamente y escaneará nuestra solicitud de extracción, al igual que la rama principal. Dependiendo del tamaño de la solicitud de extracción y del número de líneas de código incluidas, puede llevar unos segundos o unos minutos completar y ejecutar el análisis. Está ejecutándose en este momento. Espero que termine. Ahí va, ya terminó. Podemos ver que tenemos una puerta de calidad fallida debido a una vulnerabilidad en nuestra solicitud de extracción. No queremos eso, así que déjame mostrarte algo muy interesante ahora mismo. Aquí puedes ver que si intentara fusionar esta solicitud de extracción, está en rojo, hago clic en ella, está bloqueada. A menos que tenga privilegios de administrador, puedes configurarlo para que si obtienes una puerta de calidad en rojo en una solicitud de extracción, no se pueda fusionar a menos que se solucione. De acuerdo, cancelaremos eso. Ahora, permíteme ir a la pestaña de conversaciones. Permíteme llevarte a la pestaña de comprobaciones. También podemos ver una integración muy buena allí. Además, quiero mostrarte algo interesante aquí, que es nuestra integración con las capacidades de análisis de código de GitHub, y puedes ver que obtienes aún más información sobre esta vulnerabilidad. Si vamos al final aquí, podemos ver que parece que podríamos tener un defecto de inyección. Si hacemos clic en Mostrar rutas, podemos ver que tenemos una fuente aquí en app.js, y atraviesa cinco pasos diferentes, incluso se cruza en otro archivo llamado app handler.js, y eso es nuestra sincronización. El punto es que queremos proporcionar la mayor información posible en GitHub. Es donde trabajas, así que obtengamos la información correcta en el momento adecuado para que puedas tomar decisiones. Y con ese fin, tenemos esta pequeña casilla de verificación aquí. Podemos clasificar las cosas como tal vez sea un falso positivo, tal vez solo se use en pruebas o por alguna razón decimos que no lo vamos a corregir. De acuerdo, terminaré llevándote de vuelta a la pestaña de comprobaciones aquí y mostrándote una última función. Si hago clic aquí, puedo abrir esta solicitud de extracción, obtener el mismo conjunto de métricas que vimos en la rama principal pero ahora es en RPR. Ahí está nuestra vulnerabilidad. Puedo hacer clic aquí mismo y profundizar un poco más y descubrir exactamente lo que está sucediendo con esa vulnerabilidad, así como algunos consejos para corregirla, porque ese es el objetivo del juego. De acuerdo, gracias. Feliz codificación limpia y nos hablamos más tarde. ¡Hasta luego!