Citat:
|
1. Hur har du lärt dig att programmera?
|
Jag är till 100% självlärd, dvs jag har läst tidningar, böcker och numera även kikat på internet. Men jag började lära mig programmera 1979 då jag besökte en lokal TV-handlare i Torsby i Norra värmland och fick se en ABC80. Jag kikade lite i en bok och skrev mitt första program:
Jag blev nyfiken och funderade på om jag kunde få datorn att skriva ordet flera gånger, så jag hittade ordet "GOTO".
Så mitt andra program såg ut så här:
Kod:
10 PRINT "Hej!"
20 GOTO 10
Det funkade! Jag blev exalterad och var såld på programmering, det här skulle jag gilla!
Sen har jag alltid sökt upp tidningar, böcker, kurser m.m. för att lära mig mer. Men min första programmeringskurs gick jag 1986, så det var 7 år efter att jag kom i kontakt med programemring först agången.
Citat:
|
2. Vilka sorters språk kan ni koda?
|
C, Basic (alla möjliga olika varianter), DRBASIC, Visual Basic, Visual Basic .NET, Pascal, Delphi, ADA, SQLWindows, Centura, COBOL (Nja, länge sedan), dBase, CLIPPER, FoxPro, ......(minns inte alla jag jobbat med)
Citat:
|
3. Hur lång tid tog det för dig att lära dessa språk?
|
Att förstå de grundläggande komponenterna i programmering:
Sekvens (göra flera saker i följd)
Selection (Villkorsstyrda hopp)
Iteration (loopar med olika uthoppsvillkor)
Tog mig kanske en halvtimme att sätta mig in i första gången. Nu tar det inte så lång stund i de flesta nya programspråk jag testar. All programmering i imperativa språk bygger på dessa komponenter.
I Objectorienterade språk tillkommer inkapslingen av både variabler och metoder samt mer komplex kommunikation mellan olika objekt. Skillnaden mellan transienta och persistenta objekt är en viktig del också. Det tog flera år innan jag förstod hur man kan använda objektorienteringen, men det berodde inte på att jag var korkad utan på att det var förskräckligt dålig pedagogik vid utlärning av objektorientering i början (Dvs på 1980-talet).
Resten är mest att lära sig funktions-/klassbibliotek av färdiga komponenter.
Det har dock tagit många år innan jag lärt mig hur man ska tänka för att göra bra program (det finns ingen riktig utbildning som lär ut detta på ett bra sätt), dvs program som har en bra struktur som är lätt att underhålla och bygga ut utan att skapa spagettistruktur.
Idag begriper jag att man inte bara kan sätta sig och börja knacka kod om man ska bygga en applikation. Man måste först ha ett klart och tydligt mål så man vet vilka avgränsningar man ska jobba med, annars växer koden till oigennkännbarbarhet ganska snabbt. Man måste ha glasklart för sig när man är klar.
En aspekt som man lär sig med mer erfarenhet är att man hela tiden måste genomsyra sitt tänkande med "återanvändbarhet" av allt arbete man gör. Man ska aldrig skriva samma sak mer än en gång, sen ska man återanvända det man tidigare har gjort. Det tänkandet och arbetssättet underlättas betydligt av objektoerienteringen. Med hjälp av objektoerienteringen och komponenttänkandet så kan man både öka graden av återanvändning och även dölja komplex funktionalitet så den blir enkel att använda.
Sen ska man tänka igenom strukturen så den blir modulär, dvs att man kan bygga upp systemet i små delar som man kan kalla komponenter (en komponent är en tydlig avgränsning av funktionalitet som man kan återanvända på andra ställen i samma system eller i helt andra system).
Avslutningsvis så är namnsättning av klasser, variabler, konstanter och metoder en mycket viktig del av all sytemutveckling. Det har tagit mig åtminstonde 10 år innan jag uppnådde en enligt min mening acceptabel förståelse för hur viktigt en bra arbetstmetodik är för at bygga bra system.
Några av mina principer för att bygga bra system (dessa bygger på mer än 32 års utvecklarerfarenhet, varav 22 som yrkesman):
- Kravstyrt med dokumenterade verksamhetskrav
- Lyssna aldrig på idioter som vill att du ska börja bygga ett system utan dokumenterade krav
- Lätt för användaren att använda
- Ska inte kräva manual för att använda utan ska vara intuitivt dvs självklart hur man ska använda det
- Tänk återanvändning hela tiden
- Använd färdiga komponenter/klassbibliotek/ramverk
- Bygg alltid en wrapperklass runt externa komponenter så de blir lätta att byta ut
- Bygg gärna prototyper för att testa ny funktionalitet eller för att visa layout för användare
- Modulärt
- Komponentbaserat
- Objektorienterat
- Välkommenterat, Väldokumenterat, skriv pedagogiska och tydliga kommentarer
- Tänk på att den som ska läsa din kod är nästa programmerare och denne kan mindre om systemet än vad du kan
- Verksamhetsstyrd och smart namnsättning av alla identifierare med begrepp från verksamheten inte teknisk namnsättning
- Stark typning undvik svagt typade språk
- Kompilerande språk undvik dynamiska språk
- Slå på alla varningar så utvecklingsmiljön hjälper till att hitta dålig kod tidigt
- Bygg systemet med enhetstester och testa hela systemet med automatiska tester så du inte skippar tester pga lathet
- Testa hela systemet flera gånger varje dag under utvecklingen
- Var vaksam på att en liten förädring påverkar hela systemets stabilitet, TESTA OFTARE MED AUTOMATISKA TESTER