Bliv en bedre professionel IT-udvikler

For at følge med i IT-branchen er man nødt til at blive bedre til de værktøjer man arbejder med, foruden at lære nyt. Samtidigt er det vigtigt med et fælles udviklingsmiljø hvor de gamle og erfarne deler viden med nyudklækkede nørder.

Af Wilfred Gluud
Artiklen har været bragt i SamData Magasinet, nr. 3 - September  2004
 
- Det er vigtigt at gamle programmører videregiver deres erfaringer og underviser, siger Wilfred Gluud (th.), der laver specialudtræk af patientregisteret på Rigshospitalet, og hans ven Flemming Larsen, der laver shippingsystemer på en af Danmarks store EDB virksomheder.

Hvordan kan vi som systemudviklere fortsat holde os på toppen af vores profession? Verden forandrer sig, og sommetider hurtigere end vi forventer. Der er både trusler fra yngre IT-medarbejdere og for outsourcing til andre firmaer eller til den tredje verden.

IT-faget er ikke længere forkælet, og arbejdsgivere og brugere forventer valuta for pengene, både kvalitets- og tidsmæssigt. Samtidig skal man helst kunne arbejde med flere programmeringssprog og på flere platforme.

Programmører og systemudviklere er nødt til uddanne og dygtiggøre sig, hvis de vil beholde deres job i de kommende år. Den ”livslange uddannelse” er blevet en realitet, ikke mindst i IT-branchen. For at følge med skal man uddanne sig og samle på ”certifikater”, både rigtige certificeringer, kursusbeviser og oplæring via kolleger eller egne studier.

No Silver Bullets
Stress og krav om øget produktivitet betyder at vi bliver nødt til at systematisere og rationalisere vores arbejde. Nye værktøjer og programmeringssprog bliver aldrig til Silver Bullets (mirakel-løsninger) [1]. Det der er brug for er professionelle IT-medarbejdere, der kender en række programmeringssprog og værktøjer. Som er håndværksmæssigt dygtige og hurtigt kan lære nye værktøjer. Som kan analysere, dokumentere, kvalitetssikre, og som desuden forstår hvad der har forretningsmæssig værdi for firmaet/kunden, og hvordan det integreres i programmer/systemer, så det kan ændres. Desuden skal man kunne kommunikere med kolleger og kunder, både mundtligt og skriftligt.

Samtidig skærer virksomhederne ned på antallet af kursusdage, kræver korte kurser og forventer at man selv fortsætter læreprocessen. Derfor er man nødt til selv at tage initiativ til ”Blended learning” med så meget kursus som man kan vride ud af arbejdsgiveren, oplæring på arbejdspladsen, e-learning, hjemmestudier og læsning af bøger og manualer.

Hvis ikke firmaet/afdelingen gør det allerede, bør man lave forslag til oplæringsprogrammer, hvor eksperter oplærer en eller flere i de værktøjer som firmaet anvender - eller at firmaet afsætter en time hver eller hver anden fredag eftermiddag til oplæring, eller at man gennemgår en faglig bog og/eller nye værktøjer.

Invester i dig selv  
  • Lav din egen udviklingsplan
  • Få firmaet til at uddanne dig (og/eller gør det selv)
  • Lær mere engelsk (der er ingen vej udenom, og uanset niveau kan vi alle blive bedre)
  • Lær mere om generelle planlægnings- og programmeringsfærdigheder
  • Lær mere om det/de programmeringssprog eller værktøjer du arbejder med
  • Lær mere om Database / SQL / DataWarehouse
  • Lær et nyt programmeringssprog, styresystem eller værktøj
  • Lær/læs noget personligt udviklende
  • Lær et udenlandsk sprog (ud over engelsk)

Bliv en dygtigere programmør
Efter at en gammel kollega og jeg fik nye job for nogle år siden, hvor vi mødte nye firma-kulturer uden en klar styring af standarder for systemudvikling og programmering. Samtidig mødte vi yngre programmører som havde et uklart forhold til struktureret programmering, navngivning og standarder. Vi mødte også nyudklækkede unge nørder, der arbejdede nu som vi gamle gjorde for 30 år siden. Eller som SQL-eksperten Joe Celko [2] skrev for nylig: ”Vi arbejde som om vi aldrig havde lavet noget lignende før og aldrig skulle gøre det igen. Ingen tænke på at gøre systemet vedligeholdelsesvenligt, mens de kodede det. Andre lavede vedligeholdelsen, på et meget senere tidspunkt, og det var ikke udviklernes problem.” Helt så slemt er det ikke i dag, men man møder tit systemer med uklare standarder, hvor det er svært senere at forstå hvad der sker i et program/system og hvor oplysninger der burde være variabler er faste værdier.

Vi mødte også en kollega, som var Mainframe-mand [3] af den rigtig gamle skole. En dag var der en alvorlig fejl i et vigtigt databasesystem, og man prøvede hele dagen at finde fejlen. Næste morgen havde den gamle Mainframe-mand løst problemet. Men da han blev spurgt hvad løsningen var, svarede han i fuldt alvor: ”Det må du selv finde ud af, det kan du lære noget af” . Det må siges at være højdepunktet af at være ukollegial.

Samtidig havde jeg været nødt til at lære et nyt programmeringssprog foruden SQL, database og Datawarehouse. For at få styr på arbejdet i en afdeling med meget få standarder blev jeg inspireret af to nyere generelle bøger om programmering. Herfra opstod ideen om et kursus i ”Programmering som håndværk”, uanset programmeringssprog og maskinplatform.

Standarder og principper
Til kurset manglede jeg en definition af Struktureret Programmering. Jeg havde alle principperne i hovedet, men savnede én side hvor de var samlet. Jeg søgte derfor på Internettet og i al tilgængelig litteratur, men måtte konstateret at ingen har lavet en samlet definition. De forfattere der skrev om struktureret programmering (bl.a. Ed Yourdan (4) flyttede fokus fra programmering til systemanalyse, og ingen har opsummeret alle de tiltag der var beskrevet. Derfor måtte jeg selv samle og formulere alle principperne i "7 Regler for Struktureret Programmering". [nu udvidet til 8 regler] Se på min hjemmeside om du overholder alle reglerne!

Jeg troede også at der fandtes en standard for navngivning, men endte med selv at nedskrive ”Navngivning med korte navne”. På Internettet fandtes ikke den berømte ”Hungarian Convention” af Charles Simonyi (chefprogrammør ved udvikling af Word og Excel hos Microsoft), der definerer lange navne til Visual Basic, C og PASCAL. Kun i en papirudgave i tidsskriftet BYTE fra 1991, hvor jeg fandt ”Hungarian Convention” og har lagt på min hjemmeside. [i dag har artiklen kun akademisk interesse for nørder]

Desuden har jeg lånt/købt en lang række bøger om programmering generelt, og til kurset har jeg brugt materiale fra pionerer der arbejdede med undervisning i matematisk logik, som George Pólya, hvis problemløsnings-skema fra ”How to solve It”, burde være en del af alle systemudvikleres uddannelse. Også pioneren Edgar Dijstra, der opfandt udtrykket ’struktureret programmering, og er kendt for artiklen ”Go To Statement Considered Harmful” fra 1968, har givet væsentlige bidrag til programmeringsprincipper, som er værd at lære af i dag.

Men det er svært at blive en bedre og mere effektiv programmør. Det er svært at effektivt indsamle fakta og analyse dem til en programspecifikation, så man ikke mangler oplysninger midt i programmeringsarbejdet. Som hovedregel bør man derfor udvikle programmer som en gentaget proces, hvor der tilføjes nye oplysninger. Derfor er det vigtigt at arbejde med en systematisk tilgang til programmeringsprocessen, så man arbejder effektivt med principper og standarder, og ikke kommer til at bruge for meget tid på fejlskud der skal smides væk igen.

Bøger om bedre programmering
To generelle bøger om programmering står frem som de bedste:

Pragmatic-bog.jpg (29774 byte) Den Pragmatiske Programmør

The Pragmatic Programmer: From Journeyman to Master, af Andrew Hunt, David Thomas.
(Addison-Wesley 2000, 321 sider).

En særdeles brugbar metode til programudvikling som viser hvordan man effektivt udvikler høj-kvalitets produkter. Der fortælles om specifikation af hvad der skal udvikles, forhold til kunden, hold-arbejde, design praksis, udviklingsværktøjer, og test procedurer.
Fremstillingen er krydret med anekdoter og tekniske eksempler. Bogen er rettet mod den professionelle programmør, og anbefaler forbedret praksis til programudvikling og faldgruber man bør undgå. Forfatterne behandler personlig ansvarlighed, undgå duplikering af kode, tracer bullets, debugging strategier, automatisering af kode og nådeløs testning.

For nylig er udkommet 3 bøger i en ny ’Pragmatic Starter Kit’ serie, ”Pragmatic Version Control - with CVS”, ”Pragmatic Unit Testing” som fås til Java eller C#, samt ” Pragmatic Project Automation - How to Build, Deploy, and Monitor Java Application” [senere er der kommet mange bøger på forlaget]

CC2-bog.jpg (34843 byte) Færdig kode! - håndbog I programkonstruktion

Code Complete: A Practical Handbook of Software Construction. Af Steve C. McConnell.
(Microsoft Press 1993, 859 sider - 2. udgave juni 2004, 800 sider).

Bogen anmeldt af Wilfred Gluud

Mange roser den for at være den bedste praktiske guide til at skrive professionelle programmer. En praktisk reference til programudvikling fra design til testning med omkring 500 kode-eksempler i C, Pascal, Basic, Fortran and Ada. Men principperne i dette leksikon gælder for alle programmeringssprog på alle platforme. Bogen prøver at få udviklere til at handle strategisk, i stedet for at kæmpe de samme kampe igen og igen, samt checklister for valg af arkitektur, design metoder, og kvalitet i moduler og rutiner.

Første gang på kurset ”Programmering som håndværk” fortalte en af deltagerne at han kom fra et lille firma med kun to programmører. Den anden kom fra USA og havde medbragt ” Code Complete”, som han foreslog som firmaets standard for programmering. Programmøren på kurset var en dansk  datamatiker, og fortalte at bogen fungerede meget fint som standard for udvikling.

Bogen er udkommet i 2. udgave, og ifølge hjemmesiden holder 95% af første udgave, men ”terminologien er ændret, programmeringssprogene er udviklet og min (forfatterens) tænkning er udviklet”. Samtidig var der brug for at bogen fik tilføjet nyt indhold over og efter de 95%, så en del af bogen er omskrevet. Bogen omhandler nu også Objektorienteret programmering, klasser  og eksemplerne er nu i C++, Java og Visual Basic.


NOTER til artiklen

1) 'Silver Bullets' er fra titlen af en berømt artikel om ikke at forvente mirakelløsninger indenfor IT, af Frederick P. Brooks: No Silver Bullet: Essence and Accidents of Software Engineering, Computer, Vol. 20, No. 4 (April 1987) pp. 10-19.

2) Artiklen "Are We There Yet? Quality programming is within reach" af Joe Celko, fra den faste rubrik "Celko i magasinet Intelligent Interprise 20. marts 2004. 
Joe Celko er en uafhængig konsulent fra Austin, Texas i USA and the author of Joe Celko's SQL for Smarties: Advanced SQL Programming (1999). 
Joe Celko deltog i arbejdet med SQL-standarderne i 1989 og 1992. Han is one of the top SQL experts in the world, writing over 700 articles primarily on SQL and database topics i IT-magasiner og akademiske tidsskrifter. The author of five books on databases and SQL, Joe also contributes his time as a speaker and instructor at universities, trade conferences and local user groups. Joe is now employed as at Professor of Enterprise Informatics and Computer Science at Northface University, an accredited university for software developers located in Salt Lake City, Utah.

3) Mainframe-mand: Har lært programmering før struktureret programmering, og betragter sourcekode som sin personlige ejendom. Den værste slags har lært mainframe assembler den gang man i ekstrem grad skulle spare på brug af hukommelse, hvilket første til et utal af branch (GO TO).

4) Ed Yourdan: Ed Yourdon is known as the leading developer of the structured analysis/design methods of the 1970s, and was a co-developer of the Yourdon/Whitehead method of object-oriented analysis/design and the popular Coad/Yourdon OO methodology in the early 1990s. Ed Yourdon's Web Site


Andre sider: Links - Litteratur - Etiske regler
Kursus-Program - Kursus-IT-ansatte / forside www.gluud.net

Wilfred Gluud Senior Programmør -  Kontakt via e-mail wilfred@gluud.net 
20-06-2016 11:35