¿Cómo saber si tu proveedor usa buenas prácticas de código?

Cuando una empresa externa desarrolla software para tu negocio, no basta con que simplemente “funcione”. Un sistema puede cumplir con los requerimientos visibles y aun así estar construido sobre una base débil, difícil de mantener, escalar o integrar en el futuro. Esto representa uno de los mayores riesgos al subcontratar: recibir un producto funcional, pero frágil y poco confiable a largo plazo.

En este blog técnico te explicamos cómo puedes identificar si tu proveedor realmente sigue buenas prácticas de desarrollo, incluso si no tienes conocimientos profundos de programación.

1. ¿Entregan documentación clara?

La documentación es la primera señal de profesionalismo. Si el proveedor no entrega al menos una guía técnica básica, eso es una alerta seria.

Qué deberías recibir como mínimo:

• Un archivo README técnico que explique cómo instalar, ejecutar y configurar el proyecto.

• Documentación de endpoints si se trata de una API (idealmente con Swagger, Postman o Redoc).

• Un resumen de los módulos o componentes del sistema, indicando su propósito y estructura.

• Diagrama de arquitectura (si el sistema es complejo) que muestre cómo se relacionan los distintos elementos.

Este tipo de documentación no solo es útil para tu equipo, sino esencial si otro proveedor necesita tomar el proyecto en el futuro.

2. ¿El repositorio tiene un historial limpio y organizado?

Solicita acceso al repositorio del código (GitHub, GitLab, Bitbucket). No necesitas entender el código para detectar señales de calidad. Revisa:

• Si usan ramas separadas para desarrollo, pruebas y producción.

• La claridad de los mensajes de commit. Mensajes bien escritos indican una metodología ordenada.

Buenos ejemplos de commits:

• feat: agrega validación de email en el registro
• fix: corrige error de formato en JSON de respuesta

Malos ejemplos:

• última versión
• arreglo rápido
• cambios varios

Un historial confuso y sin estructura puede dificultar la trazabilidad y mantenimiento del código.

3. ¿Implementan pruebas automatizadas?

Las pruebas automatizadas son clave para garantizar que el software funciona como se espera, y que los cambios futuros no romperán funcionalidades existentes.

Pide verificar si incluyen:

• Pruebas unitarias (para funciones o módulos individuales)

• Pruebas de integración (para verificar interacción entre componentes)

• Pruebas end-to-end (para simular el comportamiento del usuario)

• Informes de cobertura de código (porcentaje del código probado)

Incluso si no eres técnico, puedes pedir reportes generados por herramientas como Jest, Mocha, PHPUnit o Cypress.

4. ¿El código es mantenible y modular?

Un buen código no solo funciona, también está pensado para evolucionar. Observa (o pregunta) si usan:

• Arquitecturas modulares como MVC, DDD o servicios separados por capas.

• Separación entre lógica de negocio, interfaz de usuario y acceso a datos.

• Patrones de diseño comunes que favorecen la reutilización.

Si tienes dudas, considera solicitar una auditoría externa. Un code review por un tercero puede darte una visión clara sin necesidad de involucrarte directamente en el código.

5. ¿Usan linters y convenciones de estilo?

Cada lenguaje de programación tiene convenciones claras de estilo. Aplicarlas mejora la legibilidad del código y facilita el trabajo en equipo.

Pide confirmación de que usan:

• Linters como ESLint (JavaScript), Pylint (Python), PHPCS (PHP), etc.

• Herramientas de formateo automático como Prettier.

• Un archivo de configuración de estilo incluido en el repositorio (.eslintrc, .prettierrc, etc.).

También puedes solicitar logs o capturas que demuestren que estas herramientas están activas.

6. ¿Usan control de versiones y despliegues con CI/CD?

Las herramientas de Integración y Despliegue Continuo (CI/CD) permiten automatizar la verificación y publicación del código, lo cual reduce errores humanos.

Haz estas preguntas:

• ¿Usan pipelines de despliegue (GitHub Actions, GitLab CI, Jenkins)?

• ¿Tienen un entorno de staging para pruebas antes de pasar a producción?

• ¿Qué pasos de control de calidad automatizado aplican antes de liberar una nueva versión?

La respuesta positiva a estas preguntas indica un nivel de madurez técnica importante.

7. ¿Están dispuestos a permitir una auditoría externa?

Finalmente, la transparencia lo dice todo. Un proveedor profesional y seguro de su trabajo no tendrá inconveniente en compartir el código con tu equipo interno o un consultor externo para su revisión.

Si evitan este tipo de revisiones, postergan sin razón o ponen demasiadas barreras, probablemente hay aspectos del desarrollo que no quieren revelar.