Comprende tu base de código para innovar más rápido

Estamos aquí para responder sus preguntas y compartir sus ideas.

Hola a todos. Mi nombre es Simon Walter.

Soy un desarrollador de software en Microsoft,

y estoy aquí para contarles un poco sobre

cómo podemos mejorar la eficiencia de los desarrolladores

ayudando a las personas a comprender su base de código de manera más efectiva.

En cuanto a la preparación para esta charla,

he estado involucrado en tecnología de desarrollo de software durante algún tiempo.

y cómo son relevantes para el desarrollo de software,

y cómo realmente entregamos aplicaciones de software,

y cómo podemos acelerar ese proceso.

Entonces, aquí está mi lista de cinco.

Su lista puede ser diferente.

Entonces, el software de código abierto,

cuando comencé en el desarrollo de software,

básicamente las APIs, las bibliotecas que tenías disponibles

eran esencialmente las que se incluían con el sistema operativo

o venían con una herramienta de desarrollo o plataforma en la que habías invertido.

Ahora tenemos bibliotecas desde el front-end,

estamos en una conferencia de React, por supuesto,

hasta el back-end en términos de proporcionar bases de datos,

herramientas de búsqueda, muchas bibliotecas,

y tal vez los desafíos en términos de decidir

qué biblioteca o framework deseas usar.

Y, por supuesto, ha habido grandes cambios en términos

de cómo las personas construyen aplicaciones de software.

Entonces, hemos pasado de un enfoque de Gran Explosión

o de metodologías tipo cascada,

donde capturamos nuestros requisitos, lo cual lleva tiempo.

Trabajé durante algún tiempo para una empresa de investigación.

Hicimos mucho trabajo para grandes organizaciones gubernamentales.

Teníamos enormes documentos de requisitos

que teníamos que leer o preparar.

Entonces, hemos pasado a un enfoque más iterativo.

Estaremos trabajando con fragmentos más pequeños

en términos de las capacidades que queremos entregar.

Y eso es genial porque nos permite reducir ese ciclo

entre la construcción y entrega de aplicaciones

o capacidades, funciones adicionales,

y obtener comentarios de nuestros interesados o clientes.

Entonces, un enfoque más iterativo y rápido.

Entonces, básicamente, nos permite corregir la dirección mucho antes

en el ciclo de vida de una aplicación o solución en particular.

Y, por supuesto, el cambio a la nube,

donde ya no tienes que preocuparte por obtener infraestructura

o redes a un nivel básico,

donde puedes obtener un servicio de base de datos

o middleware bajo demanda

sin tener que preocuparte por cómo configurarlo,

implementarlo o administrarlo.

Y, obviamente, esto proporciona bloques de construcción adicionales

en términos de construir y entregar soluciones de software.

Y, tal vez diría que hay un paralelismo entre la computación en la nube

y el software de código abierto.

Nuevamente, se trata fundamentalmente de proporcionar bloques de construcción adicionales

para permitir a los desarrolladores de software

centrarse en sus problemas comerciales,

en sus funciones y capacidades comerciales

donde realmente pueden agregar valor

a sus clientes.

Y los dos últimos en términos de integración continua,

entrega, muy alineados con el desarrollo ágil.

Nuevamente, el enfoque está en las pruebas,

lo que implica entregar software con mayor frecuencia

o entregar e implementar software de manera más rápida.

Nuevamente, reduciendo ese ciclo,

pero también permitiéndonos probar con cambios más pequeños,

obtener comentarios adicionales más rápidamente.

Idealmente, cuando te encuentres con problemas,

el conjunto de cambios que debes evaluar

para encontrar la causa raíz es más pequeño.

Y finalmente, en términos de arquitectura basada en servicios.

Entonces, es un gran cambio en términos de cambios en términos de cómo construimos realmente el software desde un punto de vista arquitectónico, desde el modelo cliente-servidor hasta las aplicaciones de tres niveles y las aplicaciones de múltiples servicios. Y nuevamente, donde el objetivo es mejorar o aumentar la encapsulación y desacoplar la lógica de la aplicación. Entonces, nuevamente, esto facilita mucho potencialmente realizar cambios dentro de nuestro código porque los cambios tienen menos impacto o un impacto limitado en otros servicios, etc., porque estamos detrás de una API basada en servicios. Y esto es relevante en términos de aplicaciones de front-end también, donde tal vez haya un movimiento para permitir a las personas crear aplicaciones de micro front-end. Nuevamente, donde tenemos un conjunto de componentes de aplicación componibles que podemos unir fácilmente.

