Alla mjukvaruprojekt borde ha en Kodkvast!

– “All kod är en skuld!”
– “Den bästa koden är den kod man inte skriver!”
– “Snabbaste sättet att få upp testtäckningen är att ta bort död kod!”

Jag tror att alla är överens om att det är bra att hålla sin kodbas så liten och kompakt som möjligt. Byggtider hålls korta, testsviter går fort att genomföra, driftsättningar går fort, statisk kodanalys går fort, nya teammedlemmar kommer snabbt in i koden, risken för buggar och sårbarheter hålls nere och så vidare. Kort sagt, man blir mer lättrörlig!

Så alla utvecklingsteam borde ägna tid åt att inte bara skriva ny kod, utan också att faktiskt städa efter sig. Men det är lättare sagt än gjort…

Så länge som man skriver ny kod är det ju inte så svårt, eftersom vi alla bygger det minsta möjliga som kan fungera och äter YAGNI till frukost, eller hur 😉 Men sanningen är ju den att allt eftersom tiden lider och mjukvaran varit i produktion ett tag så kommer kodbasen ofrånkomligen att svälla och innehålla mer och mer skräp. Kod som man egentligen borde ta bort, eftersom den inte används av riktiga slutanvändare.

Problemet accentueras dessutom av moderna fenomen som Lean Startup och Continuous Delivery  som ju poängterar att man skall driftsätta lite och ofta, gärna rena experiment för att ta reda på vad kunderna egentligen vill ha. En del av dessa experiment faller inte väl ut, och borde således städas bort. Men handen på hjärtat, hur ofta sker det? Hur lätt är det att identifiera vad som skall tas bort?

Så vad kan man göra för att identifiera kodskräp?

– “Intellij rapporterar ju vad som är död kod!” kanske du säger.

IDE-stödet för identifiering av död kod baseras på statisk kodanalys. IDE:n förslår aldrig borttagning av en publik metod, för den kan inte veta vilka klienter till koden som finns och som kan tänkas anropa dessa metoder. Så denna annars så förträffliga IDE-funktion har begränsat värde i det här sammanhanget.

Samma resonemang gäller om man använder code coverage-verktyg under acceptanstester. Den kod som verktyget identifierar som okörd indikerar ofta bara en brist i testsviten. Den naturliga reaktionen är då att skriva ytterligare tester. Om ni har en acceptanstestsvit som testar exakt det som er produkt skall klara av och allt som testtäckingsverktyget rapporterar som okört kan tas bort så är ni att gratulera. Ni har inte problemet som jag målar upp 🙂

Många företag lägger in olika former av feature trackers i sina produkter för att lära sig kundernas användningsmönster. Det kan vara JavaScript-snuttar i webbsidorna eller manuellt inlagd instrumentering av programkoden. Dessa verktyg är bra, för de hjälper produktägaren att inse vad som är värdefulla produktfunktioner. De är däremot tämligen värdelösa på att peka ut vad som inte används och som borde gallras ut.

Nå, men att analysera loggfilerna då? Samma sak här, loggfilerna pekar ut vad som används, inte vad som är död kod.

Vad man egentligen skulle vilja ha

Det man egentligen skulle vilja ha är ett verktyg – låt oss kalla det en kodkvast – som

  • Automatiskt registrerar tidpunkterna för de publika metoder som används av riktiga användare i samtliga appar i samtliga produktionsservrar.
  • Automatiskt sammanställer insamlade användningsdata med en lista på samtliga publika metoder i de installerade applikationerna.
  • Automatiskt levererar användningsdata från samtliga applikationer som delar samma kodbas (t.ex. front-office, mobil-API och back-office) till en gemensam databas.
  • Går att applicera med minimal risk, dvs inte riskerar jar hell i de egna applikationerna.
  • Har minimal påverkan på CPU-, disk-, minnes- eller nätverksanvändning.
  • Kan tillämpas på en befintlig applikation i produktion utan kodändringar.
  • Kräver minimal påverkan på applikationernas startskript.
  • I den gemensamma databasen har verktyg för att identifiera kod som inte har körts på X dagar.
  • Gör den aggregerade informationen enkelt tillgänglig för utvecklingsteamen, utan att man behöver släppa in dem i produktionsservrarna.

