Cómo Construir Tu Propio Proyecto de Código Abierto

Hola, mi nombre es Hung, soy el creador de JestPreview, una biblioteca que te brinda una experiencia de depuración visual al testing una aplicación de front-end. También soy miembro de BestOfJay.org, un sitio web que te ayuda a seguir el crecimiento del ecosistema de JavaScript. También estoy en Twitter, ¡conéctate conmigo!

En esta charla, quiero compartir contigo qué es JestPreview y por qué construirlo, las dificultades que tuve que superar al construir un proyecto de software de código abierto, lo que recibí de la comunidad, y algunos consejos si quieres construir el tuyo propio. Primero, ¿qué es JestPreview y por qué construirlo? El problema es que si eres un ingeniero, y si eres un ingeniero de front-end y escribes pruebas, tienes que trabajar mucho con la terminal de Node. Si encuentras un error, tienes que mirar el largo HTML en la terminal y es muy difícil depurar y corregirlo. Ni siquiera sabes cómo se ve tu aplicación cuando se ejecutan tus pruebas. ¿Alguna vez has intentado hacer clic en un botón pero no hay botón, solo un spinner que se carga en tu prueba? Entonces me hice esa pregunta, si Jest puede imprimir el HTML, ¿podemos renderizarlo en un navegador real? Y hasta ahora, la respuesta es sí, podemos. Como puedes ver, este es un caso de prueba escrito en la biblioteca de pruebas de React, la interacción del usuario está controlada por user-event. Y en lugar de usar screen.debug, usamos preview.debug para ver la interfaz de usuario real en nuestra aplicación en el navegador. Y cada vez que guardas, el navegador actualiza la interfaz de usuario casi de inmediato. Tiene muchos beneficios. El primero es que puedes depurar una prueba fallida mucho más fácilmente. Puedes saber cómo se ve tu aplicación. Por lo tanto, puedes escribir fácilmente tu próximo paso de testing. Por lo tanto, puedes ejecutar tus pruebas más rápido. E incluso si estás escribiendo pruebas unitarias o de integración, aún puedes ver la interfaz de usuario. Intenta cerrar la brecha entre las pruebas unitarias y las pruebas de integración con pruebas de extremo a extremo. En mi experiencia personal, escribo de 2 a 3 veces más rápido gracias a JustPreview. Quiero mostrarte una demostración. Como puedes ver, esta es una aplicación normal escrita en la biblioteca de pruebas de testing. En el lado derecho, puedes ver la interfaz de usuario que JustPreview te muestra. Permíteme ejecutar solo 1 paso y la prueba se ejecutará nuevamente. Y puedes ver que el número de conteo disminuye de 6 a 5. Permíteme disminuirlo nuevamente. Puedes ver que de 5, pasará a 4. Y eso es JustPreview.

Y ahora quiero compartir algunas dificultades que tuve que superar al construir un proyecto de software de código abierto. En primer lugar, es difícil porque cuando usas un marco y no necesitas entenderlo en profundidad, pero cuando construyes un proyecto de software de código abierto, es probable que necesites entenderlo en mucho, mucho detalle. A veces quieres hacer una pregunta, pero es probable que no encuentres una respuesta en Google o Stackoverflow.

Por ejemplo, así es como funciona el módulo CDF, pero cuando construí JustPreview para admitir el módulo CDF, tuve que profundizar en el código fuente del módulo CDF, y este es el código con el que tengo que trabajar para que JustPreview funcione con el módulo CDF. Pero es una buena oportunidad para aprender, porque cada vez que superamos un problema difícil, aprendemos mucho.

Lo siguiente es el tiempo. El software de código abierto requiere mucho tiempo, especialmente si tienes un trabajo a tiempo completo, por lo que debes administrar bien tu tiempo, y mi consejo es siempre tener un plan, y mi cita favorita es que un buen plan hoy es mejor que un plan perfecto mañana. Además, también creo que, dado que es un proyecto de código abierto, muchas personas vendrán a ayudarte, pero en realidad no es cierto para un proyecto de código abierto pequeño. Es posible que seas el único mantenedor. A veces solo quieres rendirte o archivar el proyecto. Pero en ese momento, recuerda por qué lo comenzaste en primer lugar. El éxito es financiero. Si solo lo haces por diversión, está bien. Pero si te tomas en serio trabajar en código abierto, puedes considerar patrocinadores de GitHub, Open Collective o incluso algún modelo freemium.

Quiero compartir lo que recibo al hacer código abierto. Primero es el conocimiento. Mucho conocimiento. Sé cómo funciona el Bundler en el fondo. Sé cómo procesar CSS en aplicaciones web modernas. Tengo que leer mucho código abierto, por lo que mejoro mis habilidades de lectura y desarrollo de código. Entiendo cómo funciona la herramienta en el fondo. Me convierte en un mejor programador. Luego viene la oportunidad. Recibo muchas oportunidades al hacer código abierto. Mi proyecto, Jazz Preview, fue nominado para el premio Most Exciting Use of Technology en los Open Source Awards en React Summit. Es simplemente emocionante y nunca lo había pensado antes. En cuanto a los trabajos, recibo muchas invitaciones para aplicar y es simplemente increíble porque no necesitas buscar trabajo, sino que el trabajo te encontrará. Y luego están las conferencias y eventos tecnológicos, tengo la oportunidad de participar en ellos. Además, tengo la oportunidad de conversar con muchos ingenieros excelentes, autores de bibliotecas de software de código abierto que uso a diario. Antes de hacer código abierto, nunca pensé que podría discutir temas técnicos con ellos.

