Helt enig, og jeg tror LLM-verktøy kan være en tvingende funksjon for å ta i bruk noen av praksisene til de beste teamene/organisasjonene på mindre team som kanskje ikke har vært i stand til å rettferdiggjøre dem før.
Simon Willison
Simon Willison21 timer siden
Det er ikke bare enhetstester – det er så mange andre programvareutviklingspraksiser på toppnivå som akseler produktiviteten med kodeagenter Automatiserte tester, omfattende dokumentasjon, gode versjonskontrollvaner, en kultur for kodegjennomgang, rask distribusjon til iscenesettelsesmiljøer ...
Jeg tror du ville være gal å ha flere hundre ingeniører uten en linter. Hvis du bare har to eller fire, men kanskje bare aldri oppnå aktiveringsenergi for det, og har stort sett uproduktive krangler om kodestil. Men legg til Claude Code og a) du vil ha den linteren
b) å sette opp den linteren er nå fem minutter med marginal løft kontra "En person går ned i en klassisk tarpit-oppgave med å få den integrert med alle IDE-ene/etc."
For den delen av publikummet mitt som ikke vet: en linter er et automatisert verktøy som kan håndheve standarder for kodingskonvensjoner som er strengere enn de et språk kan tillate. Du kan for eksempel vedta en husregel om at bestemte juridiske konstruksjoner ikke er tillatt
Som et eksempel er det et veldig kortfattet juridisk uttrykk på mange språk som kalles en ternær operator. Ternære operatorer er notorisk sannsynlig å forårsake feil, og et ingeniørteam kan bestemme at selv om de er kortfattede, på en risikojustert basis, er de ikke en akseptabel funksjon å bruke.
Som et eksempel på en ting du fornuftig kan regulere via linter som du ikke vil måtte ha gjentatte argumenter med Claude Code om: i Rails betyr something_id en fremmednøkkel for noe-tabellen. Claude glemmer dette av og til, og kaller mange andre ting for id.
Du kan, hvis du vil, skrive en linter-regel som skal kjøres hver gang kode endres og flagge til Claude og resten av verden: "Du navnga en variabel box_id, men _ids skal bare brukes til å referere til databasenøkler. Tenk på box_code eller et annet navn.»
En fin ting med linter-regler er at de kan ha vilkårlig prosjektspesifikk kunnskap innebygd i seg. Et gjentatt argument en japansk lønnsarbeider ble tvunget til å ha for lenge siden, med (med)ikke-morsmålstalende som gjorde en universitetsapplikasjon: du MÅ IKKE bruke «subjekt».
Hvorfor ikke? Fordi japanske universiteter deler akademiske inn i (kyouka; et som «matematikk») og (kamoku; et emne som "lineær algebra"), og siden undersubjekt er forferdelig å lese i kode, ble disse referert til av romanisert japansk for å alltid være entydige.
20,92K