Ti ting, en udvikler skal kunne i 2009

Hvis man skal være lækker på arbejdsmarkedet i krisetider, er der ti ting, man skal have styr på som udvikler, mener den amerikanske udvikler Justin James.

Hvad er de sikre kort på hånden, hvis man som udvikler skal være attraktiv på markedet i krisetider? Den amerikanske udvikler Justin James kommer med ti bud på bloggen Techrepublic:

1. Én af "de tre store:" .Net, Java eller PHP
De fleste udviklere har behov for kende til i hvert fald én af de tre største udviklingsmiljøer, .Net, enten som Visual Basic eller C#, eller Java eller PHP. Det er ikke nok bare at kunne sproget. Man skal også have kendskab til biblioteker og populære frameworks i sprogene.

2. "Tunge" klienter (RIA)

Flash er ikke bare sjove animationer, men kan meget mere med Flex-platformen. Microsoft og Sun har deres bud på tilsvarende teknologier, og HTML5 og Ajax kan en masse, som gammeldags webapplikationer ikke kunne. I fremtiden vil kundskaber indefor RIA'er pynte på CV'et, forudser Justin James.

3. Webudvikling

Webudvikling har ikke tænkt sig at forsvinde lige med det første. Her er det vigtigt, at man kan håndkode på det lave niveau, når behovet opstår, og man skal ikke være bange for at få Javascript, CSS og HTML på fingrene.

4. Webtjenester

Der er nok at vælge imellem - REST, SOAP, JSON og XML - men man får det svært som udvikler, hvis man ikke ved, hvordan man konsumerer en webtjeneste. Tjenesterne afløser tidligere tiders ODBC-, COM- og RPC-teknologier, og hvis man ikke kan følge med, ender man som vedligeholder af gamle systemer, advarer Justin James.

5. Kommunikationsevner

It-folket kommer vidt omkring i organisationen, og så gælder det om at kunne noget andet end bare at snakke nørd. Udviklere, der kan kommunikere, er mere værd og meget efterspurgte på arbejdsmarkedet.

6. Et dynamisk og/eller et funktionelt programmingssprog

Sprog som Ruby, Python, F# og Groovy er ikke helt almindelige endnu, men ideerne i sprogene har slået igennem. Eksempelvis stammer Linq i .Net fra funktionelle sprog. Ruby og Python er andre sprog, som er efterspurgte i visse sektorer, skriver Justin James, men uden at sige hvilke.

7. Adrætte metodikker

Ideerne bag adræt eller "agil" udvikling er blevet bedre defineret igennem tiden, og det gør metodikkerne mere spiselige end før. Adræt udvikling er ikke løsningen på alle projekt-problemer, men det har sin plads i mange projekter. Udviklere, som har erfaring og succes med adrætte metoder, vil i stigende grad blive efterspurgt.

8: Forståelse af problemfeltet

Udviklingshold bliver i stigende grad set som partnere, når et projektet skal fastlægges. Det betyder også, at et stigende antal organisationer foretrækker, at udviklerne har én eller anden slags kendskab til det foreliggende problemfelt.

9. Ordentlig udviklings-opførsel

I dag er det almindeligt at benytte build-værktøjer, bug-databaser, versionsstyringværktøjer og alt muligt andet på et udviklingshold. Derfor er der ikke længere plads til udvikleren, som går rundt med kildekoden på en USB-nøgle.

10. Mobil udvikling

I løbet af de næste fem år vil der komme mere fokus på mobile applikationer, spår Justin James. Hvis man kan føje mobiludvikling til sit portefølje, er man beredt til fremtiden.

Hvad mener du? Hvad skal udvikleren kunne for at blive i sadlen? Giv dit besyv med herunder.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (12)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Torben Mogensen Blogger

Med få undtagelser ser det for mig ud som teknologier, der har toppet, og er på vej til at blive erstattet af bedre ting.

Og det stærke fokus på specifikke teknologier frem for grundlæggende kompetencer virker også kortsigtet.

Men i krisetider tænker man måske kortsigtet?

Anders Reinhardt Hansen

Det er lidt apropos det vi har diskuteret før om hvad folk bør kunne som nyuddannede datamatikere...

