5. Code reviews
lyssna! 
I det här avsnittet grottar vi ner oss i code reviews! Hur jobbar vi med kodgranskning? Gillar vi det? Är det ens värt det? Dessutom om att skriva bra och dåliga kommentarer i pull requests, att släppa på ägandeskapet kring sin kod och att försöka undvika ovälkomnande jargong i sin kommunikation.
Om du gillar podden blir vi väldigt glada för en liten recension i iTunes eller en prenumeration på Spotify. Följ oss och säg hej på @asdfpodden på Instagram eller Twitter (Anton, Therése) <3
Länkar
Transkribering
Transkriberingen är gjord av nån "AI-grej". Du kan förbättra den genom
att klicka precis här :) Jag börjar inte, du får börja.
Okej.
Välkomna till ett nytt avsnitt av ASTF.
Vår nya grej är att säga vem är det som börjar och börjar inte.
Det är ju oklart.
Har ju inte sett det i halsen än.
Alltså den som börjar är den som egentligen slipper börja.
Exakt. En jävla bra deal.
Vi är så jävla dåliga på att komma igång och spela in de avsnitten annars.
Ja, men det är svårt.
Jag håller med.
Idag har vi faktiskt ett typ av ämne.
Alltså vi har inte preppat något.
Nej, nej.
Men vi har ändå ett ämne.
Men hur kan det vara så att vi inte har haft ett ämne de andra då?
Ja, men, ja, de har ju varit, jag tänker, jo okej.
Så vi har precis lika mycket ämne den här gången som vi har haft de andra gångerna?
Ja, kanske.
Jag tänkte lite mer den här gången.
Nu var det ändå så här, okej, vi pratar Code Reviews.
Okej.
Här har vi ändå bestämt ämnet kanske två dagar innan.
De andra bestämde väl liksom ämnet fem minuter innan?
Jo, fast det var ju också att vi skulle ha poddat för två dagar sedan.
Ja, det är sant.
Så jag ser inga stora skillnader om jag ska vara helt ärlig.
Men absolut.
Det är faktiskt sant.
Jo, men vi tänkte snacka lite kurdreviews, eller vad vi tycker om kurdreviews.
Vi får se vart vi landar. Som vanligt, vår avsnitt är lite spretiga.
Ja, som vanligt inte ett helt supertydligt ämne.
Nej, exakt.
Vad tycker du om Code Reviews? Eller så här, är det för eller emot Code Reviews? Ja eller nej?
För.
Jag älskar att jag säger för eller emot, sen ja eller nej.
För, ja.
Ja exakt. Ja, det skulle jag säga.
Fast jag är lite, vi kan återkomma till det här, men jag är lite kluven, för det beror lite på hur man jobbar.
Jag har ju suttit ett år, fram tills ganska nyligen, så jag har suttit typ ett år utan Code Reviews.
Ja, men då har du ju mobbprogrammerat.
Exakt.
Men vi kan ju prata vidare.
Hur jobbar du med code reviews idag?
Ska vi säga code reviews eller säger vi kodgranskning?
Nej, code reviews.
Om det är någonting som är konsekvent så är det väl svängelskan, tänker jag.
Just idag så finns det ingen tydlig rutin utan man ska lägga upp en PR och sen så har man tur så kanske någon kollar på den.
kolla på den men det kan också ta lång tid och det är lite kaosigt.
Och om ingen kollar på den får du mercha den hur du vill då eller?
Det finns nog ingenting uttalat så men jag skulle ju säga nej egentligen.
Däremot har det väl varit väldigt små då man kanske skickar över till någon
så här "Hej kan du approva den här så att jag kan mercha den" och då är det saker som
kanske en import som varit fel så att bygget inte har kört och sådana här små fixar.
Men generellt sett så är väl jag av den åsikten att jag vill gärna att folk tittar på det för att de kan sitta
dels på mycket domänkunskap som jag inte sitter på, sen är jag ju allmänt lite ängslig över att jag har bytt något dåligt
så att jag föredrar ju att folk kollar på det.
Men då är processen typ, okej, gör dina ändringar, skicka en PR, be någon kolla på det?
Ja, eller typ jag tror processen är att göra en PR och sen requesta reviewers.
Men nu kör vi Agit, antar jag.
Ja, precis. Hur ser din process ut?
Alltså i dagsläget är det väldigt lik skulle jag säga. Sedan code reviewar jag inte, eller så här,
jo, jag gör någonting lite lite större, väldigt arbeträr skala.
Då ber jag oftast någon kolla på det. Men annars så är det typ jag som gör. Men sen är det också lite speciellt att det sitter ju väldigt lite team. Jag är typ den enda som jobbar med den grejen jag gör liksom.
Men sen har det varit speciellt för jag började ju posta den här kunden typ åtta veckor sedan eller något. Sex veckor sedan. Så i början var det mycket mer så här, jag lägger upp en PR, vad gör ni?
"Vad gör du nu?"
Så då började jag skicka till folk som jag visste inte hade suttit med den här delen av sajten innan.
"Kan du kolla på den här?"
Och ofta får jag ju faktiskt feedback också.
Så det är ju positivt att folk kollar på det.
Men många grejer är ju att jag lägger upp och så merjar jag själv.
Men sen är det ofta väldigt pyttesmå saker också.
Och sen på något sätt blir det ju att när det är någonting som är jätteriktigt
Och det har varit så här, de har jobbat innan, att man behöver inte code reviewa allt, utan vi code reviewar om det är lite större grejer.
Då är det väldigt lätt att bara följa med i det.
Även om jag kanske hade föredragit att allting code reviewades samtidigt, som jag tycker att code reviews kan ta så jävla lång tid.
Alltså, processen i sig kan liksom dra så mycket tid.
Ja, jag tycker det blir ett problem när man inte har en uttalad grej
att reviewandet ingår och att du ska ta dig tid att göra det.
Där håller jag med.
I början hos en kund så vill jag gärna att allting reviewas mycket
för att jag ska hitta min plats i vad kör de för style här,
hur vill de ha saker gjort, följer min kod, deras standard.
Det är mycket sån input man kan få i början också.
Sen kanske det släpper sig väldigt små saker, det kanske inte är behövligt.
Sen blir det ibland en falsk trygghet för att du kan fortfarande få ut problem
fast det är fler personer som har kollat på det.
Men hur som helst just det här att man inte har en fast grej som vi har nu.
Det är så här, folk ska reviua.
Okej, men det finns ingen tydlighet i vem som ska reviua vad, om de älskar göra det.
Ibland säger några så här, vi har inte tid att reviua så ni får sköta det själva i frontend-delarna då.
Och då är det så här, ja absolut, men det betyder ju kanske inte att folk reviewar.
Alltså jag skjuter ju gärna själv också på det om jag sitter mitt uppe i en grej med någonting.
Då går inte jag automatiskt in och kollar code review-listan för att se om det finns något jag kan göra samtidigt och context switcha mig själv med.
Men jag tror jag var på ett annat ställe och sen kunde det vara väldigt tydlig, i alla fall när jag började var det en jävligt tydlig process ändå, för då satt vi i Teams.
Hela fronten-teamet hade en väldigt tydlig process, så vi satt utdelade på olika.
Men anledningen till att du... Anledningen? Det var helt för lågt.
Du fick ut en PR när du hade fått två tummar.
Så två personer behövde alltid kolla på din PR.
Då var det i GitLab.
Så att du tummade.
Vi pratade ganska mycket om det och påminner mycket om det hela tiden.
Ja, föra efter lunch kanske när du ändå har ryckt dig ur vad du sitter med att passa på att ta en review.
Gör det på morgonen när du börjar och kanske innan du går hem.
Så att inte att du behöver göra det mitt i när du sitter med saker men när det kommer naturliga pauser så kan du lika gärna köra en context switch där då.
För att vi är beroende av att alla hjälps åt att reviewa för att det är två personer på varje code review eller på varje PR.
Och där var det stället där jag lärde mig Code Reviews och att det är en bra sak.
För det var väldigt strukturerat och det gav mig otroligt mycket.
Ja, det där låter väldigt likt hur jag hade det också innan jag började programmera.
För då var det också väldigt mycket att vi ville ha två personer som godkände.
Vi satt i Azure DevOps då, som funkar på samma sätt som alla andra i stort sett.
Men då kände jag lite mer ägandeskap över det, för då var jag också med och satt upp hela processen.
Jag var med och drev igenom att vi flyttade till Git från, vad heter det, Visual Studio VS...
Ja, det är den här gamla varianten. Sån typ.
Jag kommer inte ihåg vad den heter. Visual Studio Version Control. VSVC kanske.
Ja, någonting sånt. Väldigt, väldigt gammalt, som vi körde innan. Så vi flyttade dit och då kände jag lite ansvar för att man skulle sätta upp en bra process där vi kör CodeReviews.
Det var också lite annorlunda i det att det teamet jag satt i var blandat, att vi förvaltade gamla applikationer, att vi nyutvecklade nya grejer.
så man hade liksom en väldigt stor flora av applikationer vi tog hand om.
Vilket gjorde att det var lite svårt att ha en överblick över allting.
Men när vi då körde igång med pull request så funkade det ändå väldigt mycket bättre.
Men det är ju som du säger, vi hade en bokning i alla skalender som låg efter lunch tror jag.
På "Kolla lite Code Rebuse, om det finns".
Och sen såg vi till att man kunde se enkelt vad som finns där.
Eller man kunde överrequesta där, "kan du kolla på det här?"
Men det funkar ändå väldigt bra.
Men sen när jag började mobbprogrammera så saknar det inte överhuvudtaget.
För då sker det ju live.
Och just den typen av code review, att den sker live,
han verkar sakna den.
Man behöver liksom inte vänta på att en PR blir godkänd.
Det är bara att pusha, allting kan gå ut direkt, allting är klart.
När koden kommittas, då är den codereviewad.
Och det är ju en dröm.
Jag tycker att det funkar så sjukt, sjukt bra.
Men, ja, jag vet inte.
Ja, det är väl samma sak om man parprogrammerar.
Har man kört på ögonen så tycker man att man kan trycka ut den direkt.
Men med allting så kan man fortfarande missa saker, helt klart.
Du kan missa saker i en code review, du kan missa saker i en mobb eller en par programmering.
Men ingenting är ju perfekt så.
Och om man inte sitter i mobb och har en sån kultur, då tycker jag ändå att code reviews är väldigt värt det.
Sen är inte det heller min favoritdel i jobbet.
Det är ju inte alltid superkul att sitta och code reviewa, men jag tycker det är någonting som ska göras.
Ja, precis. Jag håller med.
Tittar man hur det är nu så är det väldigt också så här, det går väldigt snabbt.
Vi är väldigt snabbfotade i att behöver jag någonting som kunde bevisa oss så kan jag be någon göra det
och så blir det gjort direkt i stort sett. Inte direkt, direkt kanske, men ändå en resonabel tid.
Och samma sak, vi har ju också väldigt lätt att släppa till produktion, då släpper vi till produktion.
Och det gör ju också att om det upptäcks buggar, då kan vi bara släppa en fix väldigt snabbt.
Så det tycker jag också är en stor förutsättning för att man ska kunna ha det sådär.
Nu kommer man in på att prata agilt och grejer, men att bara kunna släppa till produktion väldigt ofta och enkelt är ju fruktansvärt värt.
Ja, jag menar det är väl… Shit, jag vet inte, jag skulle nog inte kunna jobba så här. Jag har alltid jobbat så.
är det barnvid och vet hur man gör.
Alltså om jag skulle börja jobba med ställen som Big Bangs och sånt,
jag vet inte hur jag skulle hantera det.
Ja, men det är också lite så här hur ofta är ofta också.
Alltså så här, tittar man på de ställen jag har varit på så är det kanske så här,
okej, vi hade något ställe där vi hade kanske,
vi kunde släppa varannan vartid i dag beroende på hur mycket vi hade gjort
för att det behövde ändå så här QA godkännas innan.
Vi hade något ställe vi släppte efter varje sprint,
Så det tog liksom två veckor mellan varje.
Eller nu till exempel när man sitter och kan släppa exakt när man vill.
Ja, jag är ju mest suttit och kan släppa exakt när jag vill.
Ja, jag tycker att det är ju det sättet man ska sträva efter.
För att du får ut mycket mer värde av det.
Och sen, visst, det kanske blir lite fler buggar i produktion.
Men du fixar ju också buggarna väldigt mycket snabbare.
Ja. Och du får ju följa med flödet och hålla koll på din sak hela vägen på något sätt.
sen när du releaserar, då vill du ju testa att det funkar i produktion.
Så att man har ju kanske mer, man får följa med och ha mer ägandeskap hela vägen.
Jag vet inte riktigt.
Ja, alltså det är väldigt lätt annars om man släpper varannan vecka till exempel,
att bara så här, "Ja, vad har vi släppt den här gången då?"
Ja, precis.
När man ska lina upp en så här tidslinje på, "Vad har vi gjort de här senaste två veckorna?"
"Jag vet typ vad jag gjorde förra timman, men sen är det blank liksom."
Så att den slipper man ju.
Men gå tillbaka lite grann till Code Review. En annan grej som jag verkligen, verkligen föredrar med att göra live, typ i mobb eller par, är ju att man får diskussionen som blir, jag tycker, mycket, mycket bättre offline, om man fanar det uttrycket, än vad det blir om man kommenterar kod.
Det är ju en ganska stor kommunikativ utmaning att kritisera eller feedbacka, snarare är det rätt ord, annans kod.
Och sen gäller det att man uppfattar det på rätt sätt, det gäller att man tar det konstruktivt, det gäller att man inte tar det personligt,
det gäller att man inte missuppfattar, alltså det gäller att man inte låter som att du har gjort fel.
Det finns så mycket nyanser som man måste tänka på.
Ja, det finns sådana otroliga utmaningar med det som du säger.
Jag finner det där väldigt intressant också, för det finns ju olika synsätt på det där.
Jag vet till exempel att jag och min sambo, som också är utvecklare,
vi har haft ganska många diskussioner kring hur man uttrycker sig i Codeviews,
Vilket är lite kul för att när jag har pratat med andra personer som också kanske är i ett par där båda är utvecklare,
har kanske haft liknande diskussioner och liknande åsikter.
Det har hänt med kanske två, tre andra personer som jag har pratat med, att de har haft samma diskussioner.
Det är mycket den här att, okej, vissa tycker kanske att det ska vara tekniken som talar, det ska vara torrt.
Alltså inga utsvävningar, inga emojis, inga extra tillägg av ord som inte behövs.
Det här är vad vi vill uppnå, det här är det jag undrar över, det här är det jag finner något som borde ändras på.
Det ska vara torrt, strikt, tydligt.
Ja, jag är ju stark emoji-förespråkare.
Precis, för jag är mycket mer den här, jag uttrycker mig kanske mycket mer mesigt i kompis.
Men jag går in med den här "jag frågar hellre"-saker.
Jag är mycket så här "should this be here because I think this could happen here"
Och så kanske lägger jag till en smiley på slutet.
För att jag är mer av den åsikten att om jag uttrycker mig så,
visst det kanske låter lite mesigt, men det kanske får mottagaren att må lite bättre.
Jag står helt på samma tida.
Jag håller helt med. Hellre "har du tänkt på det här?"-frågor än "det ska vara så här".
Det tycker jag verkligen är mycket mer positivt att ha i en co-review.
Jag har ju väldigt mycket så här att jag kan gå in i en co-review och se så här "ja, men det är ingenting som behöver ändras".
Då kan jag skriva en kommentar så här "fan vad bra, nice". Bara för att.
Jag tycker att det kan vara värt att, jag vet själv att jag uppskattar sådana kommentarer väldigt mycket.
Vilket gör att då skriver jag dem, för jag tänker att andra kanske också gör det.
Och samma sak om jag ser en snygg lösning på någonting, då kan jag liksom kommentera den raden.
Man kan ju liksom kommentera inlines, varför ska jag inte göra det?
Jag hade ju förmodligen gjort det om jag hade suttit bredvid personen och skrivit en radenkod.
Ja, det är intressant. Jag är jävligt dålig på det faktiskt.
Jag är jättedålig på att ens komma på bra, alltså sådär positiv feedback.
Jag bara kör liksom, skiljlapparna på.
Men det är väldigt sant, man borde göra det mer.
För det är ju jäkligt peppt att få sådana kommentarer också.
"Det här känns bra, du får en bra känsla i magen, du kan möjlisgöra den och vara lite glad resten av dagen."
Och det är också extra bra att göra i en pull request-kommentar.
För att när man får, tänk att du får ett mail.
Du har fått en kommentar på din PR och man bara "ÄÄÄH" och så kommer du in och så står det bara "Good job!" Fan vad glad man blir.
Ja jävlar får du en "ÄÄÄH" varje gång du får en, asså jag får kommentarer på mina PRs alltid, jag blir mer såhär "Jag fick en approve utan en kommentar, what?!" Är det sant?
Nej, jag får väl inte. Det är inte så att jag sätter hjärtat i halsgropen varje gång jag får en kommentar.
Men kanske när jag var ny så var det nog mer så att man fick en kommentar och man bara "Oj, vad händer nu? Vad är det som händer?"
Ja, jag var absolut sådan förut. När jag tränade mig på att jobba med Code Reviews, det var ju skitjobbigt.
För jag är verkligen så här, som nämnts förut, jag vill inte misslyckas med saker, jag vill inte göra dåligt ifrån mig.
Det skapade en sån ångest, jag var, nu måste jag exponera min kod här.
Som på något sätt i förlängningen blev att exponera min hjärna, eller hur jag tänker, min kunskap, min kompetens.
Det är skitjobbigt, det är därför man pratar så mycket om det här, att du är inte din kod.
Koden är ju opersonlig, den bara är där för att det kan vara väldigt sårbart.
Ja, precis. Det är ju oerhört sårbart.
Det är väldigt lätt att knyta sig an till den koden man skriver och så här,
"Vad fan är det här?" Särskilt om man har jobbat på någonting i flera steg.
Jag har suttit med den här featuren i massor av olika steg, vi kanske har släppt lite varianter av den.
Och sen så liksom ska man släppa någon mer och så helt plötsligt börjar man få en massa kommentarer.
Och man bara "Va? Nej men det är ju min kod."
Samma sak när någon annan skickar pull requests på samma kod.
Då kan man vara lite extra kritisk istället.
Utan att man tänker på det då såklart.
Men liksom att "Det här är ju min kod, jag kan den här koden utan att jag innan..."
"Den här ändringen gillar jag inte."
"Så det här hade inte jag gjort det."
Ja, ägandeskapet blir för stort liksom.
Exakt.
Men det är ju mycket så att man knyter an till de där bitarna.
Det blir så himla märkligt ibland.
Ja, nej det är...
Jag tappar det verkligen.
Det är sånt som händer ibland.
Nej, men jag håller med.
Det är liksom så här, jag har nog väldigt lätt att knyta an till den koden jag skriver.
Jag är mycket, mycket duktigare på det idag än vad jag var för några år sedan på att liksom så här,
okej, det här kändes för att jag har knyttet an till koden,
men jag släpper det direkt.
Till skillnad från tidigare när jag la en massa värde i det jag skrev sen efteråt.
Alltså så här att det blev en reaktion. Det blir det inte längre.
Nej, alltså det där har jag också fått träna på jättemycket.
Däremot det som svider mest nu för tiden är typ om...
Jag byggde någonting för att någon sa till mig att så här ska det byggas.
Speciellt när jag var på väg någonstans.
Så kommer någon och säger "Nej, du borde göra det så här"
Så lägger jag upp en kod och då kommer en tredje person och säger "Varför gör du inte så här istället?"
Och det var så man gjorde från början. Då blir det bara så här...
Jag vill inte vara med längre.
Nej, som sagt, lite den här kommunikativa utmaningen.
Det får man såklart också släppa, men det kan ju bli väldigt jobbigt i stunden.
Jag kan ju också reagera på vad jag finner är ett otrevliga kommentarer.
Och det sätter sig hos mig, för jag har ju tränat väldigt mycket på den här konstruktiva saken.
Absolut, om någon frågar "Är det så här det borde vara?" eller "Jag ser att det här händer i gubbit när det här sker" och sånt.
Men när det kommer väldigt hårda kommentarer, typ som "Det här är fel", då blir jag sur.
Ja.
Jag blir tjurig, liksom.
Ja.
Nej, alltså, de få gånger när jag skriver "Det här är fel", då blir det också ofta en emoji på slutet.
Jag tänker, jag vet inte om det gör det bättre eller mycket sämre.
Men liksom, jag försöker alltid spela ner det. Jag tror inte att det är så ofta jag gör det.
Men om det skulle hända någon gång. Jag håller ju med dig att jag har också väldigt svårt för onödigt,
hårda, nästan lite aggressiva kommentarer.
Ja, också lite överskitta kommentarer.
Till exempel som en sån här "Nej men titta där, du fick ju ner de här raderna k till det här istället"
Då vill jag så här "Ja, det kanske inte lät så här i den personens huvud men det låter ju som, det låter extremt nedvärderande för mig"
Det är förmodligen så där alla mina komplimanger låter.
Nu kommer jag sluta skriva komplimanger.
Nu blir det inget mer. Det är här mitt fel allihopa om Anton slutar skriva komplimanger i PR.
Exakt. Nej men precis. Jag tycker det är väldigt, väldigt svårt att skriva bra pullergestkommentarer.
Jag har också problemet att jag går in lite i lösningsmode.
att jag ser att det här är ett problem, jag har ingen lösning på rak arm.
Så istället för att skriva
"har du tänkt på att det här skulle kunna vara ett problem?"
"jag vet inte vad lösningen är, men"
Då kan jag säga "hur skulle man lösa det här?"
Och så börjar jag researcha, så här kanske man skulle göra
och så blir det istället att jag löser problemet.
Vilket kanske inte riktigt är
mitt ansvar.
Det är inget negativt med det här egentligen.
Men egentligen så skulle jag lika gärna kunna skriva den korta kommentaren eller den korta varianten och bara så här "Okej, lämna det här".
Men då jag tror att jag liksom lutar lite åt att så här "Det kanske är lite otrevligt om jag erbjuder en lösning också".
Då, då tas det positivt istället.
Det är jätteroligt för jag kan göra samma sak, inte för att "Ah, men hur kan jag göra det här positivt?"
utan mer så här "Fan, ska jag kommentera på det här? Är det verkligen ett problem? Finns det en bättre lösning?
Jag måste ta reda på om det finns en bättre lösning om jag ska kommentera på det här.
Och så gör jag research och så hittar jag kanske en alternativ lösning för att jag ska våga kommentera.
Du tänker mer för att du inte ska få kritik på din feedback.
Ja, för att jag är dum.
Exakt.
Det där har jag också fått jobba jättemycket med och släppa.
Just i början var det jättemycket såhär "jag måste hitta fel med den här PRen".
Du måste inte bevisa att du är en bra kodare så därför kan du hitta fel i andras kod.
Nej, gå igenom den, kolla, se om du tycker att det finns saker som potentiellt kan bli ett problem.
Släpp små saker.
I början var det mycket mer att vi, på det första stället jag var på,
vi la oss i detaljerna jättemycket för att upprätthålla någon typ av kodstandard.
men då var vi väldigt få.
Och ju fler vi blev, ju fler team vi blev,
så fick vi ju släppa på det där
och vi drog in i prettier och sådana grejer.
Så då har man ju fått lära sig att
det behöver inte sitta och nytt
picka på allting.
Ja, jag håller verkligen med.
Jag tycker typ
stilen,
stylingen i koden,
hur du formaterar koden, allting sånt.
Är det inte totalt
kaos så tycker inte jag att det har
i en kurv att göra.
Och det var ju jättemycket i våra första kurvor.
För liksom så här, någon kommenterade, "Ah, du kanske borde ha ett mellanslag innan det här parentesen."
Man bara, "Va? Va fan?"
Prettier har ju läst väldigt mycket för frontend, eller för JavaScript i alla fall.
Och det är ju magiskt bra.
Men liksom, alla ställen där det går, borde man sätta upp en liksom automatisk lint
som bara ser till att det är formaterad rätt.
Ja, för den där orkar man inte stanna kvar på.
Men det var mer namngivningar, det var så många diskussioner om vi skulle ha avslutande JSX-taggen på Nyrad.
Vi hade möten av de här grejerna. Det var ändå på något sätt charmigt på sitt sätt.
Jag kan ändå sakna dem lite, så jag var nästan lite anti-prettier i början.
Svunnen tid.
Ja, det finns en skärm ändå av folk som försöker verkligen fighta sina åsikter.
Men "Prettier" är magiskt. Jag älskar "Prettier".
Jag undrar om det var nån som var på Spotify, tror jag.
Jag ska leta upp länken om jag hittar den.
Men så släppte de nåt som heter "Betterer".
Antagligen är namnet "Prettier" inspirerat.
Det verkar vara ett ganska najs verktyg. Det är väldigt mycket silspår.
Det var att säga att du vill sluta använda moment.js och gå över till date functions biblioteket som är en modernare variant för att jobba med datum.
Då kan den här Betterer lägga in en lintregel som säger att du inte får lägga till några nya moment, men de gamla kan vara kvar.
Och då får man liksom så här, så att om man lägger in någonting ny i Moment, då föreslår den, ja, använd Date Functions istället.
Det såg ganska nice ut faktiskt. Särskilt om man liksom sitter med något i gamla tals och bestämmer, okej, men nu går vi över till Date Functions.
Då vill man ju gärna slippa liksom att, okej, vi ska migrera alla som använder Moment till Date Functions.
Så då kunde den där göra det. Och jag tror även att den föreslog typ så här att, det fanns en massa inställningar, men
Om man ändrade i en fil som använder moment, då gav den en warning kanske, att du borde ändra från moment till date functions nu när du ändrar.
Ja, det är nice alltså. Men hur ofta gör man det egentligen?
Nej, jag vet inte heller. Men jag tänkte bara på det.
Vi gjorde det, jag undrar om jag bytte från just moment till date functions på vissa ställen på mitt förra kund.
Då fanns inte det här då. Så där la ju folk in Moment ändå, så det är skitsamma.
Men ändå så bara så här, "Ja men fan, ganska bra idé. Jag kommer bara tänka på den nu när vi pratar Linting."
Det är totalt tidsspår.
Fan, är Moment-eran över alltså?
Ja, men det kanske är det. Alltså det finns väl nån Moment-combo eller nån modern variant också nu.
För problemet förut var att man inte kunde codesplitta den, eller tree shake, eller vad fan det nu heter.
Jaha.
Och grejer.
Jag har inte suttit så mycket i 3jk såhär, men moment är ju ändå en klassiker.
Det har varit robust sånt.
Ja, det är det. Date functions är ju typ lightweight moment.
Skillnaden är väl att jag tror inte man skapar upp objekt i date functions.
Det är bara funktioner för att jobba med native JavaScript datum.
Det går att jobba med native JavaScript datum också.
Det är ju mer när man ska in.
Nu sidosparade jag ännu mer.
Det är sånt som händer.
Men jag tycker att sådana verktyg är väldigt bra för att ta bort så mycket friktion från möjligt, från när man gör en kulv.
Absolut. Det är så himla tråkigt att hålla på. Jag vet att du fastnar på importordningar och sånt, men varför då?
Det är så himla onödigt. Sen förstår jag att man vill ha saker som ser kohysivt ut. Vad heter det?
Ja, likadant.
Det här är bara "why" svängelska happens in i podd.
Nej, så det förstår jag ju absolut, men som du säger, dra in verktyg, man tjänar så jävla mycket på att göra det.
Ja, jag tycker allt sånt här ska in i Linters eller något annat som man kan göra automatiskt på.
Ja, det som jag känner i biten om man ska prata release och sånt från Pears också är det jag har lite svårt för, asymmetric release.
Alltså versioneringen liksom?
Precis, att man gör det via något lib som går på hur du har döpt dina commits.
Det är ofta, det som vi kör nu är att du ska stå fit och så slutparentes och kolon.
Och då förstår den att det är en minor.
Och kör du istället en fix så förstår den att det ska vara en patch.
Och sen tydligen, om det skulle vara en major då måste man lägga in en breaking changes flagga
Jag förstår grejen, men det känns ändå som att det skapar...
Många commits är så här, jag mödrade master och så råkar det bli en commit kanske, då måste jag ändå göra den här grejen.
Jag har ju bara gjort en refactor, så valde man refactor, men då blev det inte en release för det var inte dels semantikreleasen.
Absolut att man kan läsa dokumentationen, någonting som jag behöver jobba på i livet.
Men jag tycker kanske ändå att man måste fundera lika mycket på vad det är man vill ha
som att man skulle göra om man skulle bumpa en miner eller en patch.
Ja, jag fattar.
Så jag tycker det lägger på ett extra lager som känns betydligt mer komplext egentligen.
Ja, det är väl liksom så mycket annat. Jobba bort så mycket friktion som möjligt.
Och känner man att verktygen ger mer än de tar, då behåller man väl dem.
Men blir det liksom att man känner att "Okej, men nu ger jag inte det här lika mycket längre",
då kanske man ska liksom göra väg att kasta bort det, eller hitta ett bättre sätt att göra det.
- Ja. - Så att ja, det är väldigt svårt.
Men en sista grej bara innan vi rundar av, som jag verkligen vill slå ett slag för,
är ju att det är väldigt lätt om man sitter och gör pull request och kommenterar,
att man hamnar i en lång kedja, särskilt om två personer inte är överens.
Så hamnar man liksom att "Okej, men jag tycker så här, någon annan svarar"
och så svarar man själv.
Släpp det så snabbt som möjligt och gå och prata med personen.
Alltså det är f*n natt och dag i skillnad hur snabbt man löser problemet.
Ja, absolut. Eller bara för att den skulle ta det över slack istället.
Ja, gud ja.
Eller ta ett videosamtal. Alltså det går så mycket fortare.
Jag gillar spårbarheten, att man kan skriva den här frågan här i, och sen så tar man ändå slacken.
Bara för att påvisa att jag tyckte någonting om den här raden.
Nej, men det håller jag helt med om.
För min del så är det väl ofta om man har någonting som behöver diskuteras, man känner direkt.
Eller om man märker att det här håller på att spåra ur.
Och jag tycker också inte att man ska vara rädd att lägga sig i när andra gör det.
Alltså om två personer håller på och kommenterar en PR och säger att det var som i våra tidigare fall,
när man skulle ha två personer som godkänner.
Om man själv då är en tredje person i det här fallet,
var liksom inte rädd för att skriva en kommentar i den här tråden
och bara, ni kanske ska snacka med varandra,
eller ni kanske ska tala över slack,
eller ni kanske ska ta ett videosamtal.
För att det är väldigt lätt när man själv är där
att fastna liksom i tänket att jag ska bara svara här.
Ja, men det där är jag, alltså det där tränar man också upp på något sätt.
Jag vet att när jag satt på kunden innan den här,
innan den här, då fick jag ofta mycket kommentarer på mina peers för att jag var peers och jag visste inte vad jag höll på med.
Så det var verkligen någonting som jag ville ha, men då blev det mycket så att jag förstår inte vad du säger så då vände jag mig bara till personen
och så frågade jag, kan vi ta det här istället? Eller kan vi gå igenom det här tillsammans?
Och som du säger, det sparar så mycket tid och det ger så otroligt mycket mer.
Men jag skulle vilja ta en sista grej också som jag faktiskt har inte snackat om en gång
och som är så värt att tänka på, det är den här "community" och "inclusion" i det.
Och om man har "peers" som är "peers" eller "issues" för den delen, som är "open source"
eller som andra ser, även om du kanske har en jargong i ditt team
så betyder inte det att någon som läser det utifrån förstår det
och det kan bli väldigt ovälkomnande om man drar till exempel hårda skämt eller sådana här saker.
Så det kan ju verkligen vara någonting att tänka på ur den aspekten också.
Bara för att till exempel att du och jag skulle ha en skämsamtorn och kunna kommentera på våra PRs på det sättet.
Tänk att det kommer in en ny person då och kollar igenom den och blir liksom totalt avskräckt över att lägga upp PRs
för att den vill inte ha den behandlingen liksom.
Nej men verkligen, alltså man får försöka hålla ner det lite grann.
Alltså den jarongen man bygger upp. För att jag tycker ju att, alltså så här, man ska inte döda kulturen i teamet.
Absolut inte. Men just i pull requests, eller i dokumentation, i nedskrivet material så kan man försöka hålla det nere.
Alltså så här, jag såg något exempel, när du säger det så går jag på att jag såg något exempel, jag kommer inte alls ihåg vilket projekt det var.
och det var ganska länge sedan, på någon open source-projekt
där det blev en diskussion om just det här för att det teamet som jobbade med det,
någon hade skrivit att någon var en loser, typ.
Alltså, inte superaggressivt, utan jag fattade nog att det var på skämt,
men det var inte helt oklart.
Och han kommenterade någonting och så blev det bara en superkort råd
och sen så den som reviewade bara så här "ah, du är en sådan loser"
Det var ju hundra procent på skämt och förmodligen i den skärgången de hade det
och jag tror inte att den som hade lägt upp PR-en bryddes nog inte
Men sen blev det liksom en diskussion inom issue tror jag
om så här "är det så här vi ska göra?"
Och det känns ju superoskyldigt kan det nog kännas för dem
men utifrån som du säger, helt annan grej
Ja, jag tror i stunden så sker det nog
Jag är en mästare på att dra opassande skämt också. Jag har inte avslutat än i stunden men det är alltid bra att ha i bakhuvudet.
Det var kanske ämnet för dagen.
Jag tycker vi rinner av där. Som vanligt, vill man ha oss så finns vi på Twitter. Jag heter avnton med ett W efter A1.
Jag heter tkongstadius.
Vi är väldigt glada om ni feedbackar på den på ett konstruktivt sätt.
Många emojis.
Vi fattar att ni är snälla.
Och annars lämna gärna en recension i iTunes, det hjälper skitmycket.
Det var det där då.
-Okej, hejdå! -Bye bye!
Bye bye!
*outro*
