Det føles bra å slette gammel kode. Men hvordan gjør man det egentlig? Hvordan identifisere linjene som trygt kan slettes? Vi har arvet legacy programvare skrevet for lenge siden av folk som nå jobber helt andre steder. Vi skal ikke bare kaste hele systemet og insistere på at her må man begynne på nytt? Neida.

Vi har lært noen triks som gjør rydde-jobben til en dans på røde deletions… Vi har brukt OpenTelemetry for å finne ut hvilke API-er som faktisk er i bruk. Deretter statisk kodeanalyse for å få hjelp til å finne hvilke bestanddeler av applikasjonen som nå kan fjernes.

Men først. Hvorfor er det vits å gjøre jobben med å slette gammel kode? Det er forståelig om man opplever kode som noe verdifullt. Linje for linje med finurligheter, programmert av navngitte utviklere før oss. Det var jo vanskelig å utvikle dette! Da er det også vanskelig å lese koden og forstå programvaren mange år seinere. Tryggest å ikke røre koden for mye. Kan det ikke bare bli liggende? Men vi skal jo opp et fjell, og da er det nyttig å undersøke hva som egentlig fins oppi denne tunge ryggsekken vi skal bære med oss. Kode som ikke har blitt undersøkt på en stund kan skjule både gull og gråstein.

Siden november har team rubrikk slettet skikkelig mye kode i den mest sentrale applikasjonen vi eier. Skulle nesten tro vi er et team som motarbeider virksomheten?! 😆

Hvorfor er det nyttig å slette kode?

Vi tror de viktigste gevinstene handler om å…

• minske kognitiv last ved debugging, vedlikehold og fremtidig videreutvikling
• fjerne sikkerhetshull i svak kode (var det noen som sa SQL injections?!)
• ta vekk avhengigheter og gjøre oppgraderinger enklere fremover
• slette data som prosjektet ikke lenger trenger

Kode er en kostnad 💸

Det er mange som har beskrevet gjennom årene hvordan kode er en kostnad, at det er dyrt med for mye kode. Vi leste nylig Cory Doctorow sin underholdende rant om hvordan Code is a liability (not an asset) der han spesielt forklarer hvordan AI produserer «10,000 times more liabilities» og en detaljert gjennomgang av hvordan det blir et problem…

Writing code that works, without consideration of how it will fail, is a recipe for catastrophe. It is a way to create tech debt at scale. It is shoveling asbestos into the walls of our technological society.

Hvis vi ser inn i krystallkula og prøver å forutsi hvilke ferdigheter fremtidens utviklere trenger -- kanskje det er å slette kode?

Sånn kan vi finne ut hvilke APIer som er i bruk

Det er én ting å si at det er smart å slette kode som ikke er i bruk; noe helt annet å få 10-15 git repositories i fanget og faktisk gå i gang. Applikasjonene til vårt team har kjørt på sparebluss i mange år, og derfor er det ikke så mange mennesker vi kan spørre til råds for å finne ut av hvilke APIer vi kan kvitte oss med. Heldigvis finnes det grep vi kan ta som gjør det ganske enkelt å sjekke bruksmønster for slikt!

De viktigste backend-applikasjonene i vårt team er webapplikasjoner som kjører på Java, og da er det veldig lett å legge på opentelemetry java agent for å hente inn metrikker vi kan bruke for å telle API-trafikk.

I Amedia er det lett å samle inn metrikker fra prometheus-kompatible endepunkter i applikasjonene våre, og det kan opentelemetry-agenten hjelpe oss med ganske enkelt. Her er et eksempel fra en Dockerfile som viser hvordan:

CMD ["java", "-javaagent:/app/opentelemetry-javaagent.jar", \
  "-Dotel.service.name=frontier", \
  "-Dotel.metrics.exporter=prometheus", \
  "-Dotel.exporter.prometheus.port=9464", \
  "-Dotel.logs.exporter=none", \
  "-jar", "/app/frontier.jar"]

Da kommer det metrikker på http://localhost:9464/metrics i podden. Den meste interessante for vår del er http_server_request_duration_count som automatisk kan samles inn av agenten, for mange forskjellige webrammeverk for Java. Da kan vi hente ut trafikk per http-endepunkt med en enkel spørring mot prometheus slik:

sum by(http_route) (http_server_request_duration_seconds_count{application="frontier"})

Opentelemetry-agenten er smart nok til å vaske bort IDer og den slags fra URLer, slik at dette blir en overkommelig mengde data å se på. I tilfellet denne applikasjonen oppdaget vi ganske fort at bare rundt en tredjedel av API-overflaten var i bruk. Da er det bare å vente til man føler seg trygg på at man har nok data, og så begynne ryddejobben. 🥳

Sånn kan vi sjekke hvor trafikken kommer fra - kanskje vi kan skru av klienten og slette APIet likevel?

Et nyttig tillegg når vi allerede er i gang med OpenTelemetry er å sette opp spor, eller traces for å kunne se trafikk flyte gjennom flere systemer. Da kan vi noen ganger avdekke mønstre som vi kan bruke til å slette enda mer kode.

Vi har for eksempel sett tilfeller av at det starter jobber i én applikasjon, hvor den applikasjonen egentlig ikke gjør noe mye mer enn å starte ting i en annen applikasjon via HTTP API. Noen gangen kan vi få mye bedre oversikt ved å flytte koden til en slik jobb inn i applikasjonen som utfører arbeidet uansett, og da kan vi også bli kvitt både API og klientkode.

Når vi har slettet et API så kan vi kvitte oss med koden ganske automatisk

Når man sletter et API-endepunkt ender man typisk sett opp med ganske mye død kode. Det er lett å gi seg her, og tenke at den døde koden ikke skader noen. Det kan hende det er sant, men den hjelper neppe noen heller! Tvert i mot så kan folk som søker i kode bli lurt til å tro ting om hvordan verden virker, som slett ikke stemmer. Dette gjelder spesielt når man søker på tvers av flere repositories, for eksempel med søket til github eller verktøy som grep eller ripgrep. Derfor er det verdifullt å kvitte seg med den koden som ble død kode også, og slett ikke så vanskelig som man kanskje kunne tro!

I vårt tilfelle har vi brukt IDEA til dette, men denne typen funksjonalitet finnes nok også i mange alternative produkter. IntelliJ har tooltips som kan vise oss at en kodesnutt vi ser på er ubrukt, typisk ved at metode, variabel- eller klassenavnet får en svakere farge. Det som ikke er åpenbart er at du kan få IntelliJ til å lage en rapport over all ubrukt kode i prosjektet ditt for deg!

Da kan vi velge Run inspection by name fra code-menyen, og taste inn unused declaration. Merk at det er viktig at vi velger riktig programmeringsspråk her.

Når vi kjører unused declarations kan det være en fordel å få IDEA til å varsle også om private felter som ikke er i bruk - ofte er det slik vi klarer å slette den siste gjenstående referansen til en klasse, slik at vi kan slette hele klassen.

Til slutt så får vi en liste av ubrukte kode, hvor IDEA gjør det veldig lett å velge "Safe Delete" for å kvitte seg med kode man ikke trenger.

Psst, den øverste figuren om code frequency representerer ikke nøyaktig årstall og heller ikke presise mengder hverken additions eller deletions. Det er muligens en illustrasjon laget for dramatisk effekt, men her er et helt ekte og originalt skjermbilde fra GitHub som vi synes er stas: