Näin verkkokehitys etenee käytännössä
Ulkopuolelta kehitys näyttää mustalta laatikolta: hyväksyt ulkoasun, odotat pari viikkoa, sivusto ilmestyy. Sen ymmärtäminen mitä sisällä tapahtuu auttaa esittämään oikeat kysymykset ja tunnistamaan varoitusmerkit ajoissa.
Tämä opas selittää käytännön kulun tilaajalle eikä ohjelmoijalle.
Ympäristöt: missä työ tapahtuu#
Vakavassa projektissa on vähintään kaksi ympäristöä, usein kolme. Jos on vain yksi, se on jo itsessään merkki.
| Ympäristö | Mihin käytetään | Kenellä on pääsy |
|---|---|---|
| Paikallinen | Ohjelmoijan oma kone | Tiimi |
| Testi | Jaettu versio katselmointiin | Tiimi ja asiakas |
| Esituotanto | Tuotannon kanssa identtinen kopio | Tiimi, ennen käyttöönottoa |
| Tuotanto | Julkinen sivusto | Kaikki |
Suoraan tuotantoon tehdyt muutokset ovat yleisin odottamattomien vikojen lähde. Jos sinulle kerrotaan ettei testiympäristöä ole, kysy miksi.
Työsykli#
Useimmat tiimit työskentelevät lyhyissä sykleissä, joiden lopussa on jotain katselmoitavaa.
- Työ jaetaan pieniin tehtäviin, joilla kullakin on todennettava tulos.
- Kukin tehtävä kehitetään erikseen, versionhallinnan kanssa.
- Joku toinen katselmoi koodin ennen yhdistämistä, kun tiimi on riittävän suuri.
- Tulos menee testiympäristöön, jossa se on nähtävissä.
- Sinä katselmoit ja annat konkreettista palautetta, osoitteen ja kuvakaappauksen kanssa.
- Korjaukset menevät seuraavaan sykliin, ellei ne estä työtä.
- Viikon tai kahden välein on versio katselmoitavaksi, ei vasta lopussa.
Projekti jossa näet tuloksen vasta lopussa, on riskiprojekti. Pyydä pääsy testiympäristöön ensimmäisestä viikosta alkaen.
Testaus ennen käyttöönottoa#
Mitä pitäisi olla tarkistettuna ennen jokaista käyttöönottoa, projektin koosta riippumatta.
- Toiminnallisuus: jokainen lomake, jokainen polku, jokainen painike joka tekee jotain.
- Selaimet: ne joita kävijäsi oikeasti käyttävät analytiikan mukaan.
- Laitteet: oikeat puhelimet, mukaan lukien vanha ja hidas.
- Suorituskyky: mitattuna, ei arvioituna, päämallipohjilla.
- Saavutettavuus: näppäimistö, kontrasti, nimikkeet, otsikkorakenne.
- Sisältö: ei paikkamerkkitekstiä, ei linkkejä testiverkkotunnukseen.
- Regressio: se mikä toimi, toimii yhä.
- Tietoturva: syötteiden validointi, oikeudet, HTTPS.
Käyttöönotto ja peruutus#
Käyttöönoton pitää olla rutiinia ja tylsää. Kun se on jännittynyt tapahtuma, se on merkki hauraasta prosessista.
| Käytäntö | Miksi sillä on väliä |
|---|---|
| Automatisoitu käyttöönotto | Poistaa unohtuneet manuaaliset vaiheet |
| Peruutus minuuteissa | Muuttaa vakavan virheen pieneksi häiriöksi |
| Varmuuskopio ennen käyttöönottoa | Turvaverkko tietokannalle |
| Versioidut tietomigraatiot | Toistettavat tietokantamuutokset |
| Todennus käyttöönoton jälkeen | Nappaa sen mikä pettää vain tuotannossa |
| Ota käyttöön rauhallisena hetkenä | Vähemmän kärsiviä käyttäjiä, enemmän huomiota |
| Loki käyttöönotoista | Mahdollistaa ongelmien yhdistämisen muutoksiin |
Kysy kauanko peruutus kestää. Jos vastaus on «riippuu» tai «ei ole koskaan tarvinnut», peruutussuunnitelmaa ei ole.
Usein kysytyt kysymykset
Kuinka usein minun pitäisi nähdä edistystä?
Viikon tai kahden välein, jotain näkyvää testiympäristössä. Pidemmät syklit lisäävät riskiä huomata väärinkäsitys myöhään. Hyvin lyhyillä sykleillä jatkuvan palautteen kanssa on myös hintansa, koska keskeytetty työ on tehotonta. Kahden viikon tahti toimii hyvin useimmissa projekteissa.
Mitä teen jos projekti myöhästyy?
Selvitä ensin syy: puuttuva sisältö, laajentunut laajuus vai optimistinen arvio. Nämä kolme ratkeavat eri tavoin, ja ensimmäinen on usein asiakkaan puolella. Valitse sitten laajuuden karsimisen ja päivämäärän siirtämisen välillä — ihmisten lisääminen kesken myöhästyneen projektin yleensä myöhästyttää sitä lisää.
Pitääkö osata koodata johtaakseen tätä?
Ei. Pitää tietää mitä kysyä: onko testiympäristöä, miten käyttöönotto tehdään, kauanko peruutus kestää, mitä on testattu, kenellä on pääsy koodiin. Vastaukset kertovat paljon prosessin vankkuudesta lukematta riviäkään koodia.
Mitä on versionhallinta ja miksi sillä on väliä?
Se on järjestelmä — lähes aina Git — joka säilyttää kaikkien koodimuutosten historian ja mahdollistaa paluun taaksepäin. Sillä on väliä kolmesta syystä: se mahdollistaa virheen peruuttamisen, sen ansiosta useampi voi työskennellä rinnakkain, ja se on todiste siitä että koodi on sinun ja siirrettävissä. Projekti ilman versionhallintaa on projekti ilman historiaa.
miten verkkokehitys eteneetestiympäristöversionhallintasivuston käyttöönottokehitysprosessiverkkoprojektin johtaminen