Pero es genial haber conocido a algunos de ellos en persona. Es posible que reconozcas a algunos de ellos aquí. Y luego está el hecho de que recibo muchas cosas al azar en un día, que recibo algo como un agradecimiento por hacer esto, que hace mi vida mucho más fácil. Y eso realmente me motiva a seguir haciéndolo. Nunca había experimentado eso antes cuando solo tenía un trabajo de 9 a 5.

Entonces, ¿cómo hacerlo? Ahora quiero compartir algunos tips para construir tu propio proyecto de código abierto. Primero, ¿cómo elegir un proyecto de código abierto en el que trabajar? La respuesta es muy fácil, debe ser un proyecto que uses todos los días. Si quieres construir tu propio proyecto de código abierto, tu proyecto futuro debe resolver tus propios problemas. Es muy difícil contribuir a un proyecto del que no tienes contexto, simplemente elige uno proyecto que uses todos los días y contribuye a él. Y sabes que, en un trabajo diario, pasamos mucho tiempo en un problema en particular, y hay muchas posibilidades de que otras personas tengan el mismo problema. Así que simplemente hazlo de código abierto, y no necesita ser algo muy grande.

A continuación, comienza de forma sencilla. Ningún proyecto es complicado cuando se trata de trabajo. Simplemente comienza de forma sencilla, haz primero un MVP o una prueba de concepto, y mejóralo con el tiempo, y está bien si el código no está limpio en la fase inicial. Y si alguna vez te pierdes, está bien, eso es una señal de que vas a aprender mucho. A continuación está el mantenedor de archivos. Sabes, construir un proyecto de código abierto es difícil y estresante. Sería mucho más fácil para ti tener a alguien con quien discutir aspectos técnicos y motivarte a continuar con el proyecto. Y no comiences en la versión 1, porque un nuevo proyecto está lleno de pruebas de concepto y experimentos. v1, eso significa que tu software debe ser compatible con versiones anteriores cuando lanzas una nueva versión. Y en las versiones semánticas, el término en la relación de la versión principal es cero. Es para el desarrollo inicial. Y cualquier cosa puede cambiar, y la API pública no debe considerarse estable. Ahí puedes avanzar rápido. A continuación, cuando comienzas un proyecto para resolver un problema en particular, pero cuando lo usas como un usuario normal, sabes si es lo suficientemente bueno, o si necesitas ajustarlo o agregar más funciones para hacerlo más usable. Por ejemplo, cuando construí JustPreview, todo lo que quería era previsualizar la interfaz de usuario en Jest a Chrome, punto. Pero cuanto más lo uso, más funciones agrego para hacerlo más fácil de usar, como la recarga automática al guardar, procesar CSS, imágenes y agregar un nuevo modo automático, etc. A continuación, tienes un proyecto, pero puede ser subjetivo. Pregunta a tus amigos, colegas y tu red qué proyecto debería cambiar para ser más usable. Después de un tiempo, cuando tu proyecto obtenga más atención, presta atención a los problemas y las discusiones.

Y sabes, tu software está siendo utilizado cuando las personas comienzan a informar problemas y enviar Lo veo como magia cómo simplemente pones algo en GitHub y personas de todo el mundo vienen a ti y encuentran problemas o envían una solicitud de extracción. Y es muy importante guiar a las personas sobre cómo categorizar y encontrar problemas de manera eficiente. Y la reproducción es la más importante. Porque sin reproducción es muy difícil para el mantenedor corregir errores. Y hay muchas otras funciones de GitHub que te facilitan trabajar con código abierto, como etiquetas, hitos y GitHub actions.

El siguiente consejo es aprender de otros. Hay una famosa cita que dice que un buen artista copia y un gran artista roba. Así que no reinventes la rueda, hay mucho buen software ahí fuera que ya resuelve tu problema, aprende de ellos, lee su código fuente para ver cómo lo hacen. A continuación, debes escribir documentación. Es muy fácil para ti usar tu propio software, pero las personas de todo el mundo tienen casos de uso diferentes y especiales, por eso es importante qué problema intenta resolver tu proyecto. Describe claramente la instalación, el uso y cualquier advertencia que puedan encontrar en el documento. Si prefieres React, puedes usar DocuSource. Si prefieres Vue, puedes usar Vitepress. Ambos te ayudarán a crear documentación sin esfuerzo.

Y luego, compártelo con el mundo. Compártelo en Twitter, escribe algunas publicaciones de blog y comparte tu proyecto en un evento. Y por último, pero no menos importante, contribuye a Open Source hoy. Espero que te diviertas mucho y aprendas mucho haciendo software de código abierto. Así que gracias por tu atención. Si escribes, encuentras y pruebas, prueba JustPreview. Y si te gusta, por favor dale una estrella para apoyarme. Y las diapositivas están disponibles y son de código abierto en redadvance.hung.dev. ¡Gracias!