Noget jeg ville mene var en god ting at have på her var ting som fejlsøgning og test(herunder viden om debugging m.m.). Generelt synes jeg at det er noget man ikke underviser særlig meget i på uddannelserne selvom man burde. Problem forståelse, og viden om hvilke teknologier der kan bringes i brug til løsning af et konkret problem.

Jens Madsen

Ovenstående, er mest programmeringssprog, og metodikker. Hvad med Datalogi? Skal en programmør, kunne udvikle algorithmer? Skal en programmør, kunne dokumentere algorithmer og kode med dataark, f.eks. angive kompleksitet for lagerforbrug og processorkraft (store O funktion)? Eller, må en programmør, bruge dårlig kode, der tager lang tid, og som så bruges af andre, og tager endnu længere tid, samt øger sin store O funktion? Indenfor hardware, vil ikke gå, hvis man ikke havde timing specifikationer for chips. Man siger, at angives ikke, hvor lang tid at en opgave tager (svartid, f.eks. store O funktion), så er der ingen svartid, og den bliver aldrig færdig (hænger). Angives ikke, hvordan forbruget af ram, øger sig med opgavens kompleksitet, så siges, at forbruget går mod uendeligt (f.eks. exponentiel udvikling, eller exponentiel "i anden"). Udokumenteret, så er dokumentationen altid, at forbruget er uendeligt, eller tiden er uendelig. Står en streg, og ikke "0" så betyder det uendelig svartid, og at kompleksiteten er så høj, at der ved større opgaver, end der er opnået i et velvalgt dokumenteret eksempel, ikke kan forventes svare. Er ingen data opgivet, så kan man forvente, at eksemplet er udsøgt, og kun dette giver et svar.

Indenfor HW, er der krav til timing specifikation. Enten, skal stå en garanti for, hvor længe det går inden svar - og dette er ikke en middelværdi, men absolut maksimum. Overskrides den, kan kunden få pengne tilbage for chippen, eller for hele serien. Der er typisk krav til, at forsinkelsen har en maksimum kompleksitet på O(log(n)), fordi det er største kompleksitet, hvor man kan sige at noget svarer indenfor en acceptabel tid. Ellers, skal dokumenteres, af hvilke faktorer svartiden afhænger, og sammenhængen skal opgives.

Normalt, vil også være krav til dokumentation af hukommelsesforbruget - så man ved det ikke er uendeligt, og af hvilke parametre forbruget afhænger. Ofte, angives det ned til præcision på bytes. Men, værktøjerne angiver også forbruget med denne nøjagtighed, så det er ikke et praktisk problem.

Hvorfor, skal det så dokumenteres, så ligegyldige detaljer som forbrug af ram, og forbrug af processorkraft? Jo, ellers er hardware ikke muligt at teste. Du ved simpelthen ikke, hvor mange år, du skal vente på svaret, fra en påtrykt kombination. Dokumentation af store O funktionen, og af svartid, er nødvendigt, for at kunne dokumentere produktet er testet. Er det ikke nogle timingspecifikationer, så vil ingen tro på, at produktet nogensinde er testet af producenten, da dette kun kan gøres, hvis komponenterne, og produktets data er kendt. Kunden, vil også have svært ved at verificere en test, hvis han ikke ved hvor længe han skal vente på svaret.

Endeligt, er ikke ualmindeligt, at det i databladet angives testmetoder, fremgangsmåde, og eventuelle hvilke typer test, som er gennemgået.

Alle disse ting, undervises det i, også indenfor software og datalogi. Alligevel, er noget så fundementalt, som at kunne angive data for et program, ikke nævnt over hvad en programmør skal kunne. Det betyder, i prakis, også at softwaren er ikke testbar, og ikke brugbar. For at være dette, skal angives et datablad, der angiver såvel store O funktioner, for både ram forbrug og for processor kraft, og det skal udfra data, kunne opsættes fornuftige krav, til hvor længe der skal ventes på svar. Det skal vides, at computerens hukommelse ikke overskrides, og hvor store opgaver man kan tillade sig at teste, og derfor er også nødvendigt at have kendskab til, hvordan udviklingen er i ram forbrug, som funktion af opgavens størrelse.

