Hur observerbarhet ger utvecklare rätt mängd komplexitet

Även om vi ibland blandar ihop enkelt eller enkelt med en fantastisk utvecklarupplevelse, ibland är vad en utvecklare vill ha förmågan att dyka djupt in i komplexiteten, eftersom det är där hon får de insikter som behövs för att verkligen ta itu med ett problem.

Detta är argumentet Jean Yang, grundare och VD för Akita Software, gör, och hon har rätt. Även när branschen fortsätter att komma på nya sätt att förenkla utvecklingen genom verktyg med låg kod eller ingen kod, måste vi också hålla ett öga på saker som ger utvecklare den komplexitet de behöver för att göra sina jobb väl – ett exempel är observerbarhet.

SER: De bästa programmeringsspråken att lära sig – och de sämsta (TechRepublic Premium)

Värdet av att ha olika kategorier av utvecklarverktyg

Istället för att blanda de olika delarna av utvecklarupplevelsen (DX) till en enda stor boll, föreslog Yang att vi skulle dela upp utvecklarupplevelsen i minst två olika vägar:

När vi pratar om “utvecklarupplevelse” behöver vi verkligen dela upp dev-verktyg i två kategorier: de som förenklar saker och ting och de som hjälper utvecklare att engagera sig i komplexitet. DX-behoven är olika för förenklingsverktyg kontra komplexitetsomfamnande verktyg! I kategorin “förenkling” av utvecklingsverktyg finns alla typer av automationsverktyg: API:er som Stripe och Twilio; SaaS-produkter som Netlify; domänspecifika språk som GraphQL. Du vill att dessa verktyg ska vara så ett klick som möjligt och skydda utvecklaren från de flesta detaljer.

Det är här många människor stannar när de tänker på utvecklarupplevelsen. För flera år sedan kallade en kollega (Yehuda Katz) detta “utvecklarergonomi”, och namnet har fastnat för mig. Som Ben Kinsey definierade utvecklarergonomi är det “studiet av effektivitet i ens arbetsmiljö.” Så om verktyg/dokument/etc. gör livet lättare för utvecklaren, det är bra ergonomi.

Eller kan vara. Chris Ferdinandi har nämnt problemet med detta tillvägagångssätt: “Precis som skattesänkningar för företag ofta inte leder till nya jobb, utan leder istället till större bonusar för chefer eller aktieägarutbetalningar, [better ergonomics to yield] mer JS leder ofta till att utvecklare har lättare att skriva även JS, och cykeln fortsätter.”

Och, naturligtvis, “enklare” betyder inte nödvändigtvis en svart låda som abstraherar eller döljer all komplexitet. Faktum är att ibland vad du vill är raka motsatsen, som Yang fortsatte:

Det mest klassiska exemplet på ett utvecklingsverktyg i kategorin “komplexitetsomfattande” är en felsökning: den visar dig din stackspårning; det visar dig en samtalsgraf. Det låter dig komma dit du behöver genom att ge dig verktyg för att utforska ett komplext system. Observerbarhetsverktyg finns i denna kategori. När människor tänker på/letar efter utvecklarverktyg har de ofta förenklingsverktyg i åtanke. Men för vissa ändamål är det du behöver faktiskt ett komplexitetsomfamnande verktyg. Till exempel: övervakning kan bara ta dig så långt. Vid något tillfälle behöver du något som kan hjälpa dig grundorsaken.

Som sådan, skrev hon, behöver vi “Mer UX [user experience] konversationer om hur man hjälper utvecklare att omfamna komplexitet” samt “Mer kärlek och uppmärksamhet för komplexitetsomfattande utvecklingsverktyg, inte bara ställ-det-och-glöm-det-verktygen.”

Honeycomb CTO och medgrundare Charity Majors har betonat vikten av komplexitetsomfattande verktyg inom området observerbarhet. Observabilitetsdriven utveckling, enligt henne, är “aktivt instrumentering av kod för att kunna ha mer av en konstant ‘konversation’ med produktionssystem.” Det är att förstå hur ändringar i koden påverkar användare i realtid, driven av att utvecklare äger resultatet av koden de skriver, eftersom ingen annan är bättre positionerad för att fixa problem i den koden. Ingen annan vet det lika bra.

För att utvecklare ska göra sitt jobb bra måste de ha tillgång till komplexiteten i loggar, spår etc. Det är inte en fråga om att övervaka system efter utvecklingen; det bygger pågående insikter i utvecklingsprocessen genom dygdiga återkopplingsslingor.

Kort sagt, för Yangs poäng, låt oss för all del göra vissa aspekter av utvecklarupplevelsen så enkla som möjligt. För andra, men låt oss hålla saker komplexa.

.