Suunnitelma, jonka ohitat, on häiriö, jonka joudut myöhemmin debuggaamaan
Jokainen ohjelmistokehityksen viitekehys kehottaa sinua etenemään nopeasti, julkaisemaan varhain ja iteroimaan tuotannossa. Tekoälyn generoimien verkkosivustojen kohdalla tämä on päinvastoin. Tämä rakentaja kieltäytyy suoratoistamasta koodia suoraan kehotteestasi — se pysähtyy, kirjoittaa suunnitelman ja odottaa, että katsot sitä — ja tämä kieltäytyminen on se yksi päätös, jonka varaan kaikki muu tässä prosessissa rakentuu. Hitaammin alussa, halvemmin kaikkialla sen jälkeen. Otan sen vaihdon aina, ja uskon, ettei suurin osa vastakkaista mieltä olevista ole oikeasti nähnyt, mitä väärä arvaus maksaa myöhemmin.
Tässä on virhetilanne, jonka estämiseksi suunnitelma on olemassa. Kirjoitat "varaussivusto studiolleni" ja painat käynnistä. Järjestelmän täytyy arvata, mitä "varaus" tarkoittaa — kalenteriwidget, kolmannen osapuolen upotus vai oikea varausjärjestelmä päällekkäisyyksien tarkistuksella — ja sen täytyy arvata ennen kuin se on kirjoittanut mitään, koska muuta järjestystä ei ole. Väärä arvaus suunnitelman sisällä korjataan yhdellä lauseella, viidessä sekunnissa, valmis. Väärä arvaus generoidun koodin sisällä ei ole enää lauseen muokkaamista — puret kymmenen tiedostoa, jotka jo nojaavat väärään oletukseen. Olen nähnyt molemmat versiot tapahtua. Suunnitteluvaiheen korjaus on yksi viestinvaihto. Sama epäselvyys generoinnin jälkeen tarkoittaa hylkäämistä ja uudelleenrakentamista.
Suunnitelma ei myöskään ole pelkkä tehtävälista, ja tämä on kohta, jonka ihmiset yleensä ohittavat. Se on sopimus, ja järjestelmä pitää itsensä siihen sitoutuneena: yhdenmukaisuutta tarkistava varmentaja, yksi agenteista, jonka on hyväksyttävä lopputulos ennen julkaisua, vertaa valmista sivustoa hyväksymääsi suunnitelmaan. Rakennettiinko jokainen suunniteltu sivu? Vastaako ominaisuuslista sitä, mitä lopulta julkaistiin? "Valmis" ei ole täällä tunneperäinen arvio — se on suhteessa kirjalliseen lupaukseen, tarkistettavissa rivi riviltä. Se on vahvempi tae kuin "koodi toimii", ja saat sen vain siksi, että vertailukohtana on olemassa dokumentti. Poista suunnitelma, ja poistat mittapuun.
Missä tämä oikeasti kannattaa
Vaikutusvaltasi rakentamisen ohjaajana painottuu alkuun, käytätpä sitä tai et. Jos välität tietoarkkitehtuurista, sivurakenteesta, siitä mitkä ominaisuudet päätyvät versioon 1 versus versioon 2 — se tarkkuus on kymmenkertaisesti arvokkaampaa suunnitelman tarkastuksessa kuin ensimmäisen generointikierroksen jälkeen. Neljä ylimääräistä minuuttia suunnitelman uudelleenlukemiseen voittaa edestakaisen matkan jo pieleen menneen rakennuksen korjaamisessa.
Selkein esimerkki on tuotetyyppi — pelkkä staattinen sivusto, asennettava sovellus, framework-rakennus tai palvelinpohjainen sovellus todellisella pysyvyydellä. Se näyttää pudotusvalikolta. Se ei ole. Se on koko prosessin rakenteellisin valinta, koska se päättää hiljaisesti tusinan asiaa, joilla ei ole mitään tekemistä sivuston ulkonäön kanssa.
| Tuotetyyppi | Esikatselu | Julkaise | Tilit / tietokanta |
|---|---|---|---|
| Pelkkä staattinen sivusto | Välitön, koska kyseessä on pelkkiä staattisia tiedostoja | Staattinen tuotos kopioituu puhtaasti | Ei mahdollista — kirjautumisen pyytäminen tarkoittaa jotain, mitä tämä tyyppi ei rakenteellisesti pysty tekemään |
| Framework-rakennus | Kääntyy ensin; rikkinäinen käännös näkyy "ei esikatselua" -tilana, ei rikkinäisenä sivuna | Sama puhdas staattisen kopioinnin polku, kääntämisen jälkeen | Ei mahdollista |
| Palvelinpohjainen sovellus | — | Tarvitsee paikan, jossa oikeasti ajaa prosessia, mikä epäonnistuu eri tavalla — kaatunut prosessi, ei puuttuva tiedosto | Ainoa tyyppi, jossa tilit ja tietokannat ylipäätään ovat olemassa |
Etkä voi huoletta päivittää tyyppiä myöhemmin. Siirtyminen pelkästä sivustosta palvelinpohjaiseen sovellukseen ei ole asetusten vaihtokytkin — se on lähes toinen rakennusprojekti, koska puolet suunnitelman oletuksista (miten sivut latautuvat, missä data sijaitsee, mitä "julkaisu" tarkoittaa) tehtiin vanhaa tyyppiä ajatellen. Sano se siis jo suunnitteluvaiheessa, vaikka olisit vain puoliksi varma: "on mahdollista, että tarvitsen tilejä." Palvelinpohjaisen sovelluksen suunnitteleminen ja pelkkien staattisten osien käyttäminen ei maksa mitään. Sen huomaaminen jälkikäteen, että sellaista olisi tarvittu, maksaa uudelleenrakentamisen.
Missä kriitikoilla on oikeutettu pointti
Mikään tästä ei ole ilmaista, enkä väitä niin. Eristetyt, ajokohtaiset työtilat tarkoittavat, että tietosi kopioidaan aina tuoreeltaan sisään, mikään ei ota yhteyttä takaisin koneellesi — hyvä sinulle, jos kannettavasi kaatuu kesken rakennuksen, huono viiveen kannalta, koska työtilan valmistelu ja, framework-rakennuksissa, oikean riippuvuusasennuksen ajaminen kontin rajojen sisällä vie oikeaa kelloaikaa. Tämä kontin raja on olemassa, koska framework-rakennus ajaa komennon `npm install` ja mielivaltaisia rakennusskriptejä — koodia, jota et ole itse kirjoittanut, ja joka suoritetaan rakennusajan oikeuksilla — ja tämän tekeminen jaetulla palvelimella ilman eristystä on yhden riippuvuussekaannushyökkäyksen päässä toisen käyttäjän datan koskettamisesta. Nopea-mutta-turvaton-vaihtoehto oli saatavilla. Se ei vain ollut vaihto, joka kannatti tehdä.
Sama juttu varmennuksen kanssa. Valmis rakennus ei poistu prosessista, kun generointi pysähtyy; se poistuu, kun joukko riippumattomia varmentajia lakkaa löytämästä jotain, minkä takia kannattaisi pysähtyä:
- Koodikatselmointi
- Tietoturva
- Linkit ja SEO
- Saavutettavuus
- Yhdenmukaisuus
- Oikea selaimessa suoritettu ajo
Tämä ei ole yksi läpikäynti, vaan merkitse-korjaa-tarkista-silmukka, joka toistuu kunnes kenelläkään ei ole enää mitään sanottavaa, koska yksittäinen linter-kierros voi jäädä huomaamatta oman korjauksensa aiheuttaman taantuman. Rikkinäisen linkin korjaaminen ja samalla sivulla otsikkohierarkian vahingossa rikkominen on juuri sellaista, minkä yksi läpikäynti jättää huomaamatta ja tarkistuskierros nappaa kiinni. Tämän silmukan rehellinen kustannus on satunnainen rakennus, joka vie ylimääräisen minuutin ihan lopussa ilman näkyvää syytä. Ihmiset huomaavat sen minuutin. He eivät huomaa niitä kuutta agenttia, jotka juuri lopettivat väittelynsä sivustostasi. Se on reilu valitus kokemuksesta — en vain usko, että se on hyvä argumentti julkaista ilman, että väittely olisi edes käyty.