Entonces, diría que obviamente todos estos cambios, iniciativas, obviamente han tenido un impacto en términos de qué tan rápido, qué tan rápido podemos desarrollar software. Pero si realmente pensamos en el ciclo de vida del desarrollo de software, no es solo un gran ciclo. Muchas personas tienden a pensar en él como esencialmente un ciclo externo y un ciclo interno. Entonces, el ciclo externo es esencialmente las versiones, los proyectos, los sprints que estamos realizando. Entonces, es más un esfuerzo de equipo en cierto sentido. Y probablemente argumentaría que en términos de los cinco cambios que mencionamos anteriormente, si bien definitivamente mejoran ese ciclo de vida de desarrollo, se centran más en ese ciclo externo. Ciertamente, si pensamos en el desarrollo ágil, la entrega continua, quiero decir, ese es su enfoque cuadrado en términos de tratar de mejorar la eficiencia de ese ciclo externo. Pero tienen beneficios en términos de ese ciclo interno. Y el ciclo interno se trata realmente de lo que estás haciendo como desarrollador individual. Vale, tengo que hacer algún cambio en ti, tengo que agregar una nueva capacidad. Tengo que solucionar algún problema que apareció en nuestra suite de pruebas. Hay un incidente y tengo que investigarlo, o estoy tratando de eliminar alguna forma de deuda técnica dentro de una aplicación o conjunto de servicios. Entonces, ese es realmente el enfoque en términos de los desarrolladores individuales reales cuando realmente llegas a ese punto, estás escribiendo el código, estás más cerca de la fuente del código. Y, por supuesto, lo que todos queremos hacer es asegurarnos de que seamos tan rápidos, tan eficientes como sea posible dentro de ese ciclo interno. Una vez que tenemos una gran comprensión en términos de la tarea que tenemos por delante, una vez que tenemos un contexto completo, realmente podemos ser muy eficientes, muy productivos. Entonces sabemos exactamente lo que estamos haciendo. Podemos ponernos en marcha, estamos frente a nuestro IDE y realmente podemos escribir nuestro código, probarlo, iterar y hacerlo de manera muy eficiente. Obviamente, hay desafíos en términos de, y supongo que los principales desafíos que enfrenta la gente son interrupciones en términos de ese flujo donde tienes que cambiar de contexto. Obviamente, la mayoría de las organizaciones tienen, tenemos interrupciones planificadas donde tenemos reuniones para actualizar a las personas sobre el progreso, pero podemos tener interrupciones en términos de personas que nos hacen preguntas, ya sea que los miembros de nuestro equipo nos hagan preguntas. Y, por supuesto, puede haber cosas que no entendemos. No tenemos un contexto completo. No tenemos una comprensión completa y luego tenemos que ir y tratar de completar los vacíos en nuestro conocimiento para lograr la tarea que estamos analizando. Y realmente se trata de cómo podemos minimizar esas interrupciones para que todos tengan contexto y tengan ese flujo rápido en términos de cómo están escribiendo software. Es un dibujo animado que uno de mis colegas me señaló. Entonces, en términos de cómo realmente pensamos en cómo escribimos software en términos de hablar de eso en un flujo. Entonces, obviamente, cuando estamos escribiendo software, tenemos algún tipo de pensamiento de cielo azul.

Estamos pensando en la mejor manera de escribir este método, cómo se verá esta clase, cómo puede encapsular, cómo podemos hacer que nuestro código sea más fácil de leer, más fácil de cambiar, por ejemplo. Y eso es genial. Pero la realidad a menudo es que pasamos mucho tiempo tratando de entender antes de poder ser realmente productivos. Y obviamente eso puede ser cosas muy básicas como tratar de entender algo sobre el lenguaje o la pila tecnológica en la que estás involucrado.

Quiero decir, puedo recordar que al principio de mi career, un desafío real, ya sabes, uno de los momentos más estresantes que tuve fue trabajar en un sistema de comercio de opciones. No era una parte central de nuestro negocio, pero de vez en cuando me enviaban a un sótano en Zurich o Frankfurt y tenía que sentarme allí un domingo tratando de arreglar este sistema de comercio que había sufrido algún tipo de falla y tenía que hacerlo funcionar para el lunes. El código en sí era relativamente complejo, pero los cambios que tenía que hacer eran muy, muy simples, pero solo podía hacer esos cambios muy simples una vez que tenía una comprensión completa de lo que estaba causando este problema. Así que, ya sabes, pasé mi tiempo tratando de entender esa base de código para poder hacer un pequeño cambio y poner el sistema en funcionamiento.

Y esa es básicamente la realidad para muchos de nosotros. Vivimos en una era de software, esencialmente todo está impulsado por software de alguna manera. Por lo tanto, hay una gran demanda para iterar y mejorar nuestras soluciones de software, lo que lleva básicamente a que haya mucho más código por ahí de lo que solía haber. Tenemos muchos más desarrolladores y hay una complejidad adicional. Y en términos de si miramos los estudios de personas como Microsoft, este es de Stack Overflow, en términos de la perspectiva del desarrollo, las personas pasan el 75% del tiempo tratando de entender su código en lugar de escribirlo realmente. Entonces, nuevamente, lo que idealmente queremos hacer es cambiar esas métricas para poder escribir código de manera más efectiva.

Entonces, ¿cómo podemos ayudar a las personas a comprender su código más fácilmente? Bueno, esto es básicamente desde una perspectiva de Sourcegraph, nuestro objetivo. ¿Cómo podemos ayudar a las personas a obtener contexto, a comprender más rápidamente para que puedan pasar más tiempo escribiendo código? Entonces, ¿cómo lo hacemos? Bueno, básicamente lo que hacemos es tener una plataforma de búsqueda universal. Y básicamente lo que eso permite a nuestros clientes, a los desarrolladores que utilizan esta plataforma es buscar en todo su código. Todos sus repositorios, independientemente, en realidad, de qué host de código están utilizando para el control de origen, pero sus repositorios de front-end, sus repositorios de backend, los diferentes servicios que componen su aplicación, para que puedan obtener una mejor comprensión, ayudarles a responder preguntas, básicamente. Entonces, ¿cómo se implementa este servicio? ¿Cómo lo usa alguien, quién más está usando este componente en particular? ¿Quién más está usando esta función o esta llamada de API de backend? ¿Cómo lo uso? Ayudando a las personas a obtener esa comprensión más completa en términos de, para que puedan llevar a cabo su desarrollo, realmente entregar código de aplicación real.

Así que voy a sumergirme, dar algunos ejemplos muy simples de cómo podríamos usar esta plataforma. Ahora, no soy un desarrollador de React, pero si lo fuera, y así, lo que puedo hacer con Sourcegraph, puedo hacer algunas consultas muy simples. Este sistema que estamos viendo aquí en realidad tiene alrededor de 2 millones de repositorios de GitHub indexados. Así que 2 millones de repositorios públicos de GitHub y GitLab. Sé que Formic es una biblioteca de React. Así que puedo hacer una consulta muy, muy simple para saber dónde ocurre en mi base de código. Puedo hacer una consulta un poco más compleja para ver, en realidad una consulta real en términos de ver dónde se importa. Entonces, qué código es realmente importante esa biblioteca dentro de mi código. En este caso, estamos haciendo una consulta de expresión regular muy simple para mostrar dónde en ese código ocurre. Si queremos profundizar y ver realmente, parecer funciones específicas de React, nuevamente, consultas muy simples, pero nuevamente, inmediatamente me dan información sobre mi base de código en términos de dónde puedo ir para encontrar información sobre cómo alguien ha usado realmente esa función. Por supuesto, desde una perspectiva de React, esto es muy básico.

Pero por supuesto, en ese momento, me permite realmente adentrarme en el código. Ahora puedo comenzar a ver los otros símbolos que se definen dentro de este código. Así que ahora estamos yendo más allá de la simple búsqueda, y también hacia la capacidad que esperarías dentro de tu IDE en términos de navegación de código.

La diferencia clave aquí es que en realidad estamos proporcionando navegación de símbolos en todo tu código, no solo en los repositorios que tienes en tu estación de trabajo, tu computadora portátil, que estás utilizando dentro de tu IDE, sino en código que, ya sabes, tal vez se encuentra fuera de tus equipos o código que no necesitas modificar con frecuencia. Entonces, nuevamente, te permite acceder a ese código tanto en términos de búsqueda, como en términos de navegación de código.

Y en cuanto a React, en realidad usamos React dentro de Sourcegraph en términos de nuestra interfaz de usuario. En realidad, una de las cosas que hicimos hace unos seis, probablemente ocho, 12 meses, fue cambiar cómo usamos React. En realidad, estábamos usando componentes de clase en lugar de componentes de función. Entonces, nuevamente, en este caso, lo que puedo hacer es buscar, nuevamente, esto es en todos estos 2 millones de repositorios, buscar dónde estamos usando componentes de función. Pero lo que hacemos con Sourcegraph no es solo proporcionar la búsqueda, no solo proporcionar la navegación de código, sino también permitirnos usar la búsqueda para impulsar otras capacidades.

Entonces, en este ejemplo en particular, estábamos migrando de un patrón de código a otro. Entonces, lo que también podemos hacer con la búsqueda es mostrarnos cómo estamos rastreando, cómo estamos monitoreando esa migración en particular. Entonces, una migración de patrón de código en este caso. Pero también puede ser en términos de cómo estamos cumpliendo con las mejores prácticas en términos de asegurar que nuestro código tenga metadatos relevantes. O cómo estamos migrando de una versión de biblioteca a otra en toda nuestra base de código. Entonces, lo que podemos hacer, porque tenemos todo el código, todo el historial de confirmaciones que podemos buscar e indexar, es comenzar a crear vistas de series de tiempo en esa base de código.

Entonces, en este caso en particular, estamos mostrando cómo se está migrando desde nuestra interfaz de usuario en términos de nuestro componente de clase a un componente de función. Entonces, básicamente, esto nos está dando una vista en términos de nuestra base de código en constante cambio. Y nos permite, si somos responsables de esa iniciativa en particular, tomar decisiones. ¿Está avanzando tan rápido como queremos? Si no es así, ¿por qué? ¿Qué acciones podemos tomar para cambiar o impactar la velocidad de cambio para esta iniciativa en particular?

Y finalmente, una de las otras cosas que podemos hacer con la búsqueda es ayudarnos a automatizar cambios en toda nuestra base de código, en muchos repositorios. Entonces, en este caso, si observamos... En este caso, lo que estamos haciendo es tener un script, básicamente. Y esencialmente estamos usando ese script para averiguar en qué repositorios necesitamos hacer cambios. Y luego definir un conjunto de pasos para realizar esos cambios en todos esos repositorios de código. Automatizando cambios en múltiples repositorios. Y luego permitiéndonos monitorear cómo avanzan esos cambios a través del proceso de revisión y la canalización de CI relevante. Entonces, el objetivo realmente es permitir, desde la perspectiva de un desarrollador, que usemos una herramienta para ayudarnos a enfocarnos en trabajos de mayor valor que quizás refactorizaciones de código más básicas que de otra manera no ocurrirían o que requerirían que nos comuniquemos con muchos equipos diferentes para que realicen esos cambios y acepten y revisen esos cambios. Así que, una breve presentación de la plataforma Sourcegraph.

Así que me gustaría agradecerte por tu tiempo. Entonces, nuevamente, desde la perspectiva de Sourcegraph, nuestro objetivo es ayudar a mejorar la eficiencia de ese bucle interno. ¿Cómo podemos ayudar a los desarrolladores a comprender su código, obtener contexto, básicamente entrar en flujo, permitir que sus colegas respondan sus propias preguntas en lugar de interrumpirte para hacer preguntas sobre la base de código. Me encantaría que vayas a sourcegraph.com para usar la búsqueda universal en más de 2 millones de repositorios. Eso incluye muchos repositorios de React. Por ejemplo, todos los repositorios de Facebook que son públicos. Adelante, pruébalo, y observa qué impacto tiene en tu propio ciclo de desarrollo. Y solo quiero decir, muchas gracias por tu tiempo. ♪♪♪ ♪♪♪