5 consejos para elegir el código fuente abierto correcto

Los estudios realizados por Google muestran que, para muchos desarrolladores, encontrar código en línea consume una gran parte del día. Encontrar una función simple, una biblioteca, un paquete útil, un componente reutilizable o un tutorial útil de "cómo hacer" un blog no siempre es sencillo. Saber si puede confiar y utilizar el código que encontró puede ser aún más complicado.

Encontrar el código correcto generalmente significa recurrir a los dioses de Google u otros motores de búsqueda, realizar una consulta y cruzar los dedos para obtener una victoria rápida. Las consultas funcionales simples como "Javascript tiene propiedad propia" probablemente conducirán a diferentes foros y publicaciones de blog, mientras que las descripciones de niveles más altos ("React componente x") a menudo lo llevarán a GitHub o NPM.

Sin embargo, incluso después de encontrar el código correcto, confiar y usarlo es un problema completamente diferente. Para ayudar a comprender qué código puede usar realmente, reuní 5 parámetros que pueden ser útiles de considerar. Tomar la decisión correcta debe tener en cuenta estos parámetros (entre otros), así como la naturaleza de la tarea en sí. Aquí están las 5 claves que puede considerar para elegir el código correcto.

# 1. ¿Es legible el código?

El código legible significa mucho más que buenos comentarios y documentación. Significa que el código en sí debe ser legible para usted. Los diferentes parámetros de legibilidad pueden ser buenas convenciones de nomenclatura para identificadores, buen espaciado, lógica legible clara, alcances bien entendidos y más. La conclusión es que el código debe ser legible para ti . Cuando eliges un fragmento de código, incluso uno que funciona, pero no comprendes completamente cómo funciona, básicamente estás incorporando una bomba de tiempo de mantenimiento a tu base de código.

Depurar, modificar, actualizar y mantener el código que no puede leer es algo que debe evitar enérgicamente. La mejor manera de evitarlo será nunca dejarlo en primer lugar cuando sea posible.

# 2. ¿Se mantiene el código de forma activa?

Queremos que el código que elegimos esté "vivo". Es decir, queremos saber que los errores, problemas y actualizaciones se están manejando y este código será mantenido activamente por los desarrolladores que lo escribieron. Un buen ejemplo de un indicador de actividad pueden ser los problemas abiertos de GitHub, las solicitudes de extracción y el indicador Pulse. Los administradores de paquetes brindan información relevante para el mantenimiento, como la cantidad de dependencias y proyectos dependientes, pero aún así, luchan por presentar una métrica confiable en este campo.

Aún así, si un gran proyecto popular depende de otro paquete, podemos asumir que los problemas tienen una alta probabilidad de ser solucionados (sin embargo, todos recordamos el pad izquierdo). Sin embargo, al copiar código de desbordamiento de pila (que es un problema en sí mismo), no tiene forma de saber que puede confiar en que este código se mantendrá más que actualizarlo usted mismo cuando sea necesario (y donde lo haya duplicado).

Las pequeñas funcionalidades básicas simplemente no cambian tanto. Con este espíritu, los componentes reutilizables importados de Bit se basan en un control de versiones incremental simple que incrementa la versión del componente en 1 cada vez que su autor cambia algo. Mantener sus componentes en una versión de "última actualización" significa que, si se realizan buenas pruebas, su responsable de mantenimiento puede mantener su código de forma activa y, al mismo tiempo, actualizar incluso las funciones o componentes pequeños de su código sin romper nada.

# 3. ¿Está bien probado el código?

Elegir un código que funcione es probablemente nuestra primera prioridad. Las pruebas son una excelente manera de saber si el código que utilizo realmente hace lo que se supone que debe hacer. La descripción de las pruebas también presenta diferentes casos de uso y casos extremos que nos ayudan a saber cómo se comportará este código en diferentes situaciones. El uso de componentes probados hace que el software sea más fácil de mantener en su conjunto, lo que ahorra tiempo y problemas al intentar cambiar cosas antes de pasar a producción.

Los fragmentos de código copiados de la Web no suelen incluir pruebas. Rara vez, si acaso, las funciones copiadas de foros o publicaciones de blogs incluirán pruebas unitarias. Es muy posible que se prueben paquetes y bibliotecas, el problema radica en poder resolverlo rápidamente. Al explorar una biblioteca en GitHub, diferentes insignias o archivos en el repositorio pueden indicar qué tan bien y cuánto de este código se prueba. Aún tendremos que usar indicadores proporcionados por herramientas externas para averiguar si las pruebas pasaron o no. Al buscar un paquete, no existe realmente una forma confiable de saber qué paquete se prueba y si las pruebas se aprobaron de manera útil. Este es un gran problema en lo que respecta a la capacidad de detección de paquetes. Reutilizable

Cuando se busca un paquete, no existe realmente una forma confiable de saber qué paquete se prueba y si las pruebas se aprobaron de manera útil. Este es un gran problema en lo que respecta a la capacidad de detección de paquetes. Los componentes de Bit reutilizables se pueden probar si el desarrollador agrega dichas pruebas. Bit Scope ejecuta la prueba para que los indicadores verdes y la descripción de las pruebas se puedan mostrar en línea antes de elegir un componente del centro de la comunidad de Bit (o mediante la CLI cuando se usa en su máquina local de manera distribuida).

# 4. ¿Otros están utilizando el código?

La popularidad es algo en lo que confiamos los evolucionistas. La opinión pública es buena para tomar decisiones que ayuden a nuestra supervivencia. Si vemos a todos comiendo cierta fruta de un árbol, sabemos que probablemente no nos matará. Si vemos a todos huyendo de los arbustos, pronto podría seguir un tigre hambriento. Hasta cierto punto, lo mismo ocurre con la elección del código en 2017.

En los foros de programación, podemos utilizar diferentes indicaciones como una “V” que marca las respuestas correctas, el número de votos positivos y las opiniones vocales de los usuarios. Estas son características excelentes y tranquilizadoras para aumentar la probabilidad de que el código funcione bien. Cuando se trata de GitHub, podemos confiar en estrellas, colaboradores y otras métricas sociales para tener una sensación de confianza. Al buscar paquetes, un buen indicador sería el número de descargas de este paquete.

Los componentes de Bit que se encuentran en el centro de la comunidad de Bit presentan el número de descargas, colaboradores (en el nivel de alcance), "me gusta" simples y más (como se muestra en este Alcance de componentes de React). De cualquier manera, tenga en cuenta que las métricas sociales son una buena indicación, pero una verdad absoluta con respecto a la calidad del código. La gente a menudo se equivoca y la opinión pública puede cambiar más rápido de lo que pensamos.

# 5. ¿Está bien documentado el código?

La documentación hace que el código sea mucho más fácil de entender, usar y modificar. También es una gran indicación de la reflexión y el cuidado que puso en él el desarrollador que escribió el código. La documentación para el código que se encuentra en Stack Overflow o en diferentes publicaciones de blog puede consistir tanto en los comentarios en el código como en la respuesta real o el blog en el que se encontró. Cuando una respuesta del foro incluye una elaboración útil sobre el código que incluye, esto bien podría ser una documentación que valga la pena agregar incluso al copiar y pegar el código en sí (nuevamente, no copie y pegue el código).

Para los repositorios y paquetes de GitHub, las cosas son un poco más complicadas. Por lo general, los archivos readme y docs presentados en GitHub o NPM proporcionarán una indicación general sobre la calidad de la documentación. La documentación de los componentes de Bit se analiza desde el propio código y, por lo tanto, muestra la descripción real del componente atómico, y también puede incluir ejemplos de uso y una firma específica que incluye argumentos y retornos para diferentes funciones y comportamientos para los componentes de React y otros. De cualquier manera, elegir código documentado es una buena decisión siempre que sea posible.

Para los repositorios y paquetes de GitHub, las cosas son un poco más complicadas. Por lo general, los archivos readme y docs presentados en GitHub o NPM proporcionarán una indicación general sobre la calidad de la documentación. La documentación de los componentes de Bit se analiza desde el propio código y, por lo tanto, muestra la descripción real del componente atómico, y también puede incluir ejemplos de uso y una firma específica que incluye argumentos y retornos para diferentes funciones y comportamientos para los componentes de React y otros. De cualquier manera, elegir código documentado es una buena decisión siempre que sea posible.

Tomando la decisión

Al final del día, la memoria humana es limitada y realmente no tiene mucho sentido reinventar la rueda cada vez. Sin embargo, al encontrar y usar un fragmento de código fuente abierto, los indicadores anteriores pueden ayudar a garantizar que su aplicación permanezca segura, mantenible, funcionando y en buen estado.

Diferentes casos de uso significan dar diferente peso a los diferentes parámetros. Al elegir un paquete, será difícil saber qué tan probado, legible, documentado y mantenido activamente es. Al copiar código de un foro en línea, es posible que estemos priorizando la popularidad sobre las pruebas, el mantenimiento, etc. Los componentes de bits combinan información relevante para importar y reutilizar componentes y funcionalidades atómicas como descripción, ejemplos, descargas, dependencias, descripción de pruebas, resultados de pruebas y más. Al considerar cuidadosamente estos diferentes parámetros, podemos tomar una decisión informada y cruzar el laberinto de encontrar y elegir el código correcto para el trabajo.