Att skriva bättre kod för WordPress-baserade projekt
Jag minns inte exakt när jag först snubblade över Joel Spolskys blogg Joel on Software, men det var någon gång sent på gymnasiet.
Jag visste inte tillräckligt om hela mjukvaruutvecklingsprocessen för att få mycket av det han pratade om, men jag gillade hans skrivstil och jag njöt av vad han hade att säga.
Jag var faktiskt ett sådant fan att när jag tog examen fortsatte jag att köpa hans böcker (som var samlingar av artiklarna på hans sida) och läste dem från pärm till pärm. Jag hade kopior av dem på mitt skrivbord på jobbet, och jag använde en av hans böcker – Smart and Gets Things Done – när jag var teamledare.
De artiklar som fastnade mest för mig var dock de som handlade om att skriva bättre kod. Men här är grejen: Dessa artiklar innehöll ingenting om att faktiskt skriva kod.
Skriver bättre kod
Istället handlade det om processerna kring bättre kod. Och jag snubblade över en artikel – 16 år gammal, ändå – och jag tycker fortfarande att den är lika relevant idag som när jag först hittade den.
Förutom nu undrar jag själv hur det gäller min nuvarande utvecklingsspelning.
Joeltestet
För det första är artikeln i fråga en som jag kommer på mig själv att läsa minst en gång i månaden – om inte minst en gång i veckan – och jag kretsar allt kring vad han kallar The Joel Test. Det är tolv frågor som du ställer till ditt nuvarande utvecklingsteam.
- Använder du källkontroll?
- Kan du bygga i ett steg?
- Bygger du dagligen?
- Har du en buggdatabas?
- Fixar du buggar innan du skriver ny kod?
- Har du ett uppdaterat schema?
- Har du en specifikation?
- Har programmerare tysta arbetsförhållanden?
- Använder du de bästa verktygen man kan köpa för pengar?
- Har du testare?
- Skriver nya kandidater kod under sin intervju?
- Testar du användbarhet i hall?
Med tanke på att dessa frågor skrevs för 16 år sedan och till stor del är baserade på kompilerad kod, kan en del av terminologin behöva justeras.
Det snygga med The Joel Test är att det är lätt att få ett snabbt ja eller nej på varje fråga. Du behöver inte räkna ut rader-av-kod-per-dag eller genomsnittliga-buggar-per-böjningspunkt. Ge ditt lag 1 poäng för varje "ja"-svar.
Till exempel, snarare än att fråga om du kan göra en konstruktion till ett steg, kanske vi borde fråga om vi kan göra en implementering i ett steg. Du vet vad jag menar – att göra justeringar av sådana saker.
För det andra måste några av frågorna anpassas till avlägsna team eftersom vi inte alla är på samma kontor längre. Det vill säga, snarare än att testa korridorens användbarhet kan du behöva ta tag i någon du känner online, skicka dem till din testmiljö och fråga dem om projektet.
Joel-testet för WordPress
Kanske, för de av oss som använder WordPress som vår utvecklingsgrund, skulle vår uppsättning frågor se ut ungefär så här:
- Använder du källkontroll?
- Kan du göra en distribution i ett steg?
- Gör du dagliga distributioner?
- Har du en buggdatabas?
- Fixar du buggar innan du skriver ny kod?
- Har du ett uppdaterat schema?
- Har du krav och mockups?
- Har programmerare tysta arbetsförhållanden? Eller, om fjärrstyrning, tillåts programmerare att gå in i "Stör ej"-läge?
- Använder du de bästa verktygen på marknaden, antingen något gratis och öppen källkod eller något premium?
- Har du testare? (Och jag kan fråga om budgeten för projektet tillåter tid att skriva enhetstester för automatiserad testning också)?
- Har kandidater kodexempel tillgängliga på GitHub, en blogg eller en allmänt tillgänglig plats som kan granskas?
- Har du en grupp människor som du kan dra för att testa ditt pågående arbete?
Återigen är detta till stor del baserat på idén om ett litet, avlägset team snarare än ett stort produktföretag eller byrå på företagsnivå. Men det är något som jag fortfarande återkommer till då och då och undrar hur andra butiker står sig mot varandra.
Och hela poänggrejen?
En poäng på 12 är perfekt, 11 är acceptabelt, men 10 eller lägre och du har allvarliga problem. Sanningen är att de flesta programvaruorganisationer kör med ett poäng på 2 eller 3, och de behöver seriös hjälp…
Vi har alla något att sikta på, eller hur?
För nästa decennium?
Det är inte så mycket att jag tror att det är en tävling, men jag vet att jag skulle vilja kunna svara ja på de flesta av dessa frågor för mig själv och för dem jag jobbar med.
Men vid tidpunkten för denna artikel kan jag säga att jag inte kan säga ja till alla dessa, än mindre kanske hälften av dem. Men kanske i slutet av året kan jag det.
Och kanske kan vi andra som arbetar i branschen utvärdera våra team mot dessa frågor. Även om Internet och relaterad teknik går snabbt, har dessa frågor hållit sig väl i över ett decennium.