Så förändrar versionskontroll av källkod designprocesserna

Historien bakom versionskontroll av källkod och dess effekter

Följande är en mycket förenklad genomgång av epokerna med versionskontroll. För att komma dit vi är idag fick utvecklare utstå mer än 30 år av framsteg som gick långsamt, och en mängd misstag gjordes under tidens gång.

I början utgjorde ändringar i versionskontrollmetoden en riktig plåga för utvecklare, som plötsligt ombads att ändra sitt sätt att skriva koden. Det resulterade i att många egon blev krossade, samtidigt som många nätter tillbringades med att gråta över världens orättvisa (eller utvecklingsteamets orättvisa).

1. Vilda västerns pionjärer, var och en för sig själv

I början fanns det inga riktiga metoder för versionskontroll, förutom att manuellt kopiera filer under ett annat namn. Processen var svårbegriplig – någon skrev en bit kod, och när den var klar, gavs utdatan (mjukvaran) bort till andra, som fick inkludera den i huvudfilen. Källkoden delades nästan aldrig.

2. Delad versionskontroll och strikt ägande

Snart kom verktygen som gjorde det möjligt för folk att arbeta med samma kodbas samtidigt. Detta gjorde att man kunde hantera ännu större projekt – men att hantera konflikter orsakade av att två personer ändrade i samma saker, var fortfarande något som inträffade lite för ofta. Det positiva med det hela var ägandefrågan, som innebar att varje utvecklare hade sitt eget litet hörn som de var ansvariga för – och andra behövde då be ägaren om att få göra ändringar.

Utvecklingsprocessens fokus var att man skulle vara noga med att äga koden, samt att man skulle synka koden veckovis eller månadsvis med huvudkodbasen. De flesta verktyg gjorde det möjligt för en utvecklare åt gången att komma åt källkoden. Vissa verktyg hade till och med en användarhierarki för överordnade, som innebar att man hade ansvar för att lösa konflikter, eller kunde komma åt koden även om den var låst av en annan användare.

3. Community-verktyg och delat ägande

De moderna versionskontrollverktygen gör det enkelt att hantera eventuella konflikter, så länge ändringarna delas upp i mindre oberoende ändringar. Konflikter som skulle ha inträffat med tidigare verktyg kan för det mesta nu lösas automatiskt.

1. Processerna varierar mer än tidigare, men det finns två huvudsakliga arbetssätt. I praktiken är själva processen vanligtvis en blandning av båda sätten:
   En community av välvilliga utvecklare som driver igenom sina saker efter varje liten ändring. Efter det kanske någon annan ändrar lite också, om de tror att koden till exempel kan skrivas på ett bättre eller mer estetiskt sätt. Med det här tillvägagångssättet måste utvecklare släppa ägandet (och sitt eget ego) av koden, och inte ta det personligt när deras skapelse ser helt annorlunda ut nästa dag de kommer till jobbet.

2. Granska innan man delar. Det här betyder att dina arbetskamrater granskar varje liten ändring innan den godkänns. Här är till och med småsaker som om ett utrymme ska vara vitt eller vad saker och ting ska heta, viktigt att alla är med och godkänner. Denna modell kräver att utvecklare accepterar kritik, och accepterar att de måste ändra i koden och försöka igen. Till synes små förändringar måste också replikeras på andra ställen i projektet, vilket gör att arbetsbördan för dessa små förändringar är betydande.

Versionskontroll utanför programmering

Verktygen som designers använder idag har funktioner från de moderna källkodsverktygen. Detta sker i allt snabbare takt – det som tog 30 år för kodare tidigare, tar ”bara" några år nu. Verktyg som Figma överträffar faktiskt den nuvarande kodningsnormen genom att tillhandahålla samarbetsredigering i realtid.

Många designers försöker fortfarande arbeta enligt den gamla modellen, medan nuvarande verktyg tar dem närmare mjukvaruutvecklingsprocessen. Det innebär att den mentala modellen för ägande och att ge och ta emot feedback nu snabbt förändras för alla designers. De smärtsamma delarna av förändring och den outvecklade kulturen av snabb kritik, kan vara ett svårt steg att ta för vissa designers.

Hur man hanterar delat ägande

1. Här är några grundläggande regler för hur du framgångsrikt driver ett projekt där alla har möjlighet att vara med och påverka:

2. Det måste finnas en gemensam vision som folk kan jobba mot

3. Att koordinera vem som gör vad är något som måste öka allt eftersom jobben ökar
   Implementeringsprocesser och verktyg som hindrar system att falla samman

Utvecklare har traditionellt sett varit mycket fokuserade på verktyg. Om ett verktyg kan göra jobbet, brukar det vara att föredra framför social interaktion. Inom kodning finns det många verktyg som kontrollerar att de överenskomna riktlinjerna följs samt tester som säkerställer att varje del fungerar separat så att den slutliga produktionen blir rimlig.

Designers har normalt sett grundläggande riktlinjer för vad man bör arbeta med. Om du börjar om från början, se då till att ditt designteam har en och samma vision om vad du arbetar mot, och vad dina designprinciper är. Om du arbetar med ett designverktyg som tillåter versionskontroll, se till att ofta diskutera dina arbetssätt.

Samarbetsredigering i realtid

Samarbetsredigering i realtid är redan möjlig i till exempel Figma, som kräver internetuppkoppling och molninfrastruktur. Samarbetsredigering i realtid har testats av kodare i liten skala, men än så länge har processerna runt det inte riktigt mognat. En naiv implementering för med sig flera nackdelar, men det är uppenbart att verktygen som designers använder kommer att fortsätta att tillhandahålla funktionen.

Ett exempel är att förgrening och textbeskrivning av ändringar ses som en norm för ett framgångsrikt samarbete. I design används inte beskrivningar av ändringar i särskilt stor utsträckning, även om Abstract använder förgrening. Filialer tillåter drift i separata sandlådor tills resultatet är tillräckligt redo för granskning. Textändringsloggen beskriver vad som har gjorts, och varför.

Ett designexempel: Säg att du arbetar med att ändra en ikon. När du försöker dela resultatet säger verktyget att någon annan redigerat din ikon dagen innan. Om du kan se textbeskrivningen om varför det gjordes, får du ett bättre förståelse för hur du ska hantera konflikten.

Att veta orsaken till den dokumenterade ändringen hjälper när projektet sträcker sig över flera år. Då, idealiskt sett, kan man peka med markören på ett objekt och få versionshistoriken:

Flyttade objektet från menyn till toppikonen eftersom det visade sig i A/B-testningen i mars 2020 att det ökade omvandlingsfrekvensen.

Om någon nu går in i projektet efter, måste de ofta gissa sig till varför saker och ting är som de är, och det betyder också att organisatorisk kunskap går lätt förlorad. Det kräver disciplin och förståelse för att dokumentering av ändringar skapar nytta på lång sikt (även om det kan kännas irriterande på kort sikt).

Till sist: Designers, glöm inte att diskutera och be om stöd från utvecklarna! De som har arbetat under vilda-vilda-västern-eran kommer att stötta dig. De nya, som är vana vid det nya sättet att arbeta, kan ge dig användbara tips för att hur du ska hantera versionskontroller.