Värdet på “X dagar” är högst branchspecifikt. För en tidningssajt är det kanske så lite som två veckor. För Gymnasieintagningen är det kanske drygt ett år. För valmyndigheten är det troligen mer än en mandatperiod!

När man väl efter X dagar har identifierat och tagit bort oanvända publika metoder med tillhörande tester, så kommer IDE-stödet för att hitta statiskt död kod väl till pass! Ofta finns det en eller flera privata hjälpmetoder bakom varje publik metod, och när man väl börjar nysta så kan det visa sig vara ganska mycket som är dött.

Vilka kodkvastar finns det då där ute?

Så vitt jag vet inga alls! Jag har googlat – och jag är bra på att googla – men inte hittat något med dessa egenskaper. De flesta Runtime Intelligence-verktyg jag har hittat fokuserar på att hitta problem och flaskhalsar i den kod man har. De hjälper inte till med att identifiera död kod.

Så vad händer nu?

Du mailar mig och säger att du är intresserad av Kodkvasten. Du hittar min mailadress i min konsultprofil.

Är tillräckligt många intresserade så kanske vi på Crisp drar igång något. I så fall vill vi ju i sann lean-anda bygga något minimalt som åtminstone någon kan använda, så vi behöver veta följande:

  • Vilken JVM-version kör ni?
  • Vilka JVM-språk använder ni?
  • Vilket operativsystem kör era produktionsservrar?
  • Typ av tillämpning: fristående app, war eller ear?
  • Vilken webbserver eller appserver använder ni (om tillämpligt)?
  • Vilka webbramverk använder ni (om tillämpligt)?
  • Har ni JSP-sidor?

Följande vore kul att veta, men är helt frivilligt:

  • Berätta lite om dig själv och ditt företag!
  • Vilken bransch verkar ni inom?
  • Ungefär hur stor är er kodbas i antal klasser/källkodsrader?
  • Hur många olika appar byggs ur samma kodbas?
  • Hur många produktionsservrar deployas koden på?
  • Hur ofta produktionssätter ni ny kod?
  • Vad skulle ert värde på X dagar vara, dvs hur många dagar måste kod vara oanvänd för att kunna betraktas som död?

Det vore jättekul att få bygga Kodkvasten, men det gäller ju att någon vill ha den också…

5 responses on “Alla mjukvaruprojekt borde ha en Kodkvast!

  1. Kul ide Olle,

    Entropins lagar fungerar även på programkod. Kod ruttnar om man inte aktivt städar och jobbar med sina strukturer.

    I dagsläget är det enklaste sättet att ta sig mod att slänga koden och bygga upp det igen från scratch. Tar faktiskt inte så lång tid som man tror om man kan låta bli att skriva kod som inte kommer exekveras (hörde jag framework och platform?).

    Men….

    Att hitta död kod är verkligen bara en del av jobbet. Man skulle behöva en bra integration i ett IDE mellan identifiering av död kod och sedan den refaktoring som möjliggörs baserat på den reducerade kodmassan. Oops.. nu blev det plötsligt lite svårare…

    1. Visst är det frestande att kasta bort och skriva om då och då! Fast ännu skönare är att helt enkelt trycka på DEL-knappen OM man kan vara tryggt förvissad om att metoden ifråga verkligen är död!

      Blir liksom bättre bang-for-the-bucks på det viset.

  2. En snål version av kodkvasten är att logga med löpnummer, tex MyLog.info(“0104: User changed address”). Därefter letar man i loggen efter luckor i löpnumren.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.