Revisión de código y pruebas – Lecciones aprendidas (OSD600LAB_1)

Revisión de código y pruebas – Lecciones aprendidas (OSD600LAB_1)

En Q2BSTUDIO, empresa de desarrollo de software y aplicaciones a medida con especialización en inteligencia artificial y ciberseguridad, abordamos las revisiones de código como una actividad estructurada que combina pruebas funcionales, lectura del código y mejora de la experiencia de usuario. Nuestras áreas de trabajo incluyen aplicaciones a medida, software a medida, servicios cloud aws y azure, servicios inteligencia de negocio y soluciones de ia para empresas, lo que nos permite aportar una visión amplia y práctica durante las revisiones.

Método de revisión aplicado: primero leí el README del repositorio para entender la intención del proyecto y cómo debía funcionar la herramienta. Luego ejecuté pruebas locales con múltiples entradas: archivos individuales, directorios, rutas inexistentes, archivos grandes y casos límite para detectar fallos visibles. Después procedí a revisar el código fuente, centrándome en utilidades y en la lógica principal, con atención a manejo de rutas, gestión de errores y lectura de archivos.

Preferencia async versus sync: prefiero un enfoque asíncrono porque ofrece mayor flexibilidad. Con revisiones asincrónicas puedo probar y analizar con calma, documentar hallazgos y comunicarme con el propietario del repositorio cuando corresponda. Las revisiones síncronas son útiles para feedback rápido, pero el enfoque async facilita profundizar y proponer mejoras que afectan mantenibilidad y experiencia de usuario.

Experiencia al probar y revisar código ajeno: fue interesante y desafiante. Tuve que invertir tiempo en comprender la arquitectura antes de diseñar pruebas efectivas. El mayor reto fue distinguir comportamiento intencionado de defectos reales. Una sorpresa concreta fue que la herramienta omitía silenciosamente archivos mayores a 16KB sin avisos, lo que puede confundir a usuarios finales que esperan resultados completos o al menos un log que explique la omisión.

Qué ocurría al recibir revisiones: cuando otros comenzaron a revisar mi código me sentí al principio incómodo por los aspectos pendientes. Sin embargo, el proceso demostró ser constructivo y motivador. Comentarios sobre instrucciones de instalación poco claras o detalles de configuración llevaron a mejoras que facilitan la adopción del proyecto por terceros.

Problemas detectados y ejemplos técnicos: encontré una mezcla de fallos funcionales y problemas de usabilidad. Por ejemplo pasar una ruta inexistente provocaba excepciones no controladas porque se usaba fs.statSync sin comprobaciones previas. Se detectaron problemas de portabilidad por concatenación de rutas con la barra directa en lugar de usar path.join, lo que puede fallar en entornos Windows. A nivel de usabilidad el README carecía de instrucciones clave y conceptos como npm link estaban mal explicados. Finalmente readFileContents ignoraba silenciosamente ficheros mayores de 16KB, lo que puede producir salidas incompletas.

Documentación de incidencias: durante la revisión documenté varias incidencias con descripciones y pasos para reproducir. Entre ellas destacaron Tool crashes when given non-existent files por falta de manejo de rutas inválidas, Path concatenation in buildTree may break on Windows por uso incorrecto de separadores, readFileContents silently skips files larger than 16KB por límite no comunicado, y README has missing info and unclear instructions que dificulta la puesta en marcha. Estas entradas ayudan a priorizar correcciones y a mejorar la calidad general del proyecto.

Estado de las correcciones: no todos los problemas están resueltos todavía. Algunas tareas como actualizar la documentación son rápidas, mientras que arreglos relacionados con manejo de errores y compatibilidad multiplataforma requieren más tiempo y pruebas. El trabajo es incremental y se prioriza según impacto en usuarios y riesgo técnico.

Lecciones aprendidas: la revisión de código va más allá de encontrar bugs. Es clave mejorar la usabilidad, la documentación y la mantenibilidad. Probar proyectos de terceros aporta perspectiva sobre cómo diseñar mejores mensajes de error, cómo estructurar instrucciones claras y cómo prever escenarios de usuario reales. También reafirma que la compatibilidad cross platform y el manejo robusto de excepciones son esenciales para herramientas que pretenden ser fiables.

Cómo aplicamos esto en Q2BSTUDIO: en nuestros proyectos de Desarrollo de aplicaciones y software a medida y en soluciones de inteligencia artificial para empresas incorporamos revisiones de código sistemáticas, pruebas automatizadas, validación de límites y documentación clara para asegurar entregables de calidad. Complementamos esto con servicios de ciberseguridad y pentesting cuando la criticidad lo requiere, y con despliegues en servicios cloud aws y azure para entornos productivos.

Conclusión: una buena revisión de código combina pruebas prácticas, análisis del código fuente y atención a la experiencia del desarrollador y del usuario. Adoptar revisiones asincrónicas permite profundizar sin sacrificar la velocidad de entrega, y las lecciones obtenidas mejoran tanto proyectos propios como los de clientes que confían en Q2BSTUDIO para soluciones de software a medida, agentes IA, power bi y servicios de inteligencia de negocio.