Paremman koodin kirjoittaminen WordPress-pohjaisiin projekteihin
En muista tarkalleen, milloin törmäsin ensimmäisen kerran Joel Spolskyn blogiin Joel on Software, mutta se oli jossain vaiheessa myöhässä lukiosta.
En tiennyt tarpeeksi koko ohjelmistokehitysprosessista saadakseni paljon selvää, mistä hän todella puhui, mutta nautin hänen kirjoitustyylistään ja nautin hänen sanomisistaan.
Itse asiassa olin niin fani, että valmistuttuani ostin hänen kirjojaan (jotka olivat hänen sivustonsa artikkelikokoelmia) ja luin ne kannesta kanteen. Pidin niiden kopioita pöydälläni töissä ja käytin yhtä hänen kirjaansa – Smart and Gets Things Done – ollessani ryhmän johtaja.
Eniten mieleeni jäivät artikkelit, jotka koskivat paremman koodin kirjoittamista. Asia on kuitenkin tässä: Nämä artikkelit eivät sisältäneet mitään koodin kirjoittamisesta.
Paremman koodin kirjoittaminen
Sen sijaan kyse oli paremman koodin prosesseista. Ja törmäsin artikkeliin – joka oli kuitenkin 16-vuotias – ja pidän sitä edelleen yhtä ajantasaisena kuin silloin, kun löysin sen.
Paitsi nyt, huomaan itsekin miettiväni, miten se soveltuu nykyiseen kehityskeikkaani.
Joelin testi
Ensinnäkin kyseinen artikkeli on sellainen, jota huomaan lukevani vähintään kerran kuukaudessa – jos en ainakin kerran viikossa – ja kaikki pyörii sen ympärillä, mitä hän kutsuu Joel Testiksi. Siinä on kaksitoista kysymystä, joita kohdistat nykyiseen kehitystiimiisi.
- Käytätkö lähteenhallintaa?
- Pystytkö rakentamaan yhdessä vaiheessa?
- Teetkö päivittäin rakennuksia?
- Onko sinulla bugitietokanta?
- Korjaatko virheet ennen uuden koodin kirjoittamista?
- Onko sinulla ajan tasalla oleva aikataulu?
- Onko sinulla spesifikaatiota?
- Onko ohjelmoijilla hiljaiset työolosuhteet?
- Käytätkö parhaita työkaluja, joita rahalla voi ostaa?
- Onko sinulla testaajia?
- Kirjoittavatko uudet hakijat koodia haastattelunsa aikana?
- Teetkö käytävän käytettävyystestausta?
Koska nämä kysymykset on kirjoitettu 16 vuotta sitten ja ne perustuvat suurelta osin käännettyyn koodiin, osaa terminologiasta saattaa olla tarpeen muuttaa.
Joel Testin hieno asia on, että jokaiseen kysymykseen on helppo saada nopeasti kyllä tai ei . Sinun ei tarvitse selvittää koodirivejä päivässä tai keskimääräisiä virheitä käännekohtaa kohti. Anna joukkueellesi 1 piste jokaisesta "kyllä"-vastauksesta.
Esimerkiksi sen sijaan, että kysyisimme, voitko tehdä rakentamisesta yksivaiheisen, meidän pitäisi ehkä kysyä, voimmeko toteuttaa käyttöönoton yhdessä vaiheessa. Tiedät mitä tarkoitan – säätöjen tekemistä sellaisiin asioihin.
Toiseksi, osa kysymyksistä on mukautettava etäryhmille, koska emme ole enää samassa toimistossa. Toisin sanoen käytävän käytettävyyden testaamisen sijaan saatat joutua nappaamaan jonkun tuttusi verkossa, lähettämään hänet testausympäristöösi ja kysymään häneltä projektista.
Joelin testi WordPressille
Ehkä niille meistä, jotka käyttävät WordPressiä kehityksen perustana, kysymyksemme näyttäisivät suunnilleen tältä:
- Käytätkö lähteenhallintaa?
- Voitko toteuttaa käyttöönoton yhdessä vaiheessa?
- Teetkö päivittäisiä käyttöönottoja?
- Onko sinulla bugitietokanta?
- Korjaatko virheet ennen uuden koodin kirjoittamista?
- Onko sinulla ajan tasalla oleva aikataulu?
- Onko sinulla vaatimuksia ja malleja?
- Onko ohjelmoijilla hiljaiset työolosuhteet? Vai voivatko ohjelmoijat siirtyä "Älä häiritse" -tilaan, jos ne ovat etäkäytössä?
- Käytätkö markkinoiden parhaita työkaluja, joko jotain ilmaista ja avoimen lähdekoodin tai jotain premium-työkalua?
- Onko sinulla testaajia? (Ja voisin kysyä, riittääkö projektin budjetti myös automaattisen testauksen yksikkötestien kirjoittamiseen)?
- Onko hakijoilla saatavilla koodinäytteitä GitHubista, blogista tai julkisesti saatavilla olevasta sijainnista, joka voidaan tarkistaa?
- Onko sinulla joukko ihmisiä, joista voit testata keskeneräistä työtäsi?
Tämä taas perustuu suurelta osin ajatukseen pienestä etätiimistä pikemminkin kuin suuresta yritystason tuoteyrityksestä tai toimistosta. Mutta se on asia, johon palaan yhä silloin tällöin ja ihmettelen, kuinka muut kaupat pinoavat toisiaan vastaan.
Ja koko pisteytysjuttu?
Pistemäärä 12 on täydellinen, 11 on siedettävä, mutta 10 tai vähemmän ja sinulla on vakavia ongelmia. Totuus on, että useimmat ohjelmistoorganisaatiot toimivat pisteillä 2 tai 3, ja ne tarvitsevat vakavaa apua…
Meillä kaikilla on jotain, mihin tähdätä, eikö niin?
Seuraavalle vuosikymmenelle?
Kyse ei ole niinkään siitä, että luulen sen olevan kilpailu, mutta tiedän, että haluaisin vastata kyllä useimpiin näihin kysymyksiin itselleni ja niille, joiden kanssa työskentelen.
Mutta tämän artikkelin kirjoittamishetkellä voin sanoa, että en voi sanoa kyllä kaikille näistä, saati ehkä puolesta niistä. Ehkä vuoden loppuun mennessä voin kuitenkin.
Ja ehkä me muut alalla työskentelevät voimme arvioida tiimejämme näiden kysymysten perusteella. Vaikka Internet ja siihen liittyvät teknologiat kehittyvät nopeasti, nämä kysymykset ovat pysyneet hyvin esillä yli vuosikymmenen ajan.