Las dependencias son los cimientos sobre los que se apoya nuestro software. Dedicar tiempo a mejorarlas constituye una de las mejores inversiones que un programador pueda hacer.
Si queremos hacer aportes significativos, que tengan sentido y culminen en una pull request aceptada, resulta necesario emprender el fascinante viaje que implica el entender código ageno.
Llegar a comprender de qué manera el autor afronta el problema para resolverlo y qué patrones y paradigmas utiliza, nos brinda una comprensión más profunda del dominio de nuestro propio problema.
Al mismo tiempo, sumamos estrategias a nuestro arsenal y amplía nuestro criterio al aportarnos una mirada distinta.
Leer código escrito por otros es una de las experiencias más difíciles y al mismo tiempo más enriquecedoras a la que podamos someternos en nuestro oficio.
Al realizar aportes a los gigantes sobre cuyos hombros nos apoyamos, aliviamos su carga, y mejoramos no solo nuestro software, sino también todo software que comparta la misma dependencia.
De que nos sirve una cobertura de tests del 100% en nuestro código si se apoya sobre software frágil?
Con cada commit, entonces, mejoramos el ecosistema, dotamos de robustez a nuestro software y ampliamos recursos como profesionales. Todos salimos beneficiados:
- Nuestros usuarios.
- El autor.
- Los autores de otro software con la misma dependencia.
- Y sus usuarios.
Si hay una tarea que a todos nos provoca pereza, pero que al mismo tiempo más aporta a la calidad y confiabilidad del software son los test. Por lo que si nos sentimos especialmente proactivos y volutariosos, definitivamente hemos de empezar por ahí.
Recordemos que la cobertura de tests de las dependencias hace a la de nuestro propio código.
Existen una serie de tareas bastante arduas pero realizables utilizando un smartphone y que resultan mucho más gratificantes que las revistas de la sala de espera del dentista o la cola del supermercado haciendo nada.
Consiste en priorizar los issues. Un enfoque interesante es el de utilizar como criterio el sufrimiento de los usuarios, pero siempre recordemos que es más importante asegurarnos de acordar el criterio con el autor.
Al colaborar con esta tarea nos aseguramos de que se cuente con la información necesaria para enfocar los esfuerzos sobre lo más urgente empezando por las mejoras y correcciones más significativas.
Identificarlos, referenciarlos entre sí y cerrar todos menos uno, permite visualizar toda la información que hace al problema y concentrar toda nueva intervención en un espacio unívoco de discución.
Esto facilita la tarea de comprender el problema y permite a los usuarios un seguimiento más preciso de los avances.
Cerrar todo issue que resulte irrelevante o se encuentre publicado en el repositorio equivocado disminuye el ruido haciendo la vida más fácil a usuarios y programadores.
Lo ideal es hacerlo brindando una concisa y cordial explicación a quien lo haya abierto y referenciando el lugar más adecuado para su publicación cuando resulte pertinente.
Añadir etiquetas que permitan filtrar la lista facilita la tarea a la hora de emprender el trabajo. Se pueden utilizar diversos criterios y, como siempre, lo recomendable es ajustarse al existente o acordar uno con el autor.
Algunos de los criterios posibles son:
- Separar bugs de pedidos de funcionalidad.
- Identificar si resultarían en un salto de versión patch, minor o major según versionamiento semántico.
Quién haya pasado una tarde entera de frustración por no entender la correcta utilización de un método, conoce el valor de la documentación.
Nunca, nunca, nunca dejemos pasar la oportunidad de capitalizar ese sufrimiento invirtiendo cinco minutos más en mejorar la documentación para que nadie tenga que deccifrar el funcionamiento por segunda ves.
TL;DR Sea astuto, trabaje para los demás ;)
En suma. SIEMPRE hay algo que se puede hacer para mejorar el software. Con esta pequeña lista ya contamos con algunos indicios de por dónde empezar. Restan muchas opciones más como el análicis estático, la performance y la refactorización. Por ahora, los dejo para una futura actualización.