Enfoque técnico

En este sector, para tener “código que funciona” basta con un perfil júnior competente. “Código que funciona” solo significa producir el resultado correcto para un sprint, una funcionalidad, un escenario de usuario. Pero la vida del software no es un único sprint. Tres meses después, cuando se agrega una nueva funcionalidad; seis meses después, cuando hay que absorber un pico de tráfico; un año después, cuando llega la factura de la deuda técnica: es entonces cuando se hace visible el abismo entre “código que funciona” y “código de calidad”. El primero genera un nuevo error cada vez que se toca; el segundo sigue creciendo en silencio. En la cultura de ingeniería de Partnerfy, la palabra “funciona” nunca se usa sola: se reescribe como “funciona y sigue siendo barato de mantener”, un compromiso por escrito. El primer día y el tercer año forman parte de nuestro contrato por igual.

Hay una verdad que el sector del software ha ignorado durante años: el código escrito deprisa, estructuralmente débil y sin documentar “funciona” el día de la entrega. El cliente está contento, la agencia está contenta y el equipo de desarrollo está contento. Pero ese día se ha activado una bomba de tiempo. Las estructuras que el sector llama “código espagueti”, aunque parezcan libres de errores el primer día, se convierten poco a poco en edificios en los que no se puede clavar ni un clavo: torpes, costosos y frágiles. Agregar una nueva funcionalidad pasa a ser “primero, entender el código”; corregir un error existente, “primero, averiguar dónde se puede tocar”. En la literatura de ingeniería, esto se llama “deuda técnica”. En Partnerfy conocemos la responsabilidad que recae sobre cada módulo que escribimos. Por eso asignamos una sola tarea a cada clase, mantenemos cada función lo más pequeña posible y aplicamos a cada nombre los estándares de la literatura técnica. Tres años después, cuando otra persona abra el proyecto, debe poder leer qué hace el código, aunque nosotros ya no estemos allí.

La pantalla de aprobación del panel ID.Partnerfy es el resultado más concreto de nuestra arquitectura de alianza. Por cada módulo que desarrollamos, usted ve cuatro cosas en el panel: (1) la URL de staging, un enlace de vista previa que muestra la forma final del proyecto antes de su publicación; (2) las notas de desarrollo, con las funcionalidades agregadas o corregidas en este sprint; (3) los informes de pruebas, con los resultados de nuestras pruebas automatizadas; (4) el botón Publicar: rojo, grande y destacado. Mientras no haga clic en ese botón, el módulo no produce ningún cambio en el sistema en producción que ve su cliente. En cuanto lo haga, se inicia el proceso de despliegue automático, el cambio de versión se realiza sin tiempo de inactividad (zero-downtime) y, al terminar, recibe una notificación en el panel. Si lo desea, puede abrir la autorización de este botón a determinadas personas de su equipo. Que haga clic su responsable de cuenta, su responsable de producto o incluso su cliente final es una decisión organizativa suya. Pero, sea quien sea, en ese mismo instante la cadena de autorización queda registrada.