Godinama se developerima ponavlja da je dupliranje koda smrtni greh. DRY princip se gotovo religiozno poštuje, a svaka sličnost u kodu automatski se proglašava za anti-pattern. Međutim, praksa velikih sistema pokazuje nešto potpuno suprotno. U ozbiljnim projektima, pogrešna apstrakcija i preterano spajanje sistema često prave mnogo veću štetu od običnog dupliranja.
Na početku karijere većina developera ima jednostavnu sliku sveta. Ako se nešto ponavlja, mora odmah da se apstrahuje. Ako se pojavi još jedan Kafka topic, verovatno je loša arhitektura. Ako postoje dve slične klase, odmah treba da postanu jedna.
Kako rastu sistemi, timovi i odgovornosti, ovakva logika very brzo prestaje da važi. Loša apstrakcija i prevelika zavisnost između delova sistema drastično povećavaju kognitivno opterećenje, usporavaju razvoj i prave skrivene tehničke dugove koji eksplodiraju tek kroz vreme.
DRY princip u svojoj suštini ne govori “nikada ne dupliraj kod”, već “ne dupliraj znanje i nameru”. Problem nastaje kada se taj princip pretvori u dogmu.
Dupliranje modela podataka kao svesna odluka
Modeli podataka za komunikaciju između servisa obično su čiste klase bez poslovne logike, sa getter i setter metodama. U teoriji, one bi trebalo da žive u zajedničkom repozitorijumu koji svi koriste.
U praksi, takve deljene zavisnosti gotovo uvek završe na jedan od tri loša načina. Ili se nikada ne ažuriraju jer svako odlaganje smanjuje rizik od pada sistema. Ili se forkuju i svako održava svoju verziju. Ili se iste klase potajno dupliraju u kodu i proširuju lokalno.
Kada zavisnost postane preskupa za održavanje, timovi prestaju da je diraju. Svaka buduća izmena postaje rizična i skupa. Na kraju opet dolazi do dupliranja, ali tek nakon izgubljenog vremena i nakupljenih problema.
Zato je za veliki broj sistema racionalnije držati modele podataka lokalno u svakom servisu, čak i ako su trenutno identični. Svaki servis tada koristi samo ona polja koja su mu zaista potrebna. Promene se rade bez lomljenja drugih timova i bez globalnih refaktora.
Kafka topici i dupliranje koje štiti sistem
U pub/sub arhitekturi sa sistemima poput Kafka i RabbitMQ, jedno od ključnih pitanja je da li koristiti postojeći topic ili praviti novi.
Kod eksternih topica, gde jedan tim proizvodi događaje, a više drugih timova ih konzumira, rizik se brzo uvećava. Proizvođač često ne zna kako se podaci koriste dalje. Jedna mala promena može izazvati lančanu reakciju kroz ceo sistem.
U takvim slučajevima, odvajanje topica po poslovnim tokovima je daleko bezbedniji izbor. Iako postoji dupliranje infrastrukture, značajno se smanjuje blast radius promena i rizik od sistemskih padova.
Sa druge strane, kod internih topica unutar jednog domena gde isti tim kontroliše i produkciju i potrošnju poruka, dupliranje nema smisla. Jedan zajednički topic smanjuje troškove i pojednostavljuje održavanje.
Dupliranje poslovne logike kao zaštita od pogrešnog vezivanja
Najosetljivija odluka je uvek vezana za poslovnu logiku.
Na prvi pogled, dva identična algoritma izgledaju kao idealan kandidat za apstrakciju. Međutim, ključno pitanje nije da li su danas isti, već da li u budućnosti treba da se menjaju zajedno.
Tri pitanja pomažu da se donese ispravna odluka. Da li ova logika mora da bude univerzalna ili pripada konkretnom kontekstu. Da li promena u jednom toku treba automatski da utiče na drugi. Ko zapravo poseduje taj poslovni zahtev unutar organizacije.
Ako je odgovor da su konteksti različiti, onda je dupliranje potpuno opravdano, čak i ako je implementacija trenutno ista. Time se izbegava skriveno vezivanje sistema koje kasnije postaje gotovo nemoguće razmrsiti.
Ako je logika zaista univerzalna, tada pripada jednom mestu.
Upravo zato Sandi Mec je precizno formulisala jedno od najrealnijih pravila savremene arhitekture. Bolje je duplirati kod nego napraviti pogrešnu apstrakciju.
Gde dupliranje zaista nema opravdanje
Postoje slojevi sistema gde je dupliranje gotovo uvek loša odluka. To su repozitorijumi za rad sa bazom, klijenti za eksterne API-je i generičke utility funkcije. Ovi delovi predstavljaju tehničku infrastrukturu, a ne poslovni kontekst.
Dupliranje ovde gotovo uvek vodi u nekonzistentno ponašanje, nepredvidive bagove i eksploziju tehničkog duga.
Zašto pogrešna apstrakcija boli više od dupliranja
Duplirani kod se vidi. Loša apstrakcija se ne vidi dok ne bude kasno. Tada više nije reč o refaktoringu, već o operaciji na živom produkcionom sistemu.
Pogrešno apstrahovana logika pravi nevidljive zavisnosti između timova, usporava razvoj i tera inženjere da stalno razmišljaju o posledicama svake promene van svog domena.
Dupliranje daje lokalnu slobodu. Loša apstrakcija uzima globalnu stabilnost.
Zaključak koji menja način razmišljanja o arhitekturi
Dupliranje nije uvek neprijatelj. U mnogim slučajevima, ono je najmanje loša opcija. Pravi neprijatelj stabilnih sistema su pogrešne apstrakcije koje prerano povezuju delove sistema koji prirodno ne pripadaju istoj celini.
Iskusni arhitekte zato sve češće biraju lokalnu autonomiju umesto lažne univerzalnosti. Umesto da se bore protiv svakog ponavljanja, oni se bore protiv pogrešnog spajanja.
U realnim sistemima, dupliranje često štiti sistem, dok pogrešna apstrakcija tiho priprema teren za budući kolaps.
0 komentara