Når man kjører flere slike prosjekter samtidig og over lengre tid med betydelig antall ressurser blir det aktuelt å tenke litt større og legge en strategi for hvordan informasjon skal flyte og behandles på tvers av organisasjonen.

Med modulbasert utvikling kan man utføre prosjekter med mange personer, gjerne delt i flere grupper. Det kan gjerne sees på som et bestiller- og leverandør-forhold, eller “klient og tjener”, hvor klienten definerer hva som forventes av den andre modulen å ta i mot og returnere av data og på hvilke formater utvekslingen skal foregå.

Moduler kan integreres i systemer via kompilatorlenking mot definerte grensesnitt, som funksjonssignaturer i et “interface” fra objektorientert programmering eller en “header”-fil, eller med meldinger som sendes på en meldingsbuss. Å binde seg til et definert grensesnitt har fordeler med at man kan få en kompilator til å sjekke gyldigheten av kontrakten, at man snakkes felles språk, men det gjør det vanskeligere dersom en av partene har andre behov og trenger å endre en funksjonssignatur.

Meldingsbasert integrasjon defineres på et høyere nivå enn ved funksjonssignaturer, for eksempel at grensesnittet bare definerer hvordan meldingen kan sendes og hvordan svaret kan mottas. Ulempen med meldingsbasert kommunikasjon er at det stiller høyere krav til validering, versjonering og bakoverkompatiblitet, siden en av partene kan oppgraderes til nyere versjon mens det finnes andre systemer som fremdeles snakker det gamle språket. Ved meldingsbasert kommunikasjon bør det skrives en spesifikasjon for formatet på meldingene, for eksempel i form av et XSD-skjemadokument dersom kommunikasjonen pakkes som XML-meldinger, eller Protocol Buffers hvis meldingene er mindre og tydelig definerte.

For enklere systemer holder det kanskje med et format på forespørsler ala: customer search 'ola normann' hvor “customer” kan være navnet på modulen, “search” kan være funksjonen i modulens grensesnitt og “ola normann” er parameteren til funksjonen. Responsen kan for eksempel være kolonne- og radbasert, som et regneark.
Mange muligheter!

Internett kan sees på som et modulbasert system. Veldig forenklet så kan nettleseren, altså klienten i vårt tilfelle, sende en forespørsel mot en adresse eller filsti til en webserver, altså tjeneren, som kan svare med et HTML-dokument. Det ligger en kontrakt til grunn om et felles grensesnitt som gjør at denne kommunikasjonen fungerer, og en slik kontrakt er HTTP-spesifikasjonen. Det er mulig å basere internkommunikasjon i sitt modulbaserte system over HTTP med for eksempel SOAP, Corba, REST, Thrift, for å nevne noen teknikker. Denne type meldingsbasert kommunikasjon har noen svakheter, blant annet krever det ekstra dataprosessering for å oversette objekter og datastrukturer til og fra meldinger som kan sendes over HTTP. Dette er også dens store fordel, da modulene kan lager i forskjellige programmeringsspråk og kjøre på forskjellige plattformer.

For å oppnå en smidig integrasjon mellom modulene trengs det presis og hyppig koordinering på tvers av utviklingsgruppene. Man må ta et steg tilbake for å få et overblikk over systemet som helhet.

Dette er i hovedsak en liten rant jeg skrev i 2011, og jeg mener den fortsatt holder vann – men ta den gjerne med en klype salt…

MIME-meldinger krever CRLF-endinger på linjene før og etter boundary-kodene og etter hver MIME-header.
I eksempelet nedenfor representeres hvert linjeskift som LF.

MIME-meldingseksempel

De steder hvor det står ^M brukes CR, som oftest rett før linjeskiftet.

--part-boundary-1^M
Content-Type: text/plain; charset=utf-8; name=litt-tekst.txt^M
Content-ID:
^M
Content-Disposition: attachment; name="litt-tekst.txt"; filename="litt-tekst.txt"^M
^M
Dette er noe tekst i en fil som heter some-text.txt
Denne fila bruker UNIX-linjeendinger, altså LF og ikke CRLF,
og det er helt i orden, siden innholdet av denne tekstfila er utenfor kontekst av MIME.