Endeligt, er nødvendigt, at virksomheden står inden for kvaliteten af produktet. At kunne anvende en "komponent", uanset om det er software eller hardware, kræver at den pågældende komponent fungerer. Ellers, giver den kun kvaler. At den fungerer, betyder at den skal være testet af udvikleren, og at udvikleren står inde for produktet. Typisk, skal angives testvektorer, som udvikleren har brugt for testen. Udvikleren, er ansvarlig for, at så mange "ledninger" og "knudepunkter" som muligt, har været både høj og lav - og indenfor software, at enhver programlinie, og branch er udført i begge retninger. Ellers, er testen ikke udført ordentligt. I nogle tilfælde, kan sikkerhedstests der er indbygget i et program, være en forhindring for dette - dette skal klares, ved der bruges specielle rutiner til sådanne tjeks, som er lovligt at gå udenom når der kræves at alle linier skal være udførte, og alle branches skal være udført i begge retninger. De pågældende fejlrutiner, der må gås udenom, er så testet uafhængigt, og garanteret ikke kan medfører eksempelvis bagdøre eller typer af fejl.

Hvis test vektorer, eller test programmer, som udvikleren har udført, afleveres som del af dokumentationen, tjener disse også som eksempler, og gør det lettere for brugeren af rutinerne, eller programmet, at sætte sig ind i det, og starte med at udføre samme tests. Herefter, vil man typisk udføre sine egne tests, for at tjekke man har forstået det - f.eks. ved at først ændre i de givne tests, og siden, ved at skrive sine egne. Er der uklarheder, vil det undersøges med tests. Brugeren, som anvender rutinerne, skal altså også teste de rutiner/objekter/komponenter, der anvendes, for at sikre sig sin forståelse af komponenterne, samt at udføre dobbelttjek, at komponenternes funktion. Har udvikleren testet komponenten før, og fuld forståelse for komponenten, kan han måske udføres færre tests af den, der kun tjener til at sikre, at den stadigt fungere - eller måske kan undværes test.

I den sidste ende, står udvikleren altid inde for, at det han aflevere fungerer - og at han selv har testet såvel de rutiner han har brugt, og at han har testet sit eget på et grundigt niveau, hvor han også står inde for, at alle linier har været udført, samt branch, og switches har været udført i enhver retning. At han har gjort noget for at teste det, dokumenteres i dokumentationen, ved at specielt vigtige brugbare tests, og tests der øger forståelsen for brugen, skal være fremlagt og dokumenteret.

I sidste ende, vil et test hold, typisk tjekke det færdige produkt, trods produktudviklerne har testet det, og står inde for resultatet. Test holdet, tester det "som kunden ser det", så kunden ikke som første ord siger, at det har vist aldrig været afprøvet. Visse typer fejl, opdages først, når udstyret bruges på en måde som svarer til kunden, og sættes sammen med andet udstyr, der svarer til kundens - f.eks. om en udskrift ser ordentligt ud, og indeholder rigtige data.

Som jeg ser det, er dokumentation og test, noget af det vigtigste, ved ordentlig programudvikling. Det er helt utiligiveligt, at værktøjer ikke "dokumenterer" de nødvendige data, som skal bruges, for at kunne teste et produkt.

Endeligt, synes jeg, at det også er vigtigt, at programmører har kendskab til datalogiske decipliner - såsom hvad forskellen er på et abstrakt højniveau sprog, og et sprog der kræver noget bestemt hardware, eller bygger på vedtaget hardware og emulering af en hardwaremaskine. Og jeg synes, at det er vigtigt, at man har tilstrækkeligt forståelse for algorithmer, til at man kan vurdere den nødvendige kompleksitet af en opgave, f.eks. ved at dele den op i om noget kan sorteres, eller anbringes i alfabetisk orden, og at bruge sin viden om de idelle kompleksiteter, for de delopgaver, en opgave må indeholde.

Jeg synes, at ting som søgning, anbringelse i alfabetisk rækkefølge mv. burde være integreret effektivt i højniveau sprog, så det giver optimale CPU tider, og anvender bedste algorithme, med mindste store O funktioner - og derved, ofte vil være med til at gøre software bedre, fordi det er simplest at bruge de indbyggede ordre, og gøres dette, vil opgaverne i alle tilfælde løses, med mindst forbrug af CPU tid, og mindst kompleksitet af forbruget af ram.

Teoretisk kunnen, kendskab til sprogteori, datatyper, samt algorithmer og kompleksiteter der er nødvendigt for test og dokumentationen af rutiner og objekte, er vigtige områder, som jeg mener at enhver programmør bør kunne. At have kendskab til et programs "tilstande", og hvilke udviklingsmetoder, der giver bedst kontrol med tilstandende, og andre datalogiske områder, er også vigtigt.

Så min tilføjelse, er "datalogi", som det 11'te krav.

Hans-Kristian Bjerregaard

Som studerende på DIKU kan jeg kun være enig med dig... bare ikke i det her tilfælde. Alt hvad du nævner er rigtigt vigtigt for en datalog og det område en datalog skal beskæftige sig med. Men der er bare ikke noget der er vigtigt for "den almene programmør" (undskyld, meget, meget forkert udtryk men jeg kan ikke udtrykke det bedre).

Som jeg ser det er en af datalogernes fineste opgaver at stille en række redskaber (f.eks. gode sprog, compilere osv) til rådighed for andre så de kan udvikle software uden at skulle tænke så meget over alle disse ting.

Hvis du ser på det første punkt så indeholder det f.eks. kendskab til Java. Java har JVM (sjovt nok) der tager sig af alt 'det hårde arbejde' så programmøren kun skal tænke på logikken i sin applikation. På den måde fjernes meget af ansvaret for alt det du nævner fra programmøren og pålægges istedet JVM.

Så jeg mener denne artikkel er helt korrekt for f.eks. datamatikere.

Thomas Søndergaard

Må jeg foreslå "Ti ting, en <b>web</b>-udvikler skal kunne i 2009".

Jeg er enig med punkterne 5, 8, 9 og til dels 7. Alle de andre punkter bør udskiftes med:

  1. Tilegnelse af ny viden
    En god udvikler forstår at sætte sig hurtigt og grundigt ind i ny teknologi.

Jeg har ikke meget tilovers for efteruddannelseskurser i Ajax, java, web-services eller hvad dillerne nu hedder. Hvis man ikke kan tilegne sig den viden selv, så er man ikke en god nok udvikler.

Jakub Nørløv Iwanczuk

Jeg kan godt lide dit iver omkring din beskrivelse af datalogi og jeg kan se at vi er overordnet meget enige om datalogi, men jeg tror nu at du har taget titlen på denne artikel alt for bogstavligt.

For som Torben faktisk siger så drejer det sig primært om teknologier, som det er godt at kende for en udvikler og ikke udviklerens egenskaber/baggrund osv.

Titlen burde have været noget i retningen af "Ti teknologier, en udvikler skal kunne/kende i 2009". I mine øjne et dårligt ordvalg af forfatteren!

Baldur Norddahl

Kan vi ikke en gang for alle enes om, at karakterer er noget man får til eksamen. Skriftssproget på danske består af 29 tegn, så derfor kaldes det et tegnsæt.

Nej det kan vi ikke blive helt enige om. Dansk sprognævn siger om ordet karakter:

2) (nu næppe br.) indridset, skrevet tegn, bestemt til meddelelse; skrifttegn; bogstav. Ikke heller betyde (brakteatens) Characterer et Boemærke. Gram.Breve.51. en Chineser maae kiende 80000 Carakterer, førend han kan læse sit eget Sprog. JSneed. III.299. Høysg.2Pr.4. Det almindelige Alfabet (dvs.: runerne), som bestaaer af sexten Charakterer, er følgende. Wors.DO.92.

Citat fra http://ordnet.dk/ods/opslag?id=473959

Baldur Norddahl

Gammeldags eller ej så er det ikke forkert.

Den Danske Netordbog mener at ordet karakter har fire betydninger hvor den fjerde er "skrifttegn".

Jeg kan ikke lige finde min nudanske ordbog, men Gyldendals dansk-engelsk ordbog mener at det danske ord karakter kan oversættes til "3. (tegn) character".

Man kan selvfølgelig ringe til dansk sprognævn hvis man vil være helt sikker. Men på det forelæggende grundlag synes det ikke at diverse ordbøger kan støtte en udlægning af at det er forkert at bruge ordet karakter om et alfabetisk tegn.

Log ind eller Opret konto for at kommentere