Greenfield vs. Brownfield
Moduulissa 1 opit rakentamaan uutta nollasta (greenfield). Todellisuudessa 80 % yritystyöstä on brownfield — olemassa olevien järjestelmien muokkaamista. Tämä oppitunti käsittelee, miksi brownfield-kehitys vaatii radikaalisti erilaista lähestymistapaa.
Strateginen muutos
Brownfield-kehitys
Brownfield-kehitys tarkoittaa olemassa olevan, usein tuotannossa olevan koodikannan kehittämistä. Toisin kuin greenfield-kehityksessä, et voi tehdä vapaita arkkitehtuuripäätöksiä — sinun on ymmärrettävä nykyinen järjestelmä, sen rajoitteet ja riippuvuudet ennen muutoksia.
| Aspekti | Greenfield | Brownfield |
|---|---|---|
| Konteksti | Sinä määrittelet | Sinun pitää selvittää |
| Arkkitehtuuri | Suunnittele AI:lle | Sopeudu olemassa olevaan |
| Riski | Matala (uusi alusta) | Korkea (muutokset voivat rikkoa) |
| AI:n vahvuus | Koodin generointi | Ymmärtäminen ensin, sitten muutokset |
| Dokumentaatio | Syntyy rakentaessa | Luotava jälkikäteen |
Vibe coding vs. kurinalaisuus
Kriittinen oivallus: Vibe-koodaus 100 000+ rivin koodikantaan on vaarallista. Sinun PITÄÄ ymmärtää ennen kuin muutat.
| Aspekti | Vibe coding | Kurinalainen kehitys |
|---|---|---|
| Nopeus | Nopea aloitus | Hitaampi aloitus, nopeampi lopetus |
| Suunnittelu | Minimaalinen | Perusteellinen |
| Dokumentaatio | Ei mitään | 3-tasoinen, navigoitava |
| Ylläpidettävyys | Heikko | Korkea |
| Paras kohde | Prototyypit | Tuotanto, brownfield |
Pro-vinkki
Brownfield-projekteissa suurin virhe on hypätä suoraan koodaamaan. Käytä 30 % ajasta ymmärtämiseen ja dokumentointiin — se nopeuttaa toteutusta ja vähentää regressioita merkittävästi.
Brownfield-riskit
1. Ripple effects (ketjureaktiot)
Yksi muutos voi vaikuttaa kymmeniin tiedostoihin. Ilman kokonaisymmärrystä voit rikkoa ominaisuuksia joita et edes tiennyt olevan olemassa.
2. Implisiittiset sopimukset
Koodissa on usein dokumentoimattomia oletuksia: "tämä funktio palauttaa aina listan", "tämä kenttä ei koskaan ole null". AI ei tiedä näitä ellei ne ole dokumentoitu.
3. Vanhat riippuvuudet
Legacy-koodi käyttää usein vanhoja kirjastoversioita tai poistumassa olevia API:ja. AI voi ehdottaa moderneja ratkaisuja jotka eivät ole yhteensopivia.
4. Testikattavuuden aukot
Vanhoissa projekteissa testikattavuus on usein epätasainen. Muutos testaamattomaan osaan ei anna varoitusta.
## Ennen kuin muutat mitään
1. [ ] Ymmärrän muutettavan moduulin arkkitehtuurin
2. [ ] Tiedän mitkä muut moduulit riippuvat tästä
3. [ ] Olen lukenut olemassa olevat testit
4. [ ] Olen dokumentoinut nykyisen käyttäytymisen
5. [ ] Olen kirjoittanut speksin muutokselle
6. [ ] Olen arvioinut riskit
7. [ ] Minulla on rollback-suunnitelmaAI:n rooli brownfieldissä
AI on erityisen hyödyllinen brownfield-kehityksessä näissä tehtävissä:
- Koodikannan tutkiminen — "Selitä miten tämä moduuli toimii"
- Riippuvuuksien kartoitus — "Mitkä tiedostot käyttävät tätä funktiota?"
- Dokumentaation generointi — Luo 3-tasoinen dokumentaatio olemassa olevasta koodista
- Testien täydentäminen — Kirjoita testit olemassa olevalle koodille
- Turvallinen refaktorointi — Muokkaa testien suojassa
Miksi vibe-koodaus on riskialtista brownfield-projektissa?
Kartoita oma brownfield-projektisi
Valitse olemassa oleva projekti (oma tai avoimen lähdekoodin). 1) Tunnista 3 riskialuetta joissa muutos voisi aiheuttaa yllätyksiä, 2) Kirjoita kullekin alueelle: mikä voisi rikkoutua, miksi, ja miten verifioida, 3) Arvioi testikattavuus kyseisillä alueilla.
Yhteenveto
- 80 % työkuormasta on brownfield — olemassa olevan koodin muokkaamista
- Brownfield vaatii ymmärtämistä ennen muuttamista
- Vibe-koodaus on riskialtista suurissa koodikannoissa
- AI auttaa erityisesti koodikannan tutkimisessa ja dokumentoinnissa
- Seuraavaksi opimme 4-vaiheisen prosessin: Document → Spec → Develop → Audit