Joel on Software

Joel on Software   Joel om mjukvara

 

Andra "Joel on Software"-artiklar på svenska

Andra "Joel on Software"-artiklar på engelska

Skicka e-post till författaren (enbart engelska)

 

Saker du aldrig skall göra, del 1


Av Joel Spolsky
Översatt av Karl Ahlin
Bearbetat av David Pettersson
den 6 april 2000

Äntligen har första betaversionen av Netscape 6.0 släppts. Det fanns aldrig en version 5.0. Den senaste stora versionen, version 4.0, släpptes för nästan tre år sedan. Tre år är en väldigt lång tid på Internet. Under dessa år har Netscape suttit bredvid och hjälplöst sett deras marknadsandel rasa.

Det är lite lumpet av mig att kritisera dem för att vänta så länge med att släppa en ny version. De gjorde det inte precis med flit, eller hur?

Jo, faktiskt det gjorde de. De gjorde det genom att göra det största strategiska misstaget som något programvaruföretag kan göra:

De beslöt sig för att skriva om sin kod från början.

Netscape var inte det första företaget att göra det här misstaget. Borland gjorde samma misstag då de köpte Arago och försökte göra om det till dBase för Windows, ett projekt dömt att misslyckas som tog så lång tid att genomföra att Microsoft Access tog över hela marknaden. Sedan gjorde de om samma misstag genom att skriva om Quattro Pro från början och överraska folk med hur få nyttiga funktioner det hade. Microsoft gjorde nästan om samma misstag genom att skriva om Word för Windows i ett dödsdömt projekt kallat Pyramid vilket avbröts, kastades iväg och sopades under mattan. Tursamt nog för Microsoft så hade de fortsatt att jobba parallellt med den gamla koden, så de hade någonting att sälja ändå, vilket gjorde det hela till enbart en ekonomisk katastrof och inte en strategisk sådan.

Vi är programmerare. Programmerare är i sina hjärtan arkitekter och det första de vill göra när de kommer till en ny byggplats är att schakta undan all gammal bråte och bygga någonting storartat i stället. Vi blir inte upphetsade av inkrementell renovering: meka, förbättra eller plantera rabatter.

Det finns en subtil anledning till att programmerare alltid vill slänga bort koden som finns och börja om från början. Anledningen är att de tror att koden är en enda röra. Här är den intressanta iakttagelsen: de har förmodligen fel. Anledningen till att de tror att den gamla koden är rörig är på grund av en avgörande, fundamental programmeringslag:

Det är svårare att läsa kod än att skriva den.

Det är anledningen till att återanvändning av kod är så svårt. Det är anledningen till att alla i din grupp har en egen version av en funktion som delar isär en sträng till en vektor av strängar. De gör en egen funktion för att det är lättare och roligare än att lista ut hur den gamla funktionen fungerar.

En naturlig följd av detta axiom är att du kan fråga nästan vilken programmerare som helst idag om koden de arbetar på och få svaret "Det är en enda röra. Helst skulle jag vilja slänga den och börja om från början."

Varför är den rörig?

"Jo", blir svaret, "titta på den här funktionen. Den är två sidor lång! Inget av det här joxet hör hemma här! Jag vet inte ens vad hälften av de här API-anropen gör."

Innan Borlands nya kalkylprogram för Windows lanserades citerades Philippe Kahn, Borlands färgstarke grundare, i pressen där han skröt om hur mycket bättre Quattro Pro skulle vara än Microsoft Excel eftersom man börjat om från början. Helt ny källkod! Som om källkod rostar.

Tanken att ny kod är bättre än gammal är helt klart absurd. Gammal kod har använts. Den har testats. Många buggar har hittats och fixats. Det är inget fel på den. Den samlar inte på sig buggar genom att ligga och dega på hårddisken. Au contraire, älskling! Ska programvara vara som en gammal Dodge Dart som rostar bara genom att stå i garaget? Är programvara som en teddybjörn som är lite snuskig om den inte är tillverkad av helt nytt material?

Åter till tvåsidorsfunktionen. Ja, jag vet, det är en enkel funktion som visar ett fönster men det har börjat växa små ludna hårstrån på den och ingen vet varför. Låt mig berätta varför: det är buggfixar. En av dem fixar en bugg som Nancy upptäckte när hon försökte installera hela paketet på en dator utan Internet Explorer. En annan fixar en bugg som uppträder när minnet börjar ta slut. En annan fixar en bugg som dyker upp när en fil finns på en diskett och användaren tar ut disketten efter halva läsningen. LoadLibrary-anropet är fult men gör så att koden fungerar på gamla versioner av Windows 95.

Det krävdes flera veckor av användning i den riktiga världen för att upptäcka varenda en av dessa buggar. Programmeraren kan ha ägnat några dagar på att återskapa buggen i ett labb och sedan fixa den. Om den är som många andra buggar så är buggfixen kanske en rad kod, eller kanske ett par tecken, men det tog mycket arbete och tid att ändra dessa tecken.

När du slänger iväg kod och börjar om från början så slänger du iväg all den kunskapen. Alla samlade buggfixar. År av programmeringsarbete.

Du slänger iväg din marknadsfördel. Du ger dina konkurrenter två eller tre år i present, och tro mig, det är en lång tid i programvaruvärlden.

Du försätter dig själv i en extremt farlig position där du kommer att leverera en gammal version av koden i flera år och under tiden kan du inte göra strategiska ändringar eller reagera på nya funktioner som marknaden kräver eftersom du inte har kod som går att leverera. Du kan lika gärna stänga ner under tiden.

Du spenderar enorma mängder pengar på att skriva kod som redan existerar.

Finns det ett alternativ? Den allmänna uppfattningen verkar vara att den gamla Netscape-koden var riktigt dålig. Okej, den kanske var dålig, men vet du vad? Den fungerade riktigt bra på väldigt många datorsystem i den riktiga världen.

När programmerare säger att deras kod är en salig röra (som de alltid gör) så finns det tre olika saker som är fel med den.

Först och främst finns det arkitekturella problem. Koden är inte särskilt väl faktoriserad. Nätverkskoden poppar upp sin egen dialogruta från absolut ingenstans; det skulle ha hanterats av UI-koden. Dessa problem kan lösas, ett i taget, genom att försiktigt flytta kod, omfaktorisera, ändra gränssnitt. Detta kan göras av en programmerare som arbetar försiktigt och som checkar in alla sina ändringar på en gång så att ingen annan blir störd. Även ganska stora arkitekturella förändringar kan göras utan att kasta bort koden. Vid ett tillfälle under Juno-projektet lade vi ner flera månader på att ändra arkitekturen: bara flytta runt saker, rensa upp, skapa basklasser som var vettiga och skapa vassa gränssnitt mellan modulerna. Men vi gjorde det försiktigt, med vår existerande kodbas, och vi förde inte in några nya buggar eller slängde bort fungerande kod.

En andra anledning till att programmerare tror att deras kod är en röra är att den är ineffektiv. Det ryktades att koden som ritade upp sidor i Netscape var långsam. Men denna typ av fel påverkar bara en liten del av projektet och den kan man optimera eller till och med skriva om. Du måste inte göra om allting. När man optimerar för hastighet så gör man 1% av arbetet för 99% av effekten.

För det tredje: koden kan vara estetiskt ful. Ett projekt jag jobbade med hade faktiskt en datatyp som hette FuckedString. Ett annat hade från början använt konventionen att börja medlemsvariabler med "_", men bytte sedan till det mer standardiserade "m_". Så hälften av funktionerna började med "_" och andra hälften med "m_", vilket var fult. Ärligt talat löser man sådana här problem på fem minuter med ett makro i Emacs, inte genom att börja om från början.

Det är viktigt att komma ihåg att när du börjar om från början finns det absolut ingen anledning att tro att du kommer att göra ett bättre jobb än du gjorde första gången. Först och främst så har du förmodligen inte samma grupp med programmerare som arbetade på version ett, så du har egentligen inte "större erfarenhet". Du kommer bara att göra om större delen av de gamla misstagen igen och skapa några nya problem som inte fanns i den första versionen.

Det gamla mantrat bygg en som du slänger är farligt när det tillämpas på storskaliga kommersiella tillämpningar. Om du skriver experimentell kod så kanske du vill ta bort funktionen du skrev i förra veckan när du kommer på en bättre algoritm. Det är okej. Du kanske vill omfaktorisera en klass för att göra den mer lättanvänd. Det är också okej. Men att kasta bort ett helt program är farlig fåfänga och om Netscape hade haft en vuxen ledning med erfarenhet från programvaruindustrin så kanske de inte hade skjutit sig själva i foten så illa.



Originalartikelns engelska titel är Things You Should Never Do  

Joel Spolsky driver Fog Creek Software, ett litet programvaruföretag i New York. Han har examen från Yale och har arbetat som programmerare och i chefsbefattning på Microsoft, Viacom och Juno.


Innehållet på dessa sidor representerar en enskild persons åsikter.
Allt innehåll är Copyright ©1999-2005  Joel Spolsky. Alla rättigheter är reserverade.

FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky