Show newer

@erlendaasland Det hjelper ikke at du har mange små atomiske commits i en PR som utvikles på en branch på siden over flere dager.

@erlendaasland I tillegg: Siden du hele tiden er på main er det lett å kontekst-svitsje over til å ta unna små bugfikser eller andre ting som dukker opp underveis, uten å måtte gjøre unødige git-armhevinger, eller i verste fall - å la være å fikse ting på main, fordi du vet det kommer til å gå i konflikt med branchen din.

@erlendaasland I tillegg til de åpenbare fordelene i den kontinuerlige flyten så vil denne måten å jobbe på tvinge deg til å skrive koden din på en måte som tåler å gå i prod. Da lager man ny kode på siden først, gjør noen refaktoreringer for å "lage plass", og kobler på nye features helt til slutt. Kanskje med en feature toggle, men ikke nødvendigvis. PR-flyten tillater i mye større grad å begi seg utpå langt mer ambisiøse prosjekter og mangler rettesnoren om å holde seg "prod-kompatibel".

@erlendaasland I kontrast: kontinuerlig integrasjon. Alt arbeid committes løpende (kontinuerlig, kan du si) til main. Jeg rebaser jevnlig med main, hvor alle andres pågående arbeid kontinuerlig dukker opp, og pusher mine endringer jevnlig. Alle endringene fra den store konflikten kommer som små bruddstykker som lett flettes sammen underveis.

@erlendaasland Siste forsøk på forklare poenget mitt:

Du skal bygge en ny feature. Det tar tre dager. Med pull requests lever du på en branch i tre dager. Du kan jevnlig rebase med main, men du går glipp av kode på andre brancher. Når PR-en din er klar ser du at det er en stor konflikt med en annen PR. Førstemann i mål!

@erlendaasland poenget mitt er at diskusjonen om koden må foregå før eller mens den skrives. Ikke etterpå. Ergo har en pull request lite for seg (i miljøer med høy tillit).

@erlendaasland jeg mener kontinuerlig integrasjon: alles kode integreres med alles kode kontinuerlig. Når alle jobber på hver sin branch skjer dette ikke kontinuerlig, men i batch. Du må gjerne kaste systemer på situasjonen, men det blir ikke kontinuerlig integrasjon av det.

@erlendaasland Forøvrig: en god PR inneholder ingen kode, bare en skissert løsning før man starter kodingen. Det er den eneste måten å diskutere løsningen før det allerede er investert tid og energi i ett mulig spor, sunk cost melder seg osv. Men jeg syns parprogrammering er en bedre løsning.

@erlendaasland du kan selvfølgelig bøte på den mindre smidige prosessen med retningslinjer og kortere responstid, men det er like fullt en fundamentalt annerledes måte å jobbe på. Dersom alt går på main og så rett i prod får du helt andre spaker å dra i.

@erlendaasland hvis du har en arbeidsflyt der du kjører alle endringer via PR så har du ikke kontinuerlig integrasjon. Koden blir ikke integrert i main før du har gått gjennom en manuell prosess. Det er det motsatte av kontinuerlig integrasjon.

@glenjamin yes, everything goes directly to production. Since this happens many times per day it becomes less scary, and mostly problems are easily correlated with very few commits. Highly recommended!

Hvorfor har det blitt så populært å jobbe med pull requester når vi vet at kontinuerlig integrasjon gir økt kvalitet? Jeg har skrevet litt om hvorfor jeg mener PRs er en dårlig match for teamarbeid parenteser.mattilsynet.io/pull

@lettosprey @forteller for noe rør. Jeg kjører fra sone 2S. Selv med 4 dager på kontoret i uka (vanlig uke, av og til færre) er månedskort dyrere enn reis...

Christian boosted
Christian boosted

Which of the following best describes your political views?
(Please boost to spread this poll wider)

You don't have to rewrite your apps every 3-5 years. You just need to design it with some care. I recently gave a presentation about the architecture that helped our frontend codebase stay in kick ass shape, even after 9 years of continuous work: vimeo.com/861600197

@headius it was very interesting and well presented, thanks!

Christian boosted

In response to Google's monopolistic implementation of Web Environment Integrity, I have a modest proposal:

Open source JavaScript libraries should add bugs which only occur when they find "navigator.getEnvironmentIntegrity" is being used.

Go into a "while(true)" loop. Start throwing exceptions randomly. Just fuck up the page. Make the lives of every developer who is in the origin trial who uses your library completely miserable.

If they want to fork, they have the freedom to do so. But then they're taking on the maintenance that they would prefer to outsource to their community.

If you have enough big libraries doing this, it might make a dent.

Show older
Deff

A private server for a friendly bunch of peeps.