Kako održati dizajn sistem živim: vlasništvo, dug i male redovne popravke

Zašto sistemi blede

Dizajn sistemu je lako diviti se na lansiranju. Sve je novo, dokumentovano i dosledno, i svaki tim ga rado usvaja. Onda počinje pravi posao. Rok se približava, komponenta je skoro dobra, a kopiranje deluje brže od traženja izmene. Niko ne radi ništa pogrešno, a ipak se sistem malo više udaljava od proizvoda kojima je trebalo da služi.

Sama prečica nije problem; prečice su, ako ništa drugo, dokaz da ljudi isporučuju. Problem je što niko ne vidi kako se gomilaju i niko nije odgovoran da ih uskladi.

Neko mora da bude vlasnik

Sistemu treba jedan, jasno određen vlasnik, a ne komisija ili, još gore, „svi“. Vlasnik odlučuje šta ulazi u biblioteku, šta se menja, a šta ostaje napolju, i ima autoritet da kaže ne. To ne znači raditi sav posao sam. Znači da svako pitanje ima adresu i svaka odluka nosi ime.

Kada vlasništvo dele svi, u praksi ne pripada nikome, a biblioteka postepeno postaje skladište dobrih namera.

Dug je normalan, ćutanje nije

Svaki živ sistem gomila dug: prepisivanja, odvojene instance, ručno upisane vrednosti, komponente napravljene za prošlogodišnji problem. Ja to ne smatram neuspehom. Smatram to informacijom, zapisom o tome gde sistem više ne odgovara poslu. Važno je da dug bude vidljiv, zapisan na jednom mestu koje svi mogu da pogledaju, a ne da živi u nečijem sećanju.

Male popravke, u svakom sprintu

Navike koje održavaju sistem živim nisu glamurozne, i to je namerno. Skroman deo svakog sprinta pripada sistemu, a ne novim funkcionalnostima, i ostaje tu čak i kada rok postane uporan. Svaka izmena se upisuje u changelog sa rečenicom koja objašnjava zašto, kako bi proizvodi mogli da je prate sa sigurnošću, a ne sa strahom.

Biblioteka ima i svoje mesto za učenje, sa primerima i pravilima, tako da neko nov ne mora da čeka sastanak da bi počeo. A pre nego što se bilo šta novo primi, tražim nešto staro što može da se povuče. Vitkiji sistem je jednostavno lakše održati živim.

Šta se menja

Timovi prestaju da zaobilaze sistem, jer traženje izmene postaje brže od kopiranja komponente. Ažuriranja prestaju da plaše, jer je svako malo i objašnjeno. A sistem zadržava vrednost dugo posle lansiranja, što je, na kraju krajeva, jedini razlog da se pravi.

Na mom poslednjem velikom projektu biblioteka je radila kao poseban prostor za učenje pored proizvoda, a svaka izmena je upisivana u changelog sa kratkim obrazloženjem. Novi ljudi su mogli sami da nađu odgovore, a proizvodi su mogli da prate biblioteku bez bolne migracije.

Kada je prepravljanje ispravna odluka

Ponekad male popravke nisu dovoljne. Kada su sami temelji pogrešni, na primer tokeni koji mešaju značenje sa vrednošću, ili komponente napravljene za proizvod koji više ne postoji, krpljenje samo širi problem. Tada prepravljam jednom, pažljivo, i uspostavljam navike zbog kojih drugo prepravljanje neće biti potrebno.

Dizajn sistem nikada nije gotov. To možda zvuči iscrpljujuće, ali je zapravo prilično dobra vest: znači da ga ljudi i dalje koriste.