Una variable CSS, cinc rondes de revisió i una cadena d'eines de Swift que va mentir
GeekBye v2.0.7 va fer que tota la superposició fos translúcida de manera ajustable — cosa que sona com un canvi de CSS d'una línia i que en absolut ho va ser. La història de veritat és el que va detectar la revisió de codi: dues superfícies que es negaven a esvair-se, una barra de gravació que es veia malament amb la mateixa opacitat i un binari compilat que va oscil·lar 672 bytes perquè la nostra pròpia documentació va indicar a un revisor la versió de Swift equivocada.
"Fem la superposició translúcida" és el tipus de tasca que sona com un control lliscant i una propietat opacity de CSS. GeekBye v2.0.7 va llançar exactament aquest resultat de cara a l'usuari — un únic "mode clar" ajustable que et permet veure a través dels panells de l'assistent el que hi ha darrere. Però la part interessant d'aquest llançament no és la funcionalitat. Són les cinc rondes de revisió que van fer falta per fer-ho bé, i una batalleta sobre un binari compilat que va canviar de mida perquè la nostra pròpia documentació va mentir a un revisor.
La manera correcta de fer translúcida tota una interfície
La versió ingènua d'això és escampar un valor d'opacitat per cada component de panell i donar-ho per fet. Això és una trampa de manteniment: una dotzena de valors codificats de manera fixa que se separen l'un de l'altre en el moment que algú en toca un.
En canvi, la v2.0.7 fa servir una sola utilitat CSS compartida i un token per superfície. Hi ha una única classe overlay-surface que calcula el fons d'un panell a partir de dues propietats personalitzades: una opacitat base que cada superfície declara per si mateixa (la barra de control, el xat, les bombolles de transcripció, els blocs de codi, etc., cadascun tria la seva), i un multiplicador d'alfa global que va sobre l'arrel de la superposició i representa la configuració del control lliscant de l'usuari. Cada superfície llegeix el mateix multiplicador; cadascuna manté el seu propi caràcter. De manera crucial, només s'escala el fons del panell — el text, les icones i el backdrop-blur es mantenen totalment renderitzats, així que "translúcid" mai vol dir "il·legible."
Dues decisions d'aquest disseny mereixen menció perquè són la diferència entre una funcionalitat que ajuda i una que genera tiquets de suport:
- El valor per defecte és totalment opac. La configuració d'opacitat es llança al 100% — una no-operació. La superposició de ningú es va tornar transparent de sobte en actualitzar; la translucidesa hi és quan la vols i és invisible fins llavors.
- La configuració es valida de manera defensiva. Hi ha una única font de veritat per al mínim, el màxim, el valor per defecte i el pas, i un normalitzador que protegeix el cas buit/absent. Això importa per un parany de JavaScript:
Number(null)és0, així que una configuració absent coercida de manera ingènua faria saltar la superposició al seu estat més transparent en lloc del seu valor per defecte. El normalitzador ho detecta abans que pugui passar.
Arrossega el control lliscant i tota la superposició es re-tinta en viu, a mig de la gravació, perquè cada superfície està subscrita a la mateixa configuració. Sense reiniciar, sense recarregar.
El que va detectar la revisió (i el que una prova amb un sol monitor mai hauria detectat)
Aquí és on "una variable CSS" va deixar de ser simple. Van sorgir tres errors a la revisió, i dos són la mateixa lliçó amb barrets diferents.
Un panell que no s'esvaïa. La superposició de dreceres de teclat es mantenia tossudament sòlida mentre tota la resta es tornava translúcida. La causa: es renderitza fora del subarbre del DOM que porta la variable d'opacitat, així que mai va heretar el valor que baixava en cascada des de l'arrel de la superposició. Les propietats personalitzades de CSS s'hereten a través de l'arbre del DOM — i si un node no és realment descendent d'on has establert la variable, silenciosament no rep res. La solució va ser establir la variable localment també en aquell panell.
Una tonalitat de hover que desapareixia. Els botons Fn/Assist van perdre la seva lluïssor cian de hover. La utilitat de translucidesa establia el fons amb !important (ho ha de fer per guanyar contra els valors per defecte de la superfície), i això atropellava la tonalitat de fons hover: del mateix element. Col·lisió d'especificitat. La solució va ser fer la tonalitat de hover igualment emfàtica perquè pogués recuperar el guany en el hover.
Tots dos són la mateixa veritat subjacent: una cascada de variables CSS és una frontera de correcció real, no un detall d'estil. L'herència i l'especificitat decideixen si el teu valor arriba tan sols a l'element, i cap de les dues apareix en una captura de pantalla fins que és errònia.
La mateixa opacitat, un aspecte diferent. El més subtil: la barra de gravació i la barra inactiva estaven establertes a la mateixa opacitat base, i tot i així es veien visiblement diferents. Per què? La píndola de gravació feia servir un backdrop-blur més fort, i un desenfocament fort sobre un fons fosc tendeix cap a un resultat més fosc — així que una alfa igual produïa una aparença desigual. També tenia una vora tènue on la barra inactiva tenia una vora brillant d'anell degradat. La solució va igualar el nivell de desenfocament i l'anell. La lliçó va calar: una alfa igual no és una aparença igual un cop entra el desenfocament. La translucidesa és un sistema d'efectes que interactuen, no un sol número.
El binari que va canviar de mida perquè la documentació va mentir
Ara la batalleta, i és del meu tipus preferit — aquella on l'utillatge i la documentació no concorden i un revisor curós queda atrapat en el foc creuat.
GeekBye distribueix alguns binaris de Swift precompilats (ajudants natius per a coses com la detecció de reunions). Com que un binari compilat està comitejat al repositori, cada desenvolupador l'ha de compilar amb exactament la mateixa versió de Swift — cadenes d'eines diferents produeixen bytes diferents a partir d'un codi font idèntic, i això significaria un conflicte de git fantasma cada vegada que algú recompila. Així que hi ha un script que aplica una versió específica: Swift 6.3.x, comprovada en temps de build.
Durant la revisió d'aquest llançament, un revisor va assenyalar que un binari s'hauria de recompilar per coincidir amb "la cadena d'eines exigida pel repositori." El desenvolupador va fer exactament això — i la mida del binari va canviar de 89,184 bytes a 88,512. El missatge del commit fins i tot deia que estava "restaurant la sortida estable en bytes" recompilant amb Swift 6.2.1, "la cadena d'eines exigida pel repositori."
Excepte que 6.2.1 era la versió equivocada. L'script d'aplicació del build requeria 6.3.x. El problema era que la documentació en prosa — el README i la guia de col·laboradors — encara deia 6.2.1 en un parell de llocs. Així que un revisor conscient i un desenvolupador conscient, tots dos intentant fer el correcte, van seguir la documentació directament fins a comitejar precisament l'artefacte que l'script d'aplicació existeix per rebutjar. Un binari de 6.2.1 en un repositori de 6.3.x és la desviació exacta que trencaria la recompilació neta de qualsevol altre desenvolupador.
El commit següent ho va arreglar — i la solució és el que importa. No es va limitar a recompilar el binari de tornada a la seva forma de 6.3.x (mida restaurada a 89,184, just on havia començat). També va corregir les referències obsoletes a "6.2.1" a la documentació perquè el parany no es pogués tornar a activar. El binari va oscil·lar 672 bytes i tornar en dos commits, i l'error real mai va ser el binari. Va ser que dues fonts de veritat — l'script d'aplicació i la documentació escrita — no concordaven, i un humà es va refiar de la incorrecta.
Tres coses que va ensenyar aquest llançament
- Una cascada de variables CSS és una frontera de correcció. Dos dels tres errors de la revisió es reduïen a una variable que no s'heretava i un
!importantque atropellava un estat de hover. Si un valor ha d'arribar a un element a través de l'herència o guanyar per especificitat, aquell camí és lògica — verifica'l com a lògica, no com a estil. - Paràmetres iguals poden produir resultats desiguals. La barra de gravació i la barra inactiva compartien una opacitat i tot i així es veien diferents perquè un desenfocament diferent canviava el resultat. Quan unifiques un sistema visual sobre un número, comprova que les altres variables al voltant de cada superfície no estiguin canviant silenciosament el que significa aquell número.
- Quan la documentació i l'aplicació no concorden, arregla la discrepància — no només el símptoma. L'error no era un binari dolent; era una documentació que anomenava la cadena d'eines equivocada i un script d'aplicació que deia el contrari. Recompilar el binari tracta el símptoma. Fer que cada font de veritat concordi és la solució de veritat, perquè el proper revisor també es refiarà de la documentació.
GeekBye v2.0.7 va llançar la translucidesa uniforme, amb tots els casos límit revisats i la documentació de la cadena d'eines endreçada. És l'últim dels llançaments d'"artesania tranquil·la" abans del sprint de fiabilitat que va seguir. Per als fonaments que hi ha a sota, mira què cal realment per a una versió 2 (v2.0.0); per al llançament germà de poliment, programari tranquil: la solució del parpelleig i el xip de mode de resposta (v2.0.3 + v2.0.5); i per saber com la superposició es manté amagada en una trucada, com romandre invisible durant la compartició de pantalla.
