Fet... fins que ja no ho és: com la majoria d'enginyers de dades gestionen les tasques

La majoria d'enginyers coneixen aquest moment. Acabes una tasca, funciona i el tiquet passa a Fet . Envies el codi i passes a la següent tasca.

Aleshores, unes setmanes o mesos més tard, alguna cosa canvia. Un requisit evoluciona, algú necessita ampliar el que has creat, apareix un problema en producció o simplement tornes a obrir el teu propi codi. I penses:

En què coi estava pensant?

...o alguna cosa una mica menys educada. Segons la meva experiència, el problema poques vegades és que no sabíem com resoldre'l. Mirant enrere, normalment podem detectar una o dues coses que faríem de manera diferent . No ens hem convertit de sobte en millors enginyers; simplement hem deixat de pensar tan bon punt la solució ha funcionat.

‍

Naturalment optimitzem perquè "funcioni".

Tots treballem amb persones capaces que resolen problemes complexos cada dia. Saber com fer que les coses funcionin rarament és el que falta, i no és que a la gent no li importi. En consultoria estem constantment equilibrant la qualitat, els terminis, les expectatives dels clients i les noves sol·licituds, i sempre hi ha un altre projecte esperant.

Per tant, és natural optimitzar per a "funciona", i aquest és el punt de partida correcte. El problema és quan "funciona" es converteix discretament en la nostra definició de "fet".

Allò que construïm continua evolucionant després d'entregar-ho: els requisits canvien, les dades canvien, els volums creixen i algú altre haurà d'entendre què hem fet. Molt sovint, aquest algú som el futur nosaltres.

Hi ha una diferència entre acabar una tasca i acabar una solució . De vegades la tasca està completa, però la solució mereix cinc minuts més de reflexió.

Cinc preguntes abans de donar-ho per fet amb dades

Normalment intento fer-me algunes preguntes abans de considerar que alguna cosa està acabada. No és una llista de comprovació formal, i no sempre l'encerto. Les preguntes simplement m'ajuden a sortir de la tasca per un moment i a mirar la solució des d'un angle diferent.

‍

Què podria fallar?

Naturalment, dissenyem per al camí feliç, i la producció té una manera de trobar l'únic escenari que no hem considerat . Una càrrega s'executa dues vegades i un informe mostra de sobte el doble d'ingressos. Una columna d'origen es canvia de nom durant la nit. Un fitxer arriba amb valors NULL on ningú els esperava, o una API simplement esgota el temps d'espera. Res d'això és exòtic.

Així doncs , més enllà de "funciona?", val la pena preguntar-se: "si no funciona, sabrem què ha passat?". Un registre útil o una simple validació sovint són la diferència entre un incident dolorós i una solució ràpida.

Què probablement canviarà?

Intentar predir tots els futurs possibles és una manera excel·lent de sobreenginyar qualsevol cosa. Però normalment podem detectar què és probable que evolucioni : una data o un identificador codificat, una regla de negoci enterrada en una consulta, un esquema d'origen, una suposició de volum que es compleix per a les deu mil files d'avui però no per als deu milions de l'any que ve.

Deixar aquestes coses senzilles sovint és la decisió correcta. El que importa és prendre aquesta decisió conscientment.

Confiem en això en la producció?

La qüestió no és si tècnicament pot funcionar en producció, sinó si ens sentiríem còmodes sabent que funciona aquesta nit sense que ningú ens miri.

Si això ens fa dubtar, normalment hi ha alguna cosa que val la pena tenir en compte: la validació, el registre, la gestió d'errors, què passa en una reexecució o aquella part fràgil que esperàvem que no es convertís en un problema. Tots ho hem fet.

Una prova senzilla: imagineu-vos que la feina falla a les 3 de la matinada. Qui ho descobreix i com? Si la resposta honesta és "el client, dilluns al matí", val la pena tornar-ho a mirar.

Ens sentiríem còmodes mantenint això?

Sovint parlem del "proper desenvolupador", però força sovint som nosaltres, sis mesos després, i molt menys indulgents. Entendrem per què es va prendre una decisió? Serà fàcil depurar errors? Canviar una petita cosa significarà canviar-ne cinc més?

En el treball amb dades, això apareix ràpidament: una transformació amb cinc CTE imbricats i sense comentaris, una columna anomenada flag2 o un pipeline on un petit canvi significa actualitzar tres quaderns i un tauler de control. Sovint, un nom clar, un comentari breu que expliqui per què o dividir una consulta gegant en passos és tot el que cal. Sembla teòric fins al dia que som nosaltres els que mantenim el que hem creat.

Ho presentaríem amb confiança a un client?

Probablement aquesta és la que més valoro. Imagineu-vos que el client pregunta: "Per què ho heu construït d'aquesta manera?", "Què passa si això falla?" o "Quant difícil seria canviar això més tard?". Ens sentiríem còmodes responent?

En projectes de dades, aquestes preguntes sorgeixen més sovint del que esperaríem. Per què aquest número no coincideix amb el del full de càlcul de finances? Què passa si la càrrega d'ahir a la nit falla? Podem afegir una nova font sense reconstruir-ho tot? Una resposta clara, fins i tot si és "hem acceptat aquest compromís a propòsit", genera molta més confiança que una solució polida que ningú pot explicar.

La solució no ha de ser perfecta, i la resposta no ha de ser impressionant. Però hem d'entendre i donar suport a les decisions que hem pres. Si no em sentiria còmode explicant una decisió a un client, és un senyal que m'hi he de tornar a pensar.

No es tracta de perfecció: es tracta de la qualitat de la nostra feina

Res d'això significa construir un programari perfecte, afegir més processos o convertir cada tasca en un taller d'arquitectura. La solució més senzilla sovint és la correcta. Un valor codificat pot estar bé, i una drecera temporal es pot justificar quan el context ho requereixi.

La diferència és si aquesta simplicitat va ser una decisió conscient... o simplement el primer que va funcionar.

Això és important perquè allò que construïm en consultoria s'utilitza, sovint durant anys. Un company d'equip, el client o nosaltres mateixos ho mantindrem, ho ampliarem i en dependrem. Val la pena ser una mica més reflexius sobre el que publiquem.

Quan els 5 minuts extra valen la pena

No totes les tasques mereixen el mateix nivell d'escrutini. Una anàlisi puntual o un prototip ràpid poden funcionar amb algunes dreceres. Amb el temps, he notat alguns signes que una tasca mereix una segona ullada:

• Funciona sense que ningú ho miri. Treballs programats, càrregues nocturnes, qualsevol cosa que pugui fallar silenciosament.
• Produeix xifres en què la gent confiarà. Informes, quadres de comandament, qualsevol cosa que acabi en la decisió d'un client.
• Altres construiran a sobre. Una taula compartida, una funció comuna, un model que altres equips reutilitzaran.
• És difícil de desfer. Eliminar dades, migrar un esquema, canviar alguna cosa de la qual depenen altres sistemes.

Quan una tasca compleix una d'aquestes condicions, aquests cinc minuts solen ser el temps més econòmic que hi dedico.

Una pregunta que intento fer més sovint

Encara paro massa aviat de vegades, i encara obro codi antic i em pregunto què estava pensant. Però he començat a fer-me una pregunta addicional abans de tancar una tasca:

De debò que ho he pensat bé?

De vegades la resposta és sí. Altres vegades em fa tornar enrere per afegir un registre, eliminar un valor codificat, afegir una comprovació de qualitat de dades o provar un altre escenari. Res revolucionari, però ajuda la majoria de les vegades.

I, amb sort, la propera vegada que obri el meu propi codi, maleiré una mica menys.