Att varje dag sträva efter att bli en bättre programmerare

Ser man på en elitidrottare så har dom tydliga mål och strävar  efter att bli bättre på de dom gör.  Skulle säga att man är inte så bra man kunde vara i sin proffesion om man slutar utveckla sig själv och bara gör som man "alltid" har gjort. 

Lyssnar man på programmeringsgurun Robert C Martin (Uncle Bob) på youtube så säger han bland annat att riktigt duktiga läkare och kirurger så sitter hemma på kvällarna och läser forskningsartiklar för att bli bättre på sitt jobb.  

IT- världen går så snabbt framåt så skall man hänga med och välja rätt lösningar så måste man förnya sig kontinuerligt annars halkar man efter och väljer fel lösning på ett problem. Har man en bra grundutbildning från någon av landets högskolor så förstår man syntaxen och kan skriva kod men för att bli riktigt bra så krävs de kontinuerlig träning. 

Till en viss del får man denna träning på arbetet men ofta så är kodbasen stor och trög att refactorera att man kommer inte åt att träna. Man behöver skriva andra mindre enklare program när man tränar. 

Bestämma sig för vad man vill leverera som programmerare

Innan man börjar träna på att bli bättre så måste man göra en analys var man står och vart man vill nå.

Eftersom programmerare inte har några regler att följa såsom piloter, kirurger, tandläkare, bokförare har så måste var och en tillsvidare fundera ut sina egna principer och följa dom.

För att hitta dina egna principer ställ dig frågorna:

1. Hittas de många buggar  i koden du skriver.

2. Hur bra prestanda är det i koden.

3. Hur lätt är koden att läsa och förstå av någon annan?

4. Är koden lätt att utöka och underhålla?

Om du ständigt släcker bränder, fixar buggar, dina program är långsamma och kunderna klagar konstant.  Kom ihåg att de är ingen annans fel än ditt eget. 

Vill du vara en programmerare som vet att du levererar programvara som kunderna älskar (du hör sällan av dom, de bara kör ditt program i ur och skur). Ny funktionalitet är lätt att införa utan att programmet får buggar i befintliga funktioner. Då finns det bara ett alternativ och de är att  lära sig hur man gör.

Utvecklingsteamet man ingår i

Om man ingår i ett team som jobbar med samma kodbas så skall man inte gå sin egen väg utan man måste få hela teamet med på att förändra sättet man jobbar på för att utveckla produkten åt rätt håll. De blir att kompromissa och lära sig av varandra. 

Hur går man då för att blir bättre?

Jobbar man heltid så kan de vara bra att ha en dialog med arbetgivaren hur man ser på sin proffession och hur man tillsammans med arbetsgivaren säkerställer att man får den fortbildning som krävs för att man skall bli bättre.

Men de finns väldigt få företag som har råd att utbilda sin personal så många timmar som man behöver lägga ner. Då återstår bara att man dessutom lägger ner egen tid på att blir en bättre programmerare. 

Om man inte har hur mycket tid som helst så kanske man behöver hjälp med att välja ut några områden att fördjupa sig i.  

Vad skall man satsa på?

Först och främst skaffa dig en rad källor där du kan hitta information som håller hög kvalite. Så som www.pluralsight.com som visserligen kostar en slant men de finns inga gratis luncher.

När du har bra källor att leta i satsa på att först lära dig sånt som inte är föråldrat imorgon. Om man surfar runt lite så kommer man fram till att de finns en del saker som hängt med ett tag och de verkar hänga med ett bra ta till.

Brukar delar upp en utveckling i olika faser, varje fas har sin utmaningar och metoder för att du skall lyckas. 

Förstudierfasen

Bra planering är halva arbetet brukar man säga. Oftast misslyckas man tidigt i ett projekt om man får fel information från första början. Men de finns metoder för att ställa dom rätta frågorna istället för att förvänta sig att man får informationen serverad.

Men att förstå vad ett program skall göra och och hur en användare vill jobba i det program du skall skriva är svårt. Ibland har man någon expert som kan förklara hur programmet skall fungera. Men hur användargränssnittet skall se ut och bete sig vet man oftast kunden först när man ser det och konstaterar "inte så här i allafall". 

För att göra rätt och riktigt här så finns det metoder för hur man går tillväga för att riktigt förstå vad och hur. 

För att nämna några jag läst om:
(User stories, Use cases, Event storming, Domän modellering)
User Experience (UX for Developers på Pluralsight är en bra början).

Bok: Domain Driven Design

Specifikationsfasen

Kunden har alltid förväntningar på vad du kommer att leverera. Var noga med att skriva ner vad programmet gör och inte gör. Desto osäkrare kunden är vad dom vill ha desto mera restriktiv skall specifikationen vara. Annars fixar du "buggar" som aldrig fanns med som funktion från första början. 

Utvecklingsfasen

TDD - test driven development

Robert C Martin en författare av flera böcker är förespråkare av denna arbetsmetod. Jag är beredd att hålla med om att skriva kod som testar produktionskoden automatiskt är den enda utvägen till att över tid hålla hög kvalitet i en programvara. Samtidigt som du får facit på hur de skall fungera så dokumenterar du hur koden fungerar. Så nästa person som skall förvalta de du skriver kan läsa testerna och förstå vad koden gör. Dvs de du lärde dig i förstudie fasen skriver du ner i testerna.

Källa: www.pluralsight.com

SOLID

Hur koden skall vara skriven för att vara testbar och kunna förändras över tid. Wikipedia om vad SOLID är. De tar länge att förstå alla SOLIDs principer och att få koden att följa alla dess principer.  

Design patterns

När man skall lösa ett specifikt problem så finns det ofta andra som gjort de före en själv och då kan man hitta ett mönster att följa. Dessa mönster guidar en rätt för att upfylla principerna som SOLID beskriver. 

Källa: www.pluralsight.com

Testfasen

Även om man har automatiserad testning så finns en gräns för vad löns att automatisera. Skriv ner dina testfall, utgå från use casen om du har sådana.

Källa: Lessons-Learned-Software-Testing-Context-Driven

Leverans och förvaltningsfasen

Skriva dokumentation och avtal är inte helt lätt, lite hjälp får man av IT2018 avtalsmallen. 

Användar manualer och instruktioner hur man installerar en programvara är oftast mera arbetsdrygt än man tror och skall inte underskattas. Har inte direkt hittat några arbetsmetoder annat än att skriva en disposition först och sen skriva själva innehållet.