7 Juni 2018

Lågt hängande frukt i ekosystemet

Nyligen behövde jag konvertera strängar till Title-Case-format. Konverteringen var bara en liten del av det som krävdes för att göra klart funktionen jag jobbade på och klockan tickade på. Jag funderade i fem sekunder över hur jag skulle lösa problemet och bestämde mig för att försöka hitta ett paket från NPM istället för att skriva min egen funktion för konverteringen. Det första paketet jag hittade hade några hundra tusen nedladdningar per vecka och utan närmare eftertanke installerade jag det i vår app. Efter att ha testat paketet en stund kunde jag konstatera att det verkade göra susen.

Jag tror att de flesta utvecklare som jobbar med Javascript har erfarenhet av de positiva sidorna i ekosystemet. Som till exempel att kunna lösa alla möjliga problem genom att använda befintliga paket eller med populära bibliotek som lodash eller underscore (tyvärr saknar båda en title-case-funktion i nuläget). Men det finns också en oro över att bli beroende av bibliotek och ramverk i ett snabbt föränderligt ekosystem. Men det finns även en oro över att bli beroende av ramverk och bibliotek som vem som helst kan bygga och sprida, vilket diskuteras i denna artikel.

Title-Case-paketet spred sig genom appen och det var först senare, då en ny vy implementeras som som jag insåg att det finns sidoeffekter på de formaterade strängarna. I utvecklingen av den nya vyn önskade kunden att datat skulle sorteras på ett specifikt textfält. Inga problem! Men ordningen på det sorterade datat såg konstigt ut och inte alls i alfabetisk ordning som kraven specificerade. Efter att ha kliat mig i huvudet och felsökt i koden en stund kunde jag konstatera att det var Title-Case-paketet som var boven i dramat. I källkoden för paketet fanns en regexp som delvis gjorde formateringen men också raderade specialtecken. Det visade sig att datat sorterades på oformaterade strängar, som innehöll specialtecken, men renderades efter att title-case-funktionen gjort sin konvertering . I slutändan skrev vi en egen funktion för konverteringen. (P.S. Jag menar inte att utvecklaren som skrivit biblioteket gjort något fel)

Anledningen till att använda paketet var för att spara tid gentemot att skriva en egen funktion. I javascriptvärlden är vi vana att kunna plocka våra verktyg och hjälpmedel och ett paket med några hundra tusen nedladdningar i veckan bör ju vara bevis nog för att paketet uppfyller vad det lovar. Problemen i detta fall upptäcktes i och med ett krav från vår kund men utan detta krav hade det kanske tagit väldigt mycket tid tills vi upptäckt att det fanns ett problem med datat som processerats, sorterats och renderats. Läxan i detta fall är liten men jag tror ändå att det är en viktig lärdom när det kommer till att väga kostnad och tid mot varandra. Hur långt tid hade det tagit att skriva en funktion för konverteringen själv? Antagligen inte särskilt länge. Efter att vi insett att paketet hade sidoeffekter på strängarna kändes det rimligt att skriva vår egna funktion, vilket kanske borde varit det rimliga från första början. Så i framtiden tänker jag tänka lite längre än fem sekunder innan jag skamlöst lägger till utility-paket till apparna jag bygger. Kanske är det där som de riktiga tidsbesparingarna kan ske?