Det finns så många platser och sätt att lära sig programmera, vi behöver bara veta var vi ska leta. Ändå försummar vi ofta äldre kod. Programmering kan läras på många sätt. Men hur vi än gjorde det gjorde vi det inte på egen hand. Under vår resa fanns det många böcker, onlinekurser och dokumentation.
När vi gick igenom det här materialet snubblade vi över en massa råd om hur saker kunde göras och vad som bör undvikas. Alla dessa råd är en ansamling av erfarenheter från personerna som skrev materialet och många andra som delade med sig av sina erfarenheter före dem.
Det är vad jag gillar att kalla lånad kunskap. Det är inte vår kunskap, vi “lånar” den. Vi gör saker på ett visst sätt, men det garanterar inte att vi förstår vad vi gör.
Till exemple om vi nu håller på med microservice-arkitektur.
- Varför? Vilket problem försöker vi lösa? Vad är fördelarna? Vad är nackdelarna? Håller vi på med mikrotjänstarkitektur eller håller vi på med distribuerad monolit? Behöver vi mikrotjänster?
Detta är förmodligen det enklaste exemplet. Mikrotjänster används på senare tid som mantra. Det presenteras som den ultimata lösningen på alla våra problem. Missförstå mig inte, mikroservice arkitektur är ett vackert mönster, men det har sin egen plats.
Tills vi vet vad den platsen är, är mikrotjänster inte vår kunskap. Det är något som någon annan sa åt oss att göra. Och att rekommendera den skulle vara som att rekommendera en film som vi inte såg. Vi litar på någon annans filmsmak. Vi “lånar” den.
Detta är inte nödvändigtvis en dålig sak. Tänk på att vi arbetar för att leva, inte leva för att arbeta. Så att veta allt är inte det yttersta målet som vi bör sträva efter. Det är därför vi har egenartade tekniker och kodningsstandarder. För att visa oss vägen och för att eliminera behovet av att lära sig saker den hårda vägen. Vi behöver inte bli påkörda av en bil för att lära oss att titta åt båda hållen när vi korsar gatan.
Att ha en struktur av ett projekt, ett verktyg eller ett mönster som vi helt enkelt kan “plugga” till vår lösning utan mycket krångel är fantastiskt. Men det som definitivt borde vara vårt mål är att förstå vad vi gör, varför och när vi inte bör göra det på det sättet.
Äldre kod
Hur passar äldre kod i den här historien? Vad är ett bättre sätt att se varför vi bör eller inte bör göra något än att se det i handling? Ibland är kod bara ett offer för tid eller omständigheter, men i de flesta fall är äldre kod ett resultat av dåliga beslut.
Det är svårare att lägga märke till de dåliga besluten i början. När vi startar nya projekt är vi mest fokuserade på vad som behöver göras. Allt eftersom tiden går och programvara används börjar dåliga beslut dyka upp. Och det finns ingen bättre lärare än ett dåligt beslut.
I mjukvaruutveckling bör vi undvika tät koppling så mycket som möjligt. Men förstår vi verkligen varför? Och hur kan vi uppnå detta? Ibland är det OK att koppla ihop saker hårt om vi vet vad vi gör.
Till exempel, om vi använder en viss database går det bra att direkt använda det i affärslogik… om vi vet med säkerhet att vi inte kommer att ändra det. Om vi inte är så säkra bör vi lägga en abstraktionsnivå mellan vår affärslogik och dataåtkomstskiktet genom att använda arkiv, dataåtkomstobjekt eller något liknande.
Om vi någonsin har varit i en position där vi använder en database som saknar stöd, en anpassad lösning som inte längre uppfyller våra behov, eller helt enkelt majoriteten av anställda inte vet hur man använder det (och det finns ingen bra dokumentation), då förstår vi definitivt varför vi behöver den nivån av abstraktion. Att byta database skulle vara en mardröm, och att stanna kvar på befintlig database begränsar oss i vad vi kan göra. Det här är en förlust-förlust-situation.
Ett annat exempel, så karakteristiskt för äldre kod, skulle vara kodduplicering. Vi är alla (borde) överens om att kodduplicering är en dålig sak. Ändå finns det så många utvecklare som fortfarande duplicerar kod. Ibland till och med i stor skala. Alla av oss som någonsin har fixat en bugg, och det fortfarande finns ett felaktigt beteende i produktionen eftersom det finns två, tre eller fler kopior av samma kod som innehåller buggen, vet varför vi inte bör duplicera kod.
I en ny kodbas kan vi komma undan med det eftersom det fortfarande inte finns så mycket kod, och vi kommer fortfarande ihåg varje plats som vi behöver ändra, men det gör det inte mindre fel.
Slutsats
Att upprätthålla äldre kod är ofta deprimerande. Att hålla saker igång samtidigt som man hanterar en massa andra människors (eller dina) dåliga beslut blir snabbt frustrerande. Varje mail, samtal eller meddelande vi får betyder att något inte fungerar och vi måste åtgärda det. Det är svårt att inte bli påverkad av det.
Men att arbeta med äldre kod behöver inte vara en mardröm. Vi kan se det som en möjlighet att vässa vår kompetens. Varje kod är slutprodukten av en kedja av beslut som fattas för att lösa något problem. Genom att veta när, varför och hur saker gick fel kan vi lära oss mycket om mjukvaruutveckling. Och bara kanske koden som vi lämnade efter oss kommer att vara bättre än koden som vi ärvde.
Leave a Reply