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

Rate this content
Bookmark

La transición de una arquitectura monolítica a un enfoque basado en servicios comenzó hace varios años. La ventaja de un enfoque basado en servicios es aumentar la agilidad y acortar el ciclo de desarrollo de construcción y lanzamiento. Y más recientemente, el surgimiento de micro frontends significa que este enfoque no solo abarca la aplicación backend, sino también el desarrollo frontend. Sin embargo, un efecto secundario es el aumento de la complejidad de la base de código. Esto resulta en desafíos en términos de visibilidad sobre cómo se relacionan los componentes, quién es el propietario de un componente y el impacto de las actividades en los componentes dependientes. Esta sesión abordará estos desafíos y lo que se necesita para mantener la velocidad de desarrollo individual.

19 min
24 Oct, 2022

Comments

Sign in or register to post your comment.

Video Summary and Transcription

Podemos mejorar la eficiencia de los desarrolladores ayudando a las personas a comprender el código de manera más efectiva a través de software de código abierto, desarrollo iterativo, infraestructura en la nube, integración continua y arquitectura basada en servicios. El ciclo de vida del desarrollo de software consta de un bucle externo centrado en los esfuerzos del equipo y un bucle interno para los desarrolladores individuales. Una plataforma de búsqueda universal ayuda a los desarrolladores a comprender y buscar código, reduciendo el tiempo dedicado a la comprensión del código. Herramientas de navegación y automatización de código como Sourcegraph permiten a los desarrolladores navegar por el código, adherirse a las mejores prácticas y automatizar cambios en múltiples repositorios.

Available in English

1. Introducción al Desarrollo de Software

Short description:

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. Así que aquí está mi lista de cinco puntos. 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 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. Y, por supuesto, ha habido grandes cambios en cuanto a cómo las personas construyen aplicaciones de software. Hemos pasado a un enfoque más iterativo. 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 los dos últimos en términos de integración continua, entrega, muy alineados con el desarrollo ágil. Y finalmente, en términos de arquitectura basada en servicios.

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.

2. Construcción de Software y el Ciclo Interno

Short description:

Desde cliente-servidor hasta aplicaciones de tres niveles y aplicaciones de múltiples servicios, el objetivo es mejorar la encapsulación y desacoplar la lógica de la aplicación. El ciclo de vida del desarrollo de software consta de un ciclo externo y un ciclo interno. El ciclo externo se centra en los esfuerzos del equipo, mientras que el ciclo interno se trata de los desarrolladores individuales y sus tareas. El desafío es minimizar las interrupciones y mantener un flujo rápido en la escritura de software.

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.

3. Understanding and Searching Code

Short description:

A menudo pasamos mucho tiempo tratando de entender nuestro código antes de poder ser productivos. Existe una gran demanda para mejorar las soluciones de software, pero las personas pasan el 75% de su tiempo tratando de entender el código. Para ayudar con esto, tenemos una plataforma de búsqueda universal que permite a los desarrolladores buscar en todo su código y obtener una mejor comprensión de cómo se implementan y utilizan las cosas. Podemos utilizar consultas simples para encontrar información sobre bibliotecas o funciones específicas. Esto es especialmente útil para los desarrolladores de React.

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.

4. Code Navigation and Automation

Short description:

Podemos navegar por el código y buscar en todos los repositorios, incluso aquellos fuera de nuestros equipos. Sourcegraph ayuda con las migraciones de código, el cumplimiento de las mejores prácticas y la automatización de cambios en múltiples repositorios. Permite a los desarrolladores centrarse en trabajos de mayor valor y mejorar la eficiencia del bucle interno. Visita sourcegraph.com para experimentar la búsqueda universal en más de 2 millones de repositorios.

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. ♪♪♪ ♪♪♪

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

JSNation 2023JSNation 2023
29 min
Modern Web Debugging
Few developers enjoy debugging, and debugging can be complex for modern web apps because of the multiple frameworks, languages, and libraries used. But, developer tools have come a long way in making the process easier. In this talk, Jecelyn will dig into the modern state of debugging, improvements in DevTools, and how you can use them to reliably debug your apps.
JSNation 2022JSNation 2022
21 min
The Future of Performance Tooling
Top Content
Our understanding of performance & user-experience has heavily evolved over the years. Web Developer Tooling needs to similarly evolve to make sure it is user-centric, actionable and contextual where modern experiences are concerned. In this talk, Addy will walk you through Chrome and others have been thinking about this problem and what updates they've been making to performance tools to lower the friction for building great experiences on the web.
DevOps.js Conf 2022DevOps.js Conf 2022
31 min
pnpm – a Fast, Disk Space Efficient Package Manager for JavaScript
You will learn about one of the most popular package managers for JavaScript and its advantages over npm and Yarn.A brief history of JavaScript package managersThe isolated node_modules structure created pnpmWhat makes pnpm so fastWhat makes pnpm disk space efficientMonorepo supportManaging Node.js versions with pnpm
GraphQL Galaxy 2022GraphQL Galaxy 2022
31 min
Your GraphQL Groove
Building with GraphQL for the first time can be anywhere between daunting and easy-peasy. Understanding which features to look for in your client-side and server-side tooling and getting into the right habits (and ridding yourself of old habits) is the key to succeed with a team of any size in GraphQL.

This talk gives an overview of common struggles I've seen numerous teams have when building with GraphQL, how they got around common sources of frustration, and the mindset they eventually adopted, and lessons learned, so you can confidently stick with and adopt GraphQL!

Workshops on related topic

React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Top Content
Featured WorkshopFree
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
React Advanced Conference 2021React Advanced Conference 2021
168 min
How to create editor experiences your team will love
Workshop
Content is a crucial part of what you build on the web. Modern web technologies brings a lot to the developer experience in terms of building content-driven sites, but how can we improve things for editors and content creators? In this workshop you’ll learn how use Sanity.io to approach structured content modeling, and how to build, iterate, and configure your own CMS to unify data models with efficient and delightful editor experiences. It’s intended for web developers who want to deliver better content experiences for their content teams and clients.