El síndrome del impostor es real y afecta a los nuevos desarrolladores. Pasamos todo el camino a través de un tutorial, un campamento de entrenamiento o incluso un título, pero aún así nos alejamos de compartir nuestro código. Tememos los comentarios negativos sobre la calidad de nuestro código. Nadie sufre más por esto que los desarrolladores autodidactas. Debido a que no tenemos ninguna experiencia o capacitación “real” u “oficial”, consideramos que nuestro código es deficiente.
Estuve allí hace unos meses. Estaba trabajando en el desarrollo basado en pruebas de Harry Percival con Python . A pesar de que estaba siguiendo el tutorial, estaba consciente de compartir mi código. Aunque mi aplicación funcionaba como se esperaba, no quería compartir mi progreso. No quería que alguien me criticara por algún error obvio del que no me di cuenta. Quería que otras personas disfrutaran de mi producto, pero no quería que vieran lo pobre que soy como desarrollador.
Después de tomarme un descanso de mi propio proyecto, comencé a buscar otros proyectos en GitHub. Encontré algunos que tenían una pequeña imagen en sus páginas README.
Ahora, siendo el novato que era, pensé que esto era simplemente una imagen que Linus Torvalds te entregó en una unidad flash cuando te graduaste de la escuela "Real Developer". Nunca se me pasó por la cabeza hacer clic en él. Pensé que era una imagen estática alojada en algún lugar del repositorio. Más tarde, me topé con un proyecto que mostraba que la construcción estaba fallando.
¿Por qué alguien se tomaría el tiempo para agregar una imagen que diga que su compilación no es satisfactoria? ¿Por qué hacer el esfuerzo de quitar la otra imagen, poner esta? ¿Una imagen que dice que su proyecto está roto y lo muestra para que el mundo lo vea? Por pura curiosidad, busqué el formato sin procesar del README. Vi este código:
[](//travis-ci.com/username/projectname)Era lo suficientemente inteligente con las rebajas como para reconocer que se trataba de un enlace en el que se podía hacer clic. Entonces hice clic en el botón y me llevó a Travis-CI. De repente tuvo sentido para mí. Este botón no fue actualizado por el desarrollador del proyecto, Travis-CI lo actualizó. Es un botón dinámico.
Mi primera insignia
Entonces, una vez que me enteré de la insignia de compilación de Travis-CI, tenía que tenerla para mi proyecto. Después de todo, todo mi proyecto consistía en escribir y usar pruebas. Entonces, ¿por qué no tener algo que los ejecute automáticamente?
Así que configuré Travis-CI para ejecutar mis pruebas unitarias cuando presioné los cambios en GitHub. Justo en la parte superior de la página donde los ejecuta Travis-CI, está la insignia. Lo hice clic y obtuve la rebaja. Lo agregué a mi README. ¡Navegué a la página del proyecto en GitHub y VOILA! Allí estaba mi primera placa. ¡Me enganché!
La caza
Disfruté de que la insignia fuera una señal clara del estado actual de mi proyecto. Quería aprender más, así que fui a la búsqueda de otras insignias. Otra insignia común que encontré fue la cobertura de código. Travis-CI podría enviar el informe de cobertura a una herramienta llamada CodeCov. Podría obtener una insignia que indique la cobertura de sus pruebas, que se correlaciona con qué tan bien se prueba su aplicación.
También encontré insignias de licencia, y solo tenía sentido tener una insignia de licencia si tenía una licencia. Así que elegí una licencia y la agregué al repositorio. Obtener la insignia para eso requirió una búsqueda rápida en Google, y encontré esta esencia con todas las insignias de licencia comunes.
Con experiencia en seguridad en el ejército, sé que la mayoría de las vulnerabilidades provienen de software desactualizado. Como nuevo desarrollador, sé que esto también se aplica al software del que depende su software. Escuché sobre PyUp a través del podcast Talk Python to Me de Michael Kennedy . Cuando navegué al sitio, vi las palabras que comencé a amar "Gratis para código abierto". Estando a la caza de nuevas insignias, tuve suerte. Efectivamente, proporcionan una insignia, así que, por supuesto, la agrego al archivo README.
Finalmente, descubrí que se podía tener una insignia de estilo. Me había metido con Black antes, y encontré un ejemplo de la insignia de estilo y supe que tenía que tenerlo. Por mi propia integridad, quería asegurarme de que mi código siempre fuera compatible con el estilo de Black. Me enteré de la confirmación previa, que podría utilizar para formatear mi código incluso antes de confirmarlo. Después de sumergirme en el agujero del conejo precomprometido (que también ejecuta mi código contra bandit por seguridad y clasifica mis importaciones y requisitos), me sentí seguro de agregar la insignia negra a mi README.
El final resulto
El primer resultado de la caza de insignias es que tengo un proyecto de mejor calidad . Agregué una licencia a mi proyecto, me aseguré de que mis dependencias se mantuvieran actualizadas y mantuve el estilo de mi proyecto compatible porque quería las insignias.
Más notablemente, tengo más confianza en mi proyecto. Puedo hablar de ello sabiendo que no tiene grandes agujeros. Sé que es mucho menos probable que reciba comentarios sobre mi irresponsabilidad con respecto a la seguridad o mi falta de cumplimiento de estilo.
En pocas palabras, me siento mejor con mi código porque tengo esas insignias de GitHub.