Onko "siisti koodi" aina vaivan arvoista, vai riittääkö "riittävän hyvä" joskus?

Question

Accepted Answer

**Se riippuu koodin elinkaarta ja vaikutusalueesta.** Siisti koodi tuottaa paljon hyötyä koodille, joka elää ja muuttuu; "riittävän hyvä" on oikea valinta kertakäyttöiselle, prototyyppi- tai harvoin muutettavalle koodille. Taito on sovittaa panostuksesi tilanteeseen — välttäen sekä huolimattomuutta että kullan paneeraamista.

## Periaate: sovita ponnistus koodin elinkaaren mukaan

Koodin laatu on **investointi**, ja kuten minkä tahansa investoinnin, sen tuotto riippuu ajasta ja altistuksesta. Kaksi kysymystä, joita pitää kysyä:

- **Kuinka kauan tämä koodi elää?** Koodi, jota luetaan ja muutetaan vuosia, ansaitsee selkeyttä; kertakäyttö-skripti ei.
- **Mikä on vaikutusalue?** Keskeiset moduulit, joita moni käyttää ja joista kriittiset polut riippuvat, ansaitsevat huolellisen käsittelyn; eristetyt kulmat, jotka harvoin muuttuvat, eivät.

## Milloin siisti koodi voittaa selvästi

- Koodi, joka **muuttuu usein** — selkeys maksetaan takaisin joka kerta, kun joku lukee tai muokkaa sitä.
- **Jaettu, keskeiset tai pitkäikäinen** koodi — sekaannuksen hinta moninkertaistuu ihmisten ja ajan myötä.
- Kaikki, missä **bugi on kallis** — maksut, tunnistautuminen, tietojen eheys.

## Milloin "riittävän hyvä" on oikea valinta

- **Kertakäyttö koodi** — spike-kokeilut, eksperimentikoodi, kertakäyttö migraatiot, skripti, jonka poistat huomenna.
- **Prototyypit**, joiden tarkoitus on validoida idea, ei säilyä.
- **Harvoin muuttuva, matalan riskin** koodi, missä viimeistelyä ei juurikaan hyödy.

## Kaksi epäonnistumisen tapaa

| Epäonnistuminen | Näyttää siltä | Hinta |
|---|---|---|
| **Huolimattomuus** | sotkuisen koodin toimittaminen, joka tulee elämään | hitaat tulevat muutokset, bugit, rapistuminen |
| **Kullan paneeraaminen** | koodin liian monimutkaistaminen, jolla ei ole merkitystä | hukattu aika, ennenaikainen abstrahointi |

Molemmat ovat oikeaa hukkaa. "Riittävän hyvä" on *harkittu, kontekstuaalinen* valinta — ei tekosyy huolimattomuudelle ja ei lupa kiillottaa ikuisesti.

## Miksi se on tärkeää

Tämä kysymys erottaa insinöörit, jotka soveltavat laatua **dogmaattisesti** niistä, jotka soveltavat sitä **taloudellisesti**. Siivouskoodin kohteleminen uskonnoksi tuhlaa ponnistusta kertakäyttö-koodiin; sen kohteleminen valinnaisena rappaa järjestelmät, joihin luotat. Vanhemman asteen arviointi on tietää *minkä tyyppistä koodia pidät käsissäsi* ja investoida vastaavasti — ja kyky selittää tämä kompromissi on juuri se pragmaattinen ajattelu, jota tiimit haluavat nähdä.

Epäonnistuminen	Näyttää siltä	Hinta
Huolimattomuus	sotkuisen koodin toimittaminen, joka tulee elämään	hitaat tulevat muutokset, bugit, rapistuminen
Kullan paneeraaminen	koodin liian monimutkaistaminen, jolla ei ole merkitystä	hukattu aika, ennenaikainen abstrahointi