Dette er siste linje i fila^M
--part-boundary-1^M
Content-Type: image/png; name=lite-bilde.png^M
content-transfer-encoding: base64^M
^M
iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAIAAACQkWg2AAAAAXNSR0IArs4c6QAAAAlwSFlzAAAL
EwAACxMBAJqcGAAAAAd0SU1FB9wIAwwLKSOxKhgAAAAZdEVYdENvbW1lbnQAQ3JlYXRlZCB3aXRo
IEdJTVBXgQ4XAAAAMklEQVQoz2P8z4AD/Mcuw8RAIhjGGv7/J0UDbtUMDAws+KQZGUnxAzbVuDXg
UD1SYxoAH7UJHx3uIsQAAAAASUVORK5CYII=
^M
--part-boundary-1--^M

Store og små bokstaver i navn på MIME-headere har ingen betydning.

Blokk og separatorkoder (boundary)

I denne meldingen bruker vi separatorkoden (boundary) part-boundary-1.
Separatorene i fila prefikses med --, som viser til start på en MIME Part-blokk.
En slik blokk varer fram til neste separator av samme kode.
Siste separator appendes med -- i tillegg til prefiksen, som betyr at det ikke er flere blokker.

En blokk i en multipart kan også være en multipart, men blokker under denne separeres med egen separatorkode.

Teste meldingen mot en server

For å teste opplasting med HTTP til en web servlet kan man bruke curl.
Vi lagrer multipart-meldingen på fil melding.multipart.
For at serveren skal kunne forstå multipart-meldingen må Content-Type-headeren spesifiseres som multipart/related og boundary satt til part-boundary-1.

Eksempel på kommando:

$ curl -X POST \
    -H "Content-Type: multipart/related; boundary=\"part-boundary-1\"" \
    --data-binary @melding.multipart \
    "http://localhost:8080/multipartServlet"

Forskjellige biblioteker og krav til CRLF

Det er noe forskjeller i hvordan forskjellige kodebiblioteker tolker multipart-meldinger.
Noen tillater linjeendinger med bare LF (uten CR), mens andre er strengere og krever CRLF.

Servlet 3 sin multipart-parser er streng og krever CRLF.
Samme er tilfellet med CXF sin SOAP-Attachment-parser.

Telia MMS MMSC-parser er derimot mer tilgivende.

Ansvarsfraskrivelse…

Det er ikke sikkert jeg har forstått dette 100% ennå.
Det kan være at mitt håndkoda eksempel over inneholder noen skrivefeil.
Jeg hadde Java i tankene da jeg skrev dette, og det er Java jeg har arbeidet med for behandling av MIME-meldinger da jeg forsket på feilscenariene jeg har hatt med linjeendinger.

Mer om MIME-meldinger

RFC 1341 og spesielt seksjonen 7.2 om multipart gir mer informasjon om strukturen til MIME multiparts.

CSS og Javascript er også programmeringsspråk og bør behandles således.

Kode kjører i forskjellige miljøer, enten det er på en web-server, i en virtuell maskin, en applikasjonsserver, i nettleseren eller instruksjoner som dynamisk bygges opp og sendes til eksekveringsmotorer som gjør en jobb og sender ferdig prosessert data tilbake. Det kan være preprosessorer som ved kompilering skriver om deler av programkoden.

Dette er noe å tenke på når man strukturerer opp prosjektet i kataloger og filer.

Forskjellige programmeringsspråk krever forskjellige strategier

Noe man kanskje ikke tenker så mye på mens man forsøker å konfigurere opp prosjektet til å kjøre Java-testene eller kompilere C-fila, er at en løsning ofte består av flere enn ett programmeringspråk. Om man utvikler web-løsninger er CSS og Javascript blitt en selvfølge. CSS og Javascript er programmeringsspråk og bør behandles således.

Javascript er et nesten like gammelt språk som Java, men det er først de siste årene at tradisjelle utviklere har fått øynene opp for hva som er mulig med Javascript. Desto mer man gjør i Javascript desto større er behovet for å teste funksjonaliteten. Det er fullt mulig å kjøre automatiserte enhetstester mot Javascript-kode, og det finnes verktøy for å detektere typiske feil og påpeke klassiske fallgruver. Det finnes også verktøy for å minifisere Javascript slik at filene blir mindre og legger mindre beslag på båndbredden til brukerne av systemet, og ikke minst like viktig er at det kan spare kostnader ved å senke krav til båndbredde fra systemet. Tilsvarende finnes det verktøy for CSS som minifiserer filene og som kan analysere filene og detektere ineffektive regler og duplikate regler som aldri inntreffer.

Retningslinjer

Mange programmeringsspråk har anbefalinger til hvordan programkode skal struktureres. Om systemet som skal lages hovedsaklig skal skrives i ett programmeringsspråk kan man følge dette språkets retningslinjer. I retningslinjene defineres gjerne hva en typisk fil skal inneholde, navngiving, indentering, kontrollkode, feilhåndtering, hvordan filene plasseres i en katalogstruktur og mye annet. Perl-prosjekter struktureres ofte etter CPAN sine retningslinjer, PHP-prosjekter struktureres ofte etter PEAR sine retningslinjer og Java har sine retningslinjer.

En by bygger seg ikke selv. Foto: Flickr/Science Museum London (CC)

Det har de siste årene blitt populært å bruke Maven som kontrollsystem for prosjekter, spesielt for Java-prosjekter, men kan også brukes til andre programmeringsspråk som PHP og Javascript. Man bruker gjerne Maven som en innpakking av prosjektet, til bygging av systemet, kjøre tester, pakketere og rulle ut nye versjoner. Det legger ingen føringer for hvordan man strukturerer innholdet av filer i prosjektet.

Det er ingen fasit når det kommer til struktur av prosjekter, men dersom man er flere som arbeider på samme prosjekt kan det være smart å bli enige om hvilke retningslinjer man skal følge.

Ikke all kode er programkode

Tester skal støtte oppunder løsningen og gi en god og stabil leveranse.

Den viktigste delen av løsningen er det kjørbare systemet, og det er dette som skal gi merverdi til bedriften. Dokumentasjon, tester, byggerammeverk og utviklingsmiljø er biprodukter; støttefunksjoner som skal bidra til å gi et godt og kjørende system.

Maven brukes, som nevnt ovenfor, gjerne til bygging av løsningen og til å kjøre opp web-server under utvikling, men Maven er ikke en del av det kjørbare systemet i leveransen.

Tester, som enhetstester og funksjonstester, er ikke programkode og trenger ikke behandles som det. Tester skal støtte oppunder løsningen og gi en god og stabil leveranse. Tester bør holdes utenfor katalogstrukturen til programkoden. Det kan være løsere retningslinjer til testene, for eksempel friere navngiving av tester, ingen maksimal linjelengde eller flatere katalogstruktur.

Testene dine er viktige fordet!

En god test er en verifikator om at en funksjon fungerer. En god test er presis på hva den tester og er lett å lese og forstå.

En god praksis er å navngi testene etter hva de tester. Et eksempel kan være en test som skal teste at en kunde som heter “Ola” har adresse “Drammensveien”, og denne testen kan da hete test_kunden_ola_har_adresse_drammensveien, selv om dette ikke stemmer overens med for eksempel Java’s camelcase.

En testfunksjon skal teste en ting, og kun én ting. Du trenger ikke å teste at du har korrekt brukernavn og passord i konfigurasjonen for hver eneste test du skriver. Hvis navnet på testen indikerer at en brukers adresse skal kontrolleres så skal testen gjøre det, og lite annet. Samme testen kan gjerne teste forskjellig input dersom det virker hensiktsmessig. For eksempel kan en e-postadresse-validator kontrollere flere godkjente e-postadresser, men kanskje bør det være en egen testfunksjon for verdier som skal feile valideringen.

Samhandling med andre arkitekturprinsipper

Det er mulig å kombinere struktur på utviklingsmiljøet med andre arkitekturvalg. For enkle web-løsninger er trelagsarkitekturen MVC (model-view-controller) populær, hvor man skiller applikasjonslogikk fra datamodell og presentasjon, og man kan plasserer filer i en katalog navngitt etter laget hvor de hører hjemme.

Hvis prosjektet setter domenedrevet design høyt så kan det være smart å segmentere ut filene som utgjør domenemodellene i egne kataloger, for å holde domenet samlet uten for mye støy fra annen kode.

En felles hverdag

Det er smart å ha orden i prosjektet sitt. Kildekoden til prosjektet kan sees på som skrivebordet ditt; hvis det er vanskelig å finne det du leter etter så er ikke arbeidsmiljøet optimalt. I et prosjekt med mange utviklere betyr dette at alle deler “felles skrivebord”. Å sette retningslinjer som alle i prosjektgruppen enes om å følge kan bidra til en ryddigere hverdag for alle, men retningslinjene bør ikke blir detaljerende og vanskelige å følge. Alle skal føle seg komfortable med disse.

Det er en felles hverdag. En god struktur bidrar til raskere utvikling, enklere feilsøking, og etterhvert til bedre kode med færre feil.

Problemet oppstår først når man etter en stund skal inn og gjøre endringer i allerede eksisterende funksjonalitet, helst uten å brekke hele systemet. Kanskje man kaller på funksjoner som man egentlig ikke aner hvor finnes i kodetreet, man har ikke peiling på hvor denne globale variabelen “er_satt” ble satt, enda mindre pailing hvor den kanskje ble endret på veien, og den smarte workarounden som du la inn for et halvt år siden er nå blitt et midtpunkt i systemet ditt. Hva gjør du så? Jo, du legger til en ny “if”…

… eller du starter på nytt. Tanken på å starte fra scratch kan virke skremmende på de fleste, men du har et gigantisk fortrinn foran hvem som helst andre som skulle laget det samme. Du vet hva du skal lage. Du har laget det før, og du skal lage det samme på nytt, men denne gangen med modularitet i fokus.

Det finnes noen små og enkle leveregler når det gjelder programmering. Ingen linjer skal være lenger enn 80 tegn i bredden og ingen funksjoner skal være på flere linjer enn hva skjermbildet ditt kan vise, og gjerne litt mindre. En skummel situasjon er hvor man får løkker inni løkker inni løkker, fordi dette skaper en uorden og det er vanskelig å se på koden og umiddelbart se hva som blir gjort med dataene. Kanskje kan en av løkkene flyttes ut som en ny funksjon, som bare håndterer et sett av dataene. Kanskje denne funksjonen kan benyttes et annet sted i programmet ditt. Tankegangen bak modularitet er å få oversiktlig og gjenbrukbar kode.

Vær gnien på hvilke data du sender mellom funksjonene. Man kan si at dersom antall parametere inn til en funksjon overstiger tre, så gjør enten funksjonen alt for mye eller så hører disse dataene sammen og du kan kanskje lage en klasse som representerer dataene dine istedet. Husk at dataene du sender til en funksjon skal ha høy integritet, eller med andre ord “høre sammen”. Dersom du har behov for å sende data som ikke hører sammen eller som ikke er på samme nivå i systemet ditt, som for eksempel en liste med fotballag sammen med en referanse til databasekontrolleren din, da bør du vurdere å tenke nytt. Kanskje mottakerfunksjonen kan klare å finne referansen til databasekontrolleren selv, eller kanskje du kan sende lista med fotballag til en klasse som arver fra databasekontrolleren som har direkte tilgang til databasen via denne.

For å ta et konkret eksempel på et prosjekt jeg har jobbet med for litt siden, stod vi foran et valg hvor vi kunne lage noen funksjoner for å håndtere forskjellige filtyper og bruke if-else-kontrollstrukturer for å kalle på riktige funksjoner, eller å lage nye klasser for hver filtype og bruke en hashmap for å finne ut hvilken som skulle brukes. Vi gikk for valg nummer to. Vi lagde en felles klasse med en abstrakt metode, som alle de forkjellige filtypene arvet fra. Dermed kunne vi lage noen små og oversiktlige klasser, hvor navnet på klassene indikerte hvilken filtype de håndterte, og disse klassene arvet fra fellesklassen med forskjellige implementasjoner av den abstrakte metoden for å håndtere filtypens unike handling. Det som viste seg var at mange av disse filtypene skulle håndteres likt. Det som kunne blitt et hav av if-elsif ble nå bare en utvidelse av hashmapen for å peke alle filtypene med samme handlingsmønster til samme klasse.

Dette er bare et lite eksempel av hvordan man kan programmere modulært. Det er flere måter å programmere modulært på. Man kan for eksempel lage en plugin-arkitektur hvor man kan stikke inn små moduler som gjør en bestemt oppgave totalt uavhengig av de andre modulene man skulle bruke. Det man må passe på er at disse innstikksmodulene ikke blir for store og monolitiske, men at man også fører modularitetstankegangen videre ut i modulene sine og helt ut i hver funksjon.

Kort oppsummert handler dette om “best practices”. Innen objektorient programmering heter det at enhver klasse skal ha høy kohesjon og svak kobling. Dette gjelder også for strukturell programmering. En funksjon skal ikke kunne alt, men skal være en ekspert på sitt område.