Većina proizvoda ne propada zato što je prvu verziju bilo tehnički nemoguće izraditi. Propadaju zato što prva verzija neprimjetno postane zatvor: svaka nova potreba korisnika zahtijeva rizičnu iznimku, svaka odluka tima ovisi o sjećanju jedne osobe, a svako izdanje pretvara se u pregovaranje s prošlošću.

Projektiranje za potrebe koje se mijenjaju ne znači predviđanje svake buduće značajke. Riječ je o očuvanju korisnih mogućnosti. Trajan proizvod svom timu ostavlja prostor za učenje, promjenu smjera i poboljšanje iskustva bez stalne ponovne izgradnje temelja.

Počnite s promjenom, a ne s komponentama

Tehnički timovi često započinju arhitektonske rasprave navođenjem tehnologija, servisa i okvira. Ti su izbori važni, ali važnije je pitanje jednostavnije: što će se vjerojatno promijeniti?

Neke je promjene lako predvidjeti. Pravila određivanja cijena mogu se razlikovati po korisniku. Tijek rada može dobiti korake odobravanja. Proizvodu koji počinje na jednom tržištu možda će trebati novi jezici, valute ili pravila usklađenosti. Druge se promjene ne mogu unaprijed znati, ali može se znati njihova kategorija: ponašanje korisnika otkrit će pogrešne pretpostavke.

Dobra arhitektura razdvaja dijelove koji se mijenjaju iz različitih razloga. To ne znači stvaranje servisa za svaku imenicu u dokumentu za planiranje. Znači izbjegavanje sustava u kojem mala prilagodba pravila zahtijeva izmjene korisničkog sučelja, upita baze podataka, pozadinskih poslova i integracijskog koda.

Na primjer, razmotrite pretplatnički proizvod koji u početku nudi mjesečne planove. Ako su uvjeti ispunjavanja uvjeta za plan, obračunska razdoblja i pristup značajkama raspršeni po kontrolerima i uvjetima u prednjem dijelu aplikacije, dodavanje godišnje naplate bit će skupo. Ako se ta pravila nalaze iza jasne granice domene pretplata, novi plan i dalje zahtijeva rad, ali ne zahtijeva potragu po cijelom proizvodu.

Odaberite najjednostavniju strukturu koja zadržava reverzibilnost odluka

U ranom životu proizvoda jednostavnost je prednost pri isporuci. Dobro organiziran monolit često je lakše razumjeti, testirati, postaviti i održavati nego distribuirani sustav. Prerano razdvajanje može složenost jedne baze koda zamijeniti mrežnim kvarovima, dupliciranim podacima, koordinacijom postavljanja i nejasnim vlasništvom.

Cilj nije maksimalna modularnost prvog dana. Cilj je struktura koja može postati modularnija kada to dokazi opravdaju.

• Neka granice budu vidljive. Grupirajte kôd prema poslovnim sposobnostima, a ne samo prema tehničkim slojevima.
• Izložite eksplicitna sučelja. Neka pozivatelji ovise o operaciji ili ugovoru, a ne o tablicama i internim prečacima drugog modula.
• Zaštitite vlasništvo nad podacima. Zajednička baza podataka može biti praktična, ali neograničeno pisanje između modula stvara skriveno povezivanje.
• Zabilježite važne odluke. Kratak zapis arhitektonske odluke objašnjava zašto ograničenje postoji i kada ga treba ponovno razmotriti.

Reverzibilnost je osobito vrijedna kada tim nije siguran. Odluka nije slaba zato što se može promijeniti; snažna je kada je njezin trošak promjene razumljiv i namjerno se njime upravlja.

Izgradite spojeve oko neizvjesnosti

Spoj je mjesto na kojem se jedna odgovornost može zamijeniti ili promijeniti bez ometanja ostatka sustava. Korisni spojevi nisu apstraktan ukras. Pojavljuju se ondje gdje neizvjesnost ima stvaran trošak.

Vanjski pružatelji usluga poznat su primjer. Plaćanja, dostava e-pošte, identitet, pretraživanje i generiranje dokumenata mogu se promijeniti zbog potreba proizvoda, cijena, pouzdanosti ili regionalnih zahtjeva. Aplikacija se ne bi trebala pretvarati da ti pružatelji ne postoje, ali ponašanje specifično za pružatelja treba zadržati uz adapter, umjesto dopustiti da se proširi posvuda.

Poslovna pravila zaslužuju jednaku pažnju. Ako je pravilo dovoljno važno da utječe na ishode korisnika, dodijelite mu jasno mjesto i izravno ga testirajte. Izbjegavajte ga zakopati u filtar baze podataka, uvjet predloška ili usputnu logiku pozadinskog radnika.

Učinite konfiguraciju pitanjem proizvoda

Konfiguracija se često smatra operativnom naknadnom mišlju. U stvarnosti je jedan od najčešćih načina na koji se proizvod razvija. Dostupnost značajki, ograničenja, uvjeti uvođenja i ponašanje specifično za korisnika trebaju kontroliranu promjenu.

Upotrebljavajte konfiguraciju za vrijednosti i odabire pravila za koje se očekuje da će varirati. Nemojte je upotrebljavati kao zamjenu za koherentan model. Rastuća zbirka labavo imenovanih zastavica može postati drugi, nedokumentirani programski jezik.

Za svaku značajnu postavku definirajte tko je njezin vlasnik, gdje se provjerava valjanost, koja je njezina sigurna zadana vrijednost i kako se ukida. Zastavica značajke trebala bi imati predviđenu točku uklanjanja. U protivnom privremena logika uvođenja postaje trajna arhitektura.

Neka prakse isporuke oblikuju arhitekturu

Arhitektura koja se ne može sigurno isporučiti nije potpuna. Timovi uče o stvarnim potrebama kroz izdanja, razgovore s podrškom, nadzor i obrasce upotrebe. Ako su postavljanja rijetka i stresna, taj se ciklus učenja usporava.

Projektirajte promjene tako da stare i nove verzije po potrebi mogu kratko koegzistirati. Migracija baze podataka može zahtijevati dodavanje novog polja, postavljanje koda koji može čitati oba oblika, popunjavanje podataka, prebacivanje ponašanja i tek tada uklanjanje starog polja. Taj je slijed manje dramatičan od jednog destruktivnog izdanja, ali mnogo je tolerantniji.

1. Dodajte novu strukturu bez narušavanja postojećih čitanja.
2. Postavite kôd kompatibilan sa starim i novim podacima.
3. Migrirajte ili dopunite podatke u vidljivim skupinama.
4. Omogućite novo ponašanje.
5. Uklonite kôd za kompatibilnost nakon dovršetka prijelaza.

Ovaj pristup također podržava udaljene timove. Jasne bilješke o izdanju, vidljiva stanja uvođenja i eksplicitni kriteriji vraćanja smanjuju ovisnost o sinkronim sastancima. Ljudi u različitim vremenskim zonama mogu pregledati iste dokaze umjesto da se oslanjaju na osobu koja je slučajno bila na mreži tijekom incidenta.

Vlasništvo je arhitektonska značajka

Svaki važan dio proizvoda treba vlasnika, ali vlasništvo nije čuvanje prolaza. Znači da je netko odgovoran za održavanje razumljivosti granice: njezinu svrhu, operativno stanje, plan razvoja i kompromise koje nosi.

Zajedničko vlasništvo najbolje funkcionira kada je konkretno. Tim bi trebao znati tko može objasniti podsustav, tko pregledava promjene visokog rizika, koje nadzorne ploče otkrivaju njegovo stanje i kako drugi inženjer može sigurno pridonijeti. Dokumentacija bi trebala odgovoriti na pitanja koja usporavaju rad: čime ovaj modul upravlja, o čemu ovisi i kako može zakazati?

Za programere je ovo karijerna vještina jednako koliko i tehnička. Snažni inženjeri ne dodaju samo značajke. Oni olakšavaju budući rad ljudima koji nisu bili prisutni pri izvornoj odluci. Lokalno znanje pretvaraju u sposobnost tima.

Smanjujte složenost s namjerom

Nije sav tehnički dug loš. Ponekad je racionalan trošak brzog učenja. Opasnost počinje kada privremeni izbori više nisu vidljivi, mjerljivi ili u nečijem vlasništvu.

Preispitujte složenost uz planove proizvoda. Kada nova inicijativa opetovano dotiče isto krhko područje, to je dokaz za ulaganje. Kada predložena apstrakcija štiti od nejasne budućnosti, pričekajte jasniji signal. Pitanje nije „je li ovaj kôd elegantan?” Nego: „pomaže li nam ova struktura da sigurno isporučimo sljedeću značajnu promjenu?”

Proizvod traje kada njegova arhitektura podržava kontinuirano prosuđivanje. Neka sustav ostane razumljiv, izolirajte neizvjesnosti koje su važne, objavljujte u malim koracima od kojih se može oporaviti i tretirajte vlasništvo kao zajedničku praksu. Budućnost će vas i dalje iznenađivati. Cilj je učiniti ta iznenađenja prilikama za učenje, a ne razlozima zbog kojih se proizvod ne može pomaknuti.