Steven
Steven6 min de lectura

Què és realment una release de 127 commits

GeekBye v1.7.0 van ser 127 commits en onze dies. Des de fora, això sembla un centenar de coses petites. Des de dins van ser dues grans funcionalitats entrellaçades al final — i una d'elles es va construir al lloc equivocat, i després es va arrencar i reconstruir a mitja release. Aquesta és l'anatomia d'una gran release.

Engineering
Release
Arquitectura
GeekBye Releases
Què és realment una release de 127 commits

Hi ha una versió d'aquesta entrada de blog que simplement enumera tot el que hi ha a GeekBye v1.7.0 — una pantalla d'inici redissenyada, un flux de calibratge, una barra lateral plegable, noves opcions de configuració, i així contínuament. Seria exacta i no t'ensenyaria res. Perquè la història honesta d'una release de 127 commits no és la llista. És la forma.

Aquesta és la forma. Cent vint-i-set commits sonen com cent vint-i-set coses petites. Gairebé mai ho és. v1.7.0 van ser dues grans funcionalitats, construïdes en paral·lel en branques de llarga durada durant uns onze dies, entrellaçades al final. Entendre una gran release significa entendre aquests dos fils — i l'únic lloc on vam construir alguna cosa al punt equivocat i la vam haver d'arrencar de nou a mitja volada.

Fil un: calibratge

El primer fil va ser el calibratge — una avaluació de veu amb IA de les teves habilitats de comunicació. Comences una trucada en directe amb un "coach de carrera" d'IA, treballes a través d'un conjunt estructurat de fases (escalfament, comportamental, comunicació tècnica, resposta sota pressió, definició d'objectius), i al final obtens una puntuació en sis dimensions: confiança, claredat, especificitat, implicació, compostura, rellevància. Per sota, també mesura mètriques de parla concretes — el teu ritme de parla, la freqüència de mots crossa, si les teves pauses es llegeixen com a estratègiques o dubitatives.

El resultat no és una nota, és un punt de partida. El calibratge produeix els teus punts forts, les teves àrees de creixement i — de manera crucial — una dificultat recomanada amb què començar a practicar. Calibra on hauria de trobar-te el producte. Cada habilitat torna com una targeta de retroalimentació desplegable amb un resum, un suggeriment concret i una frase realment citada de la teva pròpia trucada com a exemple. És la funcionalitat sobre la qual es construeix la resta de l'experiència de pràctica.

Fil dos: una finestra completament nova

El segon fil va ser un redisseny premium — i anomenar-lo redisseny el menysvalora. No era un canvi d'aparença de les pantalles existents; era efectivament una segona finestra d'aplicació, desenvolupada en sis fases explícites: una barra lateral plegable a l'estil Notion, un desplegable de capçalera que substituïa l'antiga llista de sessions, navegació a l'estil navegador amb historial i molles de pa, i reconstruccions premium d'Inici, Perfils, Reunions i Configuració.

Dues grans funcionalitats. Això és el que van ser realment 127 commits. I la part més difícil de publicar-les no va ser escriure'n cap de les dues — va ser l'entrellaçat. Les dues branques eren interdependents; una es va fusionar dins de l'altra, i la branca de calibratge va haver d'incorporar la branca main quatre vegades separades només per no desincronitzar-se mentre el redisseny es movia per sota seu. El nombre de commits no és el cost d'una gran release. Les branques de llarga durada i l'ordre d'integració sí.

La part que val la pena llegir: vam construir el calibratge al lloc equivocat

Aquí està l'error, i és un de bo perquè és molt comú.

GeekBye té una regla arquitectònica ferma: totes les operacions d'IA viuen al backend. El client és una closca prima que parla amb un servidor. Tothom ho sabia.

I tot i així, el calibratge es va construir primer a la base de dades local del client. Una taula dedicada, una migració de base de dades, un repositori de 254 línies, gestors IPC, i un banc de 515 línies de preguntes d'avaluació — tot vivint a la màquina de l'usuari. Funcionava. També violava silenciosament el contracte sobre el qual està construïda tota l'aplicació.

Tres dies després, un sol commit va eliminar 680 línies a través de vuit fitxers per traslladar-ho tot al backend, on les dades de calibratge es van convertir en un model del costat del servidor com cal, i la lògica de preguntes i la puntuació van passar a ser una qüestió del servidor. Un altre commit va eliminar de soca-rel el banc de preguntes de 515 línies del client. El diff és gairebé graciós: una inserció, sis-centes vuitanta supressions.

Ningú no es va proposar escriure 680 línies de codi d'un sol ús. Va passar de la manera que això sempre passa: la drecera del client està just aquí, és més ràpid prototipar en local, i "ja ho traslladarem al backend més endavant" sembla inofensiu. Però quan la teva arquitectura ja et diu on viu la font de veritat, construir-ho a qualsevol altre lloc no és una drecera — és refer feina que ja t'has programat a tu mateix. La lliçó que va quedar: posa-ho on diu el contracte, la primera vegada, fins i tot quan la versió local sigui més ràpida de muntar.

L'error que només la integració podia trobar

Un rebut més, perquè és el mode de fallada característic de les grans releases. Un cop el calibratge i la nova navegació es van connectar i van començar a funcionar de debò, l'aplicació va començar a activar un límit de peticions — HTTP 429 — sense cap raó òbvia.

La causa era pura integració. L'estat de calibratge s'obtenia a nivell de component, així que cada navegació el tornava a obtenir — i el strict mode de React, que deliberadament invoca dues vegades els efectes en desenvolupament per fer aflorar errors, ho va duplicar de nou. El resultat van ser de quatre a vuit peticions de calibratge idèntiques disparant-se per cada canvi de pantalla, prou per activar el limitador de peticions del servidor. La solució va consolidar l'obtenció a un parell de crides en muntar-se.

No hauries pogut trobar aquest error provant el calibratge sol, ni la navegació sola. Només existeix a la juntura — on es troben dues funcionalitats correctes de manera independent. Aquest és l'impost que cobra una gran release: l'última milla no és construir les funcionalitats, és descobrir tot el que només es trenca quan finalment són a la mateixa habitació.

Tres coses que ens va ensenyar una gran release

  1. Una release de 127 commits són dos o tres grans temes, no un centenar de petits. Troba els fils. La feina — i el risc — viu en com s'entrellacen, no en el recompte.
  2. Posa la font de veritat on diu el contracte que viu, la primera vegada. Vam eliminar 680 línies traslladant el calibratge del client al backend. La drecera local és refer feina que has programat per endavant; l'arquitectura ja et va donar la resposta.
  3. La integració fa aflorar fallades que l'aïllament no pot. La tempesta de 429 vivia a la juntura entre dues funcionalitats correctes i només va aparèixer un cop van funcionar juntes. Pressuposta una passada d'integració, no només proves per funcionalitat.

Aquest és un cosí de l'era v1 d'una història que tornaríem a explicar a una escala molt més gran — vegeu què cal realment per a una versió 2: 206 commits d'estats honestos (v2.0.0), on la mateixa veritat de "un gran nombre és realment unes quantes grans idees" es desplega per tota la reescriptura de la v2. Per al capítol anterior de la història de la v1, com transmetre un informe en directe sense el parpelleig (v1.6.13); i per a tot l'arc, l'anatomia de publicar programari fins a la perfecció.

Articles Relacionats

Vam esborrar 5.000 línies de codi d'àudio — i les transcripcions van començar a aparèixer duplicades
Steven
Steven7 min de lectura

Vam esborrar 5.000 línies de codi d'àudio — i les transcripcions van començar a aparèixer duplicades

GeekBye v1.6 va arrencar dos transcriptors Swift al dispositiu i els va substituir per una única canonada unificada — una eliminació neta de més de 5.000 línies, feta mentre la gent era enmig d'una reunió a l'aplicació. Llavors les transcripcions van començar a aparèixer dues vegades, perquè l'error va migrar a l'única capa que encara pensava que hi havia dos motors.

Enginyeria
Transcripció
Arquitectura
Una connexió perduda no hauria de fer petar tota l'aplicació — però la nostra ho feia
Steven
Steven7 min de lectura

Una connexió perduda no hauria de fer petar tota l'aplicació — però la nostra ho feia

Quan el nostre backend es va desconnectar en plena reunió, no només va aturar la transcripció: va fer petar tota l'aplicació. La causa era un únic esdeveniment sense gestionar, i la solució eren deu línies. Aquest és el grup de versions que va fer que GeekBye es mantingués amb la sessió iniciada i connectat a través de les coses que abans el mataven.

Enginyeria
Fiabilitat
Electron
La teva app de Mac obté accés al micròfon — i l'oblida a cada arrencada
Steven
Steven6 min de lectura

La teva app de Mac obté accés al micròfon — i l'oblida a cada arrencada

GeekBye va demanar permís per al micròfon, li'l vas donar i funcionava. A la següent arrencada: desaparegut. I l'app no apareixia enlloc a Configuració del Sistema → Micròfon. El culpable era una funció de seguretat de macOS que executava l'app en silenci des d'una ruta que desapareix — aquí tens el diagnòstic i la solució d'un sol avís.

macOS
Permisos
Enginyeria