This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-12-05
Channels
- # adventofcode (89)
- # announcements (9)
- # babashka (11)
- # beginners (8)
- # biff (5)
- # calva (4)
- # cherry (121)
- # clara (15)
- # clerk (16)
- # clj-kondo (20)
- # clj-otel (2)
- # cljdoc (20)
- # clojure (84)
- # clojure-austin (1)
- # clojure-bay-area (3)
- # clojure-berlin (1)
- # clojure-czech (2)
- # clojure-europe (59)
- # clojure-nl (1)
- # clojure-norway (12)
- # clojure-poland (1)
- # clojure-uk (15)
- # cursive (16)
- # datomic (46)
- # events (3)
- # fulcro (85)
- # graalvm (20)
- # hyperfiddle (11)
- # improve-getting-started (1)
- # lsp (7)
- # off-topic (48)
- # overtone (8)
- # podcasts-discuss (4)
- # re-frame (31)
- # releases (1)
- # ring (12)
- # sci (13)
- # shadow-cljs (8)
- # specter (3)
- # squint (26)
- # xtdb (5)
- # yamlscript (6)
Ikke så Clojure-spesifikt, men drister meg allikevel til å reklamere litt for min siste brannfakkel: https://parenteser.mattilsynet.io/pull-requests/?li Forventer mer motbør på denne en mange andre ting jeg har skrevet 😅 Hvem er uenig? Hvorfor?
Der satt du ord på mange ting jeg har kjent på når jeg har vært i team med PR-drevet utvikling, denne skal jeg dele neste gang temaet dukker opp 😍
Nice one! Jeg skrev et lignende internt innlegg for litt siden. Kult å se at flere tenker i samme baner.
Ingen motbør herfra - det har demret for meg de siste årene at en PR-basert hverdag er veldig anti-lean og bremser hastigheten, uten å gi den effekten de er ment å gi - bedre kvalitet. Alternativer? God gammeldags design før programmering, par-programmering, retrospektiv kodegjennomgang,
Supert artikkel, altså. Setter ord på mye av det som er feil med det som virker å være vanlig praksis. Spesielt godt poeng mot slutten der, det med grad av tillit. Hvis teamet ditt har så lav tillit at en PR-basert flyt presser seg fram, så ville jeg heller tatt tak i det grunnleggende problemet.
Veldig god artikkel, og jeg merker at jo mer vi kjenner hverandre på teamet, jo mindre bruker vi PR aktivt. Men det er også krevende å oppnå den graden av tillit i et team: Så min pragmatiske side vil lene seg mot at jeg har stor forståelse for at pull-request prosessen oppstår og vedvarer. Generelt tror jeg vi i IT-utvikling har en lang vei å gå når det kommer til å sørge for at det mellom-menneskelige i samarbeid fungerer, og det er for lett å lene seg på tekniske verktøy og strukturerte prosesser.
Er det egentlig vanskelig å oppnå nok tillit i et utviklingsteam til at alle kan commite rett til main? Jeg har jobbet i 20 år, og har enda ikke jobbet i et team som aktivt brukte pull requester eller andre former for låser på main-branchen.
Har en helt annen erfaring. Jeg har ila. de siste 3 årene kun jobbet et sted (nåværende) hvor tilliten er der i teamet. Jeg har også opplevd å være på et team hvor vi var 3 utviklere som satt sammen, men hvor han ene insisterte på pull requests og låst main branch, etter at noe feil kom inn i main en gang. Dette var også utvikling på noe som ikke skulle i prod før om 2-3 år.