Avaa repositorio kuusi kuukautta ominaisuuden julkaisun jälkeen, ja voit päätellä siitä paljon. Voit seurata arkkitehtuuria, tarkastella skeemaa, lukea testit ja nähdä tarkalleen, mitkä rivit muuttuivat.
Se, mitä et yleensä pysty jälkikäteen rekonstruoimaan, on keskustelu, joka teki noista riveistä tarpeellisia.
Koodi ei kerro sinulle, että validointisääntö on olemassa siksi, että yksi asiakas lähettää virheellisiä vientitiedostoja. Se ei selitä, että outo uudelleenyrityskäytäntö estää kaksoistapahtumat alavirran järjestelmässä. Se ei näytä, että selkeämpi käyttöliittymä hylättiin saavutettavuustestin jälkeen, tai että palveluraja heijastaa sopimuksellista rajoitetta eikä teknistä mieltymystä.
Git on erinomainen koodihistorian säilyttämisessä. Tarkoituksen se säilyttää vain silloin, kun tiimi kirjaa sen tietoisesti ylös ja pitää sen yhteydessä toteutukseen.
Tämä kuilu on aina ollut osa ohjelmistotekniikkaa. Tekoälypohjaiset koodaustyökalut tekevät siitä näkyvämmän. Järjestelmä voi lukea jokaisen tiedoston repositoriossa, seurata jokaista symbolia ja tuottaa teknisesti vakuuttavan patchin, mutta silti ratkaista väärän ongelman.
Ongelma ei ole se, että koodi johtaisi harhaan. Koodi vastaa vain kapeampaan kysymykseen.
Viisi ohjelmistotyön totuuden kerrosta
Useimmat merkitykselliset ohjelmistomuutokset nojaavat viiteen erilaiseen todistusaineiston kerrokseen.
- Tarkoitus — Mitä lopputulosta käyttäjä, asiakas tai liiketoiminta pyytää? Tämä voi löytyä määrittelystä, tiketistä, tukikeskustelusta tai kokousmuistiosta.
- Rajoitteet — Mikä ei saa rikkoutua? Yhteensopivuuslupaukset, tietoturvarajat, sääntely, sopimukset, budjetit ja määräajat sijaitsevat usein repositorion ulkopuolella.
- Toteutus — Miten järjestelmä toimii tänään? Koodi, testit, skeemat, riippuvuudet ja käyttöönoton konfiguraatio muodostavat tämän kerroksen.
- Ajonaikainen näyttö — Mitä oikeassa järjestelmässä tapahtuu? Lokit, jäljet, metriikat, tuotantodata ja häiriöraportit voivat olla ristiriidassa sellaisten oletusten kanssa, jotka näyttävät koodissa järkeviltä.
- Päätöshistoria — Miksi nykyinen lähestymistapa valittiin? Pull requestit, suunnittelukeskustelut, hylätyt vaihtoehdot ja aiemmat häiriöt sisältävät vastauksen.
Repositorio on vahvimmillaan kolmannessa kerroksessa. Se sisältää osia muistakin, mutta harvoin riittävästi edustaakseen niitä kokonaan.
Tällä on merkitystä, koska ohjelmistovirheet ilmestyvät usein kerrosten rajapinnoissa. Toteutus vastaa vanhentunutta määrittelyä. Korjaus täyttää tiketin vaatimukset mutta rikkoo operatiivisen rajoitteen. Testit menevät läpi, koska ne koodaavat eilisen oletuksia. Koodi on sisäisesti johdonmukaista samalla kun tuotantodata noudattaa mallia, jota kukaan ei dokumentoinut.
Paikallisesti oikea patchi voi silti olla väärä muutos.
Mitä repositorio ei yksin pysty kertomaan
Ajatellaan käyttäjää, joka muokkaa dokumenttia ja hakee sitten päivitettyä lausetta, mutta näkee hakutuloksissa vain vanhan version. ”Laita haku päivittymään heti” kuulostaa selkeältä pyynnöltä. Repositorio paljastaa useita mahdollisia aloituskohtia, mutta se ei yksin pysty määrittämään oikeaa korjausta.
| Kysymys | Todennäköinen lähde |
|---|---|
| Mikä dokumentin versio on ensisijainen? | Lähdedokumentti ja versiohistoria |
| Missä vanha teksti yhä on? | Synkronointilokit, poiminnan tulos, hakuindeksi tai välimuisti |
| Mitä ”heti” tarkoittaa tässä tuotteessa? | Tuotelupaus tai palvelutavoite |
| Muuttuivatko dokumentin käyttöoikeudet sen sisällön mukana? | Lähteen käyttöoikeudet ja auditointihistoria |
| Rajoittuuko vanhentunut tulos yhteen käyttäjään, lähteeseen tai alueeseen? | Pyyntöjäljet ja tuotannon metriikat |
Hakukoodi saattaa selittää, miten tulokset palautetaan. Se ei voi kertoa, onko todellinen vika synkronoinnin viive, vanhentunut poiminta, välimuistin invalidointi, käyttöoikeuksien propagointi vai odotus, jota tuotteessa ei koskaan määritelty.
Tämä ero korostuu entisestään kypsissä järjestelmissä. Kenttä, joka näyttää vanhentuneelta, saattaa silti tukea legacy-asiakasta. Duplikaatilta vaikuttava palvelu saattaa erottaa dataa, jolla on erilaiset käyttöoikeusvaatimukset. Näennäisen ylimitoitettu tarkistus saattaa olla ainoa kooditason jälki tuotantohäiriöstä, jota nykyinen tiimi ei koskaan nähnyt.
Monimutkaisuuden poistaminen on arvokasta. Monimutkaisuudeksi naamioituneen historian poistaminen on kallista.
Enemmän kontekstia voi silti johtaa väärään vastaukseen
Ilmeinen ratkaisu on antaa tekoälylle enemmän aineistoa: koko repositorio, jokainen tiketti, jokainen dokumentti, jokainen viesti ja jokainen loki.
Se luo pääsyn, ei ymmärrystä.
Lähteet voivat olla vanhentuneita, ristiriitaisia, spekulatiivisia tai eri yleisöille kirjoitettuja. Ideointisession ei pitäisi mennä hyväksytyn määrittelyn edelle. Kuusi kuukautta vanhan vaatimuksen ei pitäisi hiljaisesti kumota eilistä tuotepäätöstä. Tuotantoloki pitäisi sitoa siihen julkaisuun, ympäristöön ja koodipolkuun, joka sen tuotti. Asiakkaan pyyntöä ei pitäisi käsitellä yleispätevänä vaatimuksena tarkistamatta sen soveltamisalaa.
Siksi vakavasti otettava kontekstijärjestelmä tarvitsee muutakin kuin tiedonhakua. Sen täytyy pystyä päättelemään seuraavista asioista:
- Auktoriteetti: Mikä lähde saa määrittää vaatimuksen?
- Ajantasaisuus: Mikä tieto on voimassa nyt, ja mikä on korvattu?
- Alkuperä: Mistä kukin väite, rajoite tai johtopäätös on peräisin?
- Suhteet: Mitkä ongelmat, julkaisut, asiakkaat, datasetit ja koodipolut kuuluvat yhteen?
- Käyttöoikeudet: Mitä lähteitä tässä tehtävässä saa käyttää ja näyttää tälle henkilölle?
Konteksti ei ole kasa tokeneita. Se on graafi, jossa on aikaa, auktoriteettia ja rajoja.
Enemmän kontekstia pitäisi tuottaa enemmän näyttöä, ei enemmän varmuutta ilman näyttöä.
Työn todellinen yksikkö on muutos
Editorit ja koodaustyökalut on järjestetty tiedostojen ympärille, koska tiedostot ovat se, mitä muokkaamme. Kehitystiimit on järjestetty muutosten ympärille.
Muutos alkaa syystä. Siitä tulee vaatimus, se koskettaa koodia ja dataa, kulkee katselmoinnin läpi, päätyy tuotantoon ja synnyttää uutta näyttöä. Jos nämä vaiheet jäävät irrallisiksi, jokainen tuleva tehtävä alkaa uudella arkeologisella kierroksella.
Todellisen ohjelmiston parissa työskentelevän tekoälyjärjestelmän pitäisi seurata tätä elinkaarta.
Ennen toteutusta sen pitäisi tunnistaa pyyntö, olennaiset rajoitteet ja mahdolliset ristiriitaiset lähteet. Sen pitäisi tietää, korjaako se vikaa, muuttaako odotettua käyttäytymistä vai tuoko käyttöön uuden sopimuksen.
Toteutuksen aikana sen pitäisi kytkeä jokainen merkityksellinen valinta näyttöön. Miksi tämä moduuli? Miksi tämä migraatiostrategia? Miksi tämä haara säilytetään? Selityksen pitäisi säilyä pidempään kuin sen keskustelun, jossa koodi tuotettiin.
Toteutuksen jälkeen sen pitäisi liittää muutokseen varmennustulokset, katselmointipäätökset ja uudet havaitut rajoitteet. Muuten seuraava henkilö — tai seuraava AI-istunto — joutuu selvittämään ne uudelleen.
Tässä on ero työkalun, joka voi muokata repositoriota, ja järjestelmän, joka voi osallistua insinöörityöhön, välillä.
AI:n pitäisi vähentää uudelleenrakentamisen tarvetta, ei poistaa harkintaa
Parempi konteksti esitetään joskus polkuna autonomiseen ohjelmistokehitykseen. Välitön arvo on vähemmän dramaattinen ja hyödyllisempi: ennen muutoksen tekemistä tarvittavan todellisuuden uudelleenrakentamisen kustannusten pienentäminen.
AI voi tuoda alkuperäisen vaatimuksen relevantin koodin viereen. Se voi nostaa esiin poikkeaman, joka selittää epätavallisen suojauksen. Se voi yhdistää epäonnistuvan mittarin julkaisuun, joka muutti sitä. Se voi näyttää jo ennen toteutuksen alkamista, että kaksi auktoritatiivista lähdettä ovat eri mieltä.
Nämä kyvykkyydet eivät poista insinööriharkintaa. Ne tekevät harkinnasta paremmin perusteltua.
Ihmisen on silti päätettävä, mikä kompromissi on hyväksyttävä, onko vaatimus täydellinen ja kuinka paljon riskiä julkaisu voi kantaa. Järjestelmän pitäisi tehdä evidenssi näkyväksi ja päättely tarkasteltavaksi. Sen ei pitäisi piilottaa epävarmuutta viimeistellyn patchin taakse.
Mittapuu ei ole ”osaako se generoida koodia?”
Mittapuu on ”osaako se selittää, miksi tämä on oikea muutos juuri nyt?”
Repositoriotietoisuudesta työymmärrykseen
Koodausavustajista tuli ensin hyödyllisiä ymmärtämällä kehittäjän edessä olevan tiedoston. Repositoriotietoisuus oli seuraava merkittävä askel: siihen kuului liittyvän koodin löytäminen, symbolien seuraaminen ja muutosten tekeminen koko projektin laajuudella.
Seuraava askel on tietoisuus repositorion ympärillä olevasta työstä.
Se tarkoittaa koodin yhdistämistä sitä pyytäneeseen määrittelyyn, sitä täsmentäneeseen keskusteluun, sitä haastaneeseen tuotantoevidenssiin ja päätökseen, joka pitäisi muistaa myöhemmin. Se tarkoittaa myös sellaisen kontekstin sulkemista pois, joka on epäolennaista, vanhentunutta tai käyttäjän käyttöoikeuksien ulkopuolella.
Dvinaa rakentaessamme tämä on yksi niistä ajatuksista, joihin palaamme jatkuvasti. Työ ei tapahdu yhden tiedoston, sovelluksen tai keskustelun sisällä. Merkitys elää niiden välisissä yhteyksissä ja siinä, miten nuo yhteydet muuttuvat ajan myötä.
Repositorio on edelleen olennainen. Se on järjestelmän toiminnan suoritettava ensisijainen totuuden lähde. Se ei vain ole täydellinen totuuden lähde tuotteen tarkoitukselle, operatiiviselle todellisuudelle tai organisaation muistille.
Koko tarina muuttaa sitä, mitä rakennetaan
Kun käytössä on vain koodi, luonteva kysymys on:
Mikä muutos sopii tähän järjestelmään?
Laajemman kontekstin myötä kysymys muuttuu muotoon:
Mikä muutos sopii tähän järjestelmään, tähän vaatimukseen, tähän historiaan ja tähän hetkeen?
Tuo toinen kysymys paljastaa rajoitteet ennen kuin niistä tulee regressioita. Se antaa arvioijille toteutuksen taustalla olevan perustelun. Se auttaa uusia tiimin jäseniä ymmärtämään, miksi järjestelmä on sellainen kuin on. Se antaa tekoälylle perustellun roolin: ei editorin sisällä olevana oraakkelina, vaan osallistujana, joka voi koota näyttöä työn eri puolilta.
Reposi ei koskaan kertonut koko tarinaa.
Mahdollisuus on rakentaa järjestelmiä, jotka pystyvät lukemaan myös lopun siitä — ja näyttämään työnsä.
