Én negativ, to positive

BRANSJEFOLK OM JAVA: Johannes Brodwall, sjefsarkitekt i Steria

Publisert Sist oppdatert

Java. Hva er det de snakker om? Hva er trendene innen programutvikling og tilhørende verktøy? Hva er kult og hva er ut? Computerworld har snakket med flere utviklere og stilt spørsmål om trender og hva den enkelte synes er interessant. Svarene får du her.

Johannes Brodwall holder foredrag og deltar i meetups og er vel relativt godt kjent i utviklermiljøer. I fjor holdt han foredrag på Javazone om "hvorfor han hater SOA", noe han egentlig ikke gjør. I år blir det paneldiskusjon rundt tematikken å få det til å slutte å gjøre vondt å programmere.

Han peker på tre trender, hvor den første er negativ:

- Det er mange verktøy som tjenestebusser og kompliserte rammeverk som innfører mer kompleksitet enn problemene de er satt til å løse. Mange programmerere vil heller bruke dagevis på å slåss mot et verktøy enn å bruke noen timer på virkelig forstå problemet de vil løse.

- Jeg har en analogi: Da jeg vokste opp, var jeg frustrert over min far som sa at jeg ikke fikk lov å bruke kalkulator før jeg ikke trengte den. Nå ser jeg verdien av det han sa: Jeg må skjønne hva verktøyene løser for meg før jeg kan bruke dem skikkelig.

Krabbe før gå

- Innen Java vil jeg ikke ønske å la utviklere bruke Spring-MVC før de har brukt servlet-biblioteket direkte, JAXB før de har konstruert en XML melding for hånd, eller Hibernate før de kan bruke SQL.

- Dette har vært en kjepphest for meg lenge, og på Javazone 2010 demonstrerte Anders Karlsen og jeg hvordan å bygge en webapplikasjon uten rammeverk. Jeg har nylig skrevet en tilsvarende artikkel på bloggen min, der jeg implementerer en tjenesteorientert arkitektur med integrasjon uten å bruke integrasjonsverktøy.

Bedre testing

- Den andre trenden er positiv. Utviklere i Java og C# er for lengst vant til at verktøyet automatisk oppdager syntaksfeil hver gang man gjør en endring i koden. For noen år siden begynte det å komme verktøy for mange språk som automatisk kjører tester hver gang man utfører en endring.

- Jeg bruker selv Infinitest på mine prosjekter. Infinitest er ikke så utbredt som det fortjener blant Java-utviklere, men mange som tar det i bruk ser seg aldri tilbake. For C# utviklere finnes NCrunch, som mange snakker varmt om. Innen Ruby bruker mange AutoTest eller watchr.

- Et slikt verktøy kalles ofte kontinuerlig testing eller autotesting. Med kontinuerlig testing kan jeg gjøre større endringer i koden enn jeg våget tidligere, fordi jeg får feedback i løpet av sekunder om jeg har ødelagt noe.

Mer automatikk

Den siste trenden Brodwall nevner er også en positiv trend. De fleste prosjekter i dag benytter byggservere som Jenkins eller TeamCity. Da vil automatisk endringer bli kompilert og testet når utviklere sjekker inn ny kode. Dette kalles kontinuerlig integrasjon og har vært i utbredt bruk i en rekke år.

- Det som er nytt er at flere og flere prosjekter starter å utvide hva byggserveren gjør. Mange prosjekter installerer automatisk alle endringer på et passende testmiljø, og enkelte prosjekter går så langt som å automatisk oppgradere produksjonsmiljøet.

- Hvor langt det er hensiktsmessig å ta dette, kan variere fra prosjekt til prosjekt. Kostnadene ved å sette opp et robust miljø for å produksjonsette flere ganger om dagen er betydelig. Men de aller fleste prosjekter kan få glede av å automatisk oppgradere et passende testmiljø.

- Her kan jeg peke på at alle løsningene jeg har sett for dette krever betydelig mengder eget arbeid. De automatiske verktøyene er ikke helt der i dag, men man kan få hjelp av byggservere som Jenkins og TeamCity, server-konfigurasjonsløsninger som Chef og Puppet og databasemigreringsverktøy som liquibase og dbmigrate.