Amerikansk programvareutvikler, født 1961. Skapte Extreme Programming, populariserte testdrevet utvikling og skrev JUnit. «Make it work, make it right, make it fast» er hans, og det er rekkefølgen vi følger.
Definisjon
Beck kommer fra Smalltalk-miljøet på slutten av åttitallet og gjennom nittitallet. Det er verdt å vite, for praksisene han er kjent for er ikke funnet opp ved et skrivebord. De er hentet ut av en arbeidsform der programmereren satt i systemet mens det kjørte, endret det og så virkningen med en gang.
Extreme Programming ble formet i 1996, under Chrysler C3-prosjektet. XP satte navn på ting som i dag er selvsagte og den gangen ikke var det: parprogrammeringUtviklingspraksis der to utviklere arbeider sammen ved én maskin - én skriver kode, én reviewer og tenker - kontinuerlig og synkront., kontinuerlig integrasjon, og kunden som en del av teamet i stedet for en part på andre siden av en kravspesifikasjon.
Testdrevet utvikling er den delen som har spredd seg lengst, popularisert gjennom «Test-Driven Development: By Example» fra 2002. Sykelen er rød, grønn, refaktorer: skriv testen som feiler, få den til å gå grønn på enklest mulige måte, og rydd så koden mens testen holder deg i nakken. Poenget er ikke testdekningen. Poenget er at du må beskrive hva du vil ha før du beskriver hvordan.
JUnit skrev han sammen med Erich Gamma i 1998. Det rammeverket ble malen for xUnit-familien, og dermed for måten enhetstester ser ut i praktisk talt alle språk i dag.
Mantraet hans er en rekkefølge, ikke tre likestilte mål. Få det til å virke. Så gjør det riktig. Så gjør det raskt. De som bytter om på de to første ender med noe elegant som ikke løser oppgaven, og de som hopper over den andre ender med teknisk gjeldAkkumulerte kostnader av raske, kortsiktige teknologivalg - gjør fremtidig utvikling tregere og dyrere. de ikke har valgt.
Linja hit er ekte og ikke en pyntereferanse. Smalltalk-miljøet Beck hentet parprogrammering og den raske tilbakemeldingssløyfa fra, er det samme miljøet Jon Petter selv har bakgrunn fra, i den samme perioden.
Parprogrammering er et kjerneprinsipp hos oss, ikke en øvelse vi tar fram når noen ser på. Det er også den billigste formen for kunnskapsoverføring vi kjenner: to som har skrevet noe sammen har begge sett hvorfor det ble som det ble.
Testene er grunnen til at omskriving er praksis og ikke risiko. Når spesifikasjonen og testene bærer kravene, er koden under dem noe som kan byttes ut. Det er derfor sju år i drift og moderne kode ikke er en selvmotsigelse, og det er samme sak som at kunnskap om håndverket er det som gjør farten forsvarlig.
XPs tanke om kunden i teamet er forløperen til designpartner-modellen: den som skal bruke det, sitter i rommet mens det formes, i stedet for å få det overlevert når det er for sent å mene noe.
I praksis
Linja hit er ekte og ikke en pyntereferanse. Smalltalk-miljøet Beck hentet parprogrammeringUtviklingspraksis der to utviklere arbeider sammen ved én maskin - én skriver kode, én reviewer og tenker - kontinuerlig og synkront. og den raske tilbakemeldingssløyfa fra, er det samme miljøet Jon Petter selv har bakgrunn fra, i den samme perioden.
Parprogrammering er et kjerneprinsipp hos oss, ikke en øvelse vi tar fram når noen ser på. Det er også den billigste formen for kunnskapsoverføringSystematisk prosess for å flytte faglig kompetanse fra ett individ, team eller system til et annet - fundamentalt i konsulentfaget og den nordiske arbeidsmodellen. vi kjenner: to som har skrevet noe sammen har begge sett hvorfor det ble som det ble.
Testene er grunnen til at omskriving er praksis og ikke risiko. Når spesifikasjonen og testene bærer kravene, er koden under dem noe som kan byttes ut. Det er derfor sju år i drift og moderne kode ikke er en selvmotsigelse, og det er samme sak som at kunnskap om håndverket er det som gjør farten forsvarlig.
XPs tanke om kunden i teamet er forløperen til designpartner-modellen: den som skal bruke det, sitter i rommet mens det formes, i stedet for å få det overlevert når det er for sent å mene noe.
