Frågeställningen om vad som anses vara bra kod har gäckat programmerare i decennier och kommer säkerligen vara ett ämne för dissektion långt in i framtiden. Då jag själv har programmerat professionellt i några år nu så tänkte jag skriva lite om de insikter och åsikter jag fått om ämnet.
Vad som anses vara bra kod kan som sagt diskuteras i oändlighet. Jag kommer inte gå in på nivån där det argumenteras om goto skapar spagettikod eller om globala variabler är ren ondska, det kan visserligen vara en rolig diskussion men är också otroligt subjektivt. Denna text ämnar ligga på en lite högre abstraktionsnivå och fokuserar snarare på programmering som en teamsyssla där kodens tillgänglighet för andra är i fokus. Då program utvecklas i team så kokar kärnan av snygg programmering nämligen enligt mig ner till en simpel fråga ”vem är mottagaren?”. Nästan alla av oss som programmerar jobbar antagligen i team och genom att känna till sina kollegors styrkor och förstå deras arbetssätt kan vi ofta anpassa den kod vi skriver till att fungera väl för den organisation vi arbetar i.
Att förstå sina kollegors styrkor är en viktig del av att jobba i ett team, beroende på om kollegorna i fråga är nyexade eller har tjugo års erfarenhet varierar antagligen deras bekvämlighet med er kodbas. Speciellt om den innehåller nischade eller äldre teknologier som inte studeras under dagens utbildningar. Därmed blir saker som kodstruktur, standarder och kommentering mycket viktiga för att förenkla möjligheten som du och dina kollegor gemensamt har för att förstå och arbeta i kodbasen.
Att använda en kodstandard är för många självklart och detta är något även jag vill ställa mig bakom. En bra kodstandard som är utarbetad i en organisation kan hjälpa till att skapa ett gemensamt och strukturerat utseende på kodbasen. En kodstandard kan också hjälpa en programmerare med hur de bör bemöta och strukturera lösningar på problem.
Jag tror att detta är något de flesta utvecklare kan ensa om, det är kul att använda och hitta olika tekniska lösningar på sina problem. Och detta är självklart bra. Dock så tycker jag att det är viktigt att komma ihåg uttrycket ”för mycket av det goda” när man introducerar tekniker i sin kodbas. Att använda mängder av tekniker under utveckling ökar ofta kodens komplexitet och gör den svårare att förstå och följa för de som inte är lika bekväma i de teknikval som tagits. Jag tycker därför det är viktigt att ensa om de tekniker som används och försöka hålla en röd tråd i de teknikval som tas så att återanvändningen är hög och komplexiteten är låg.
Styrkor, standarder och teknik är alla tre områden som kraftigt överlappar varandra men jag tror att alla i någon utsträckning blandas samman till att bli den kodbas en organisation arbetar med. Jag tror också att om dessa tre områden hålls i balans så kommer en mer gemensam och sammanhängande kodbas skapas där alla utvecklare kan fortsätta att utvecklas men också bidra med sina egna styrkor vare sig de är nya eller erfarna.
// Mats Levin, Consultant, Prevas AB
Du måste vara inloggad för att få kommentera
Stängd för fler kommentarer
Relaterade artiklar
Hur kan vi förbättra användarupplevelsen i gamla system
Anna-Karin Alm: Är det bättre att satsa amerikanskt?
Hållbara vardagshjältar behövs
Stopp i produktionen
Predictive Maintenance, Why, What, and How
Verksamheten i fokus
Möt produktionsutmaningarna med IndTech
Vill du ta ett första steg mot bättre underhållsplanering
4 snabba tips när olyckan inträffar på din arbetsplats
Vårda och skapa starka lösenord
Så får du din produktion att blomstra
Är det dåligt att återanvända lösenord?
Harmonisering av sensordata gör Internet of Things (IoT) enkelt
Hållbar produktion skapas på gränsen mellan ordning och kaos
Vad kan industrin göra redan idag för att skapa en hållbar framtid?
Har du koll på Agenda 2030, och målen om hållbar industri och produktion?
Chilla, låt systemet göra jobbet
Välj smart, låt systemet göra jobbet
Därför repade sig Chile snabbare än Haiti från jordbävningen 2010
Tar pulsen på energibranschen, Vattenfall Eldistribution
Internet of Moving Things – Kristoffer om samarbetet med Wittra
Mer om DFX, med fokus på Design for Serviceability
Tar pulsen på energibranschen, Göteborg Energi
I påskharens godislager
Mer om DFX, med fokus på Design for Assembly
Med digitalisering och fältservice löser man ärenden med färre kundbesök
DFX – vad är det
The devil is in the details
Blev det fel eller har julklappen redan pajjat
Jultomten har läget under kontroll
Jultomten måste planera om resan
Jultomten behöver assistans
Tre steg till testautomatiserad miljö
I Jultomtens fältverkstad
Digitalisering av fältservice, film del 2
IoT del 4 - vår nya affärsmodell
Kemikalielagstiftningar, mycket att tänka på
Hur kan industrin utnyttja gamification
Digitalisering av fältservice, film del 1
Vad krävs för att medicintekniska produkter, certifierade under MDD eller AIMDD, ska få fortsätta att säljas i EU
Gamification, i din vardag
Smartare Elektronikhandboken
Klinisk utvärdering av medicintekniska produkter
Framtidens fastighetsunderhåll – digitala tvillingar i fokus
Bildbehandling, inte så komplicerat som det låter
IoT del 3 - vår nya affärsmodell
Att gå med i ett partnernätverk – vad innebär det för mig
Shh - don't say it Innovation too aloud
Underhållssystem – varför välja molnet
Vad är UX och varför är det så viktigt för mitt företag
IoT del 2 - vår nya affärsmodell
Nyfiken på hur du kan digitalisera din fältservice
Är min app en medicinteknisk produkt
Fältservice – vem är din ledstjärna
En IoT fabrik på fyra hjul
Prototyping i Figma
IoT del 1 - vår nya affärsmodell
Brexit, Microservices och AI
Hello IoT Button
Smart Maintenance for competitive edge
Taking advantage of electronics in modern healthcare
En resa in i framtiden
Digitalisering och automation - på rätt sätt
Mobil teknologi växer inom hälso och sjukvården
Kommentarer