Software Design Document (SDD) nije birokratski dokument već jedan od najvažnijih alata za donošenje tehničkih odluka. Ispravno napisan dizajn dokument može da spreči pogrešne arhitektonske izbore, uštedi godine razvoja i olakša saradnju između timova pre nego što bude napisana ijedna linija koda.
Na to ukazuje i softverski inženjer sa iskustvom u kompanijama Google i Microsoft, koji ističe da je osnovna svrha dizajn dokumenta da identifikuje najteže tehničke probleme i omogući kvalitetne povratne informacije dok su promene još jeftine i jednostavne.
Kada Software Design Document zaista ima smisla
Autor navodi da dizajn dokument nije potreban za svaki projekat. Njegova vrednost raste kako se povećavaju kompleksnost, rizik i broj ljudi koji učestvuju u razvoju.
Posebno je koristan kada projekat traje više meseci, uključuje više razvojnih timova ili kada postoje značajni bezbednosni, infrastrukturni ili poslovni rizici. U takvim situacijama dokument pomaže da svi učesnici dele isto razumevanje ciljeva i tehničkih odluka.
Istovremeno upozorava da previše detaljan dokument može imati suprotan efekat. Ako tokom faze planiranja budu definisani svi implementacioni detalji, praktično je napisan ceo sistem pre nego što razvoj počne.
Najvažnije pitanje: koliko košta pogrešna odluka?
Autor predlaže jednostavno pravilo za određivanje sadržaja dokumenta: šta je cena pogrešne odluke?
Ako izbor tehnologije, arhitekture ili infrastrukture kasnije zahteva višemesečni refaktoring ili kompletno prepisivanje sistema, takva odluka mora biti detaljno obrazložena u dizajn dokumentu.
Sa druge strane, odluke poput toga da li će aplikacija prikazivati 20 stavki po stranici ili koristiti dugme "Load more" ne zaslužuju opširnu raspravu. Takve izmene mogu se napraviti za nekoliko sati na osnovu povratnih informacija korisnika.
Šta bi svaki dizajn dokument trebalo da sadrži
Prema autoru, ne postoji univerzalni šablon, ali većina kvalitetnih Software Design Document dokumenata ima zajedničke elemente.
Sve počinje jasnim ciljem projekta, objašnjenjem problema koji se rešava i poslovnim kontekstom. Nakon toga slede definisani ciljevi, ograničenja, scenariji korišćenja, kao i arhitektonski dijagrami koji omogućavaju da svi članovi tima steknu isto razumevanje sistema.
Važan deo dokumenta čine i SLO ciljevi (Service Level Objectives), odnosno merljive vrednosti poput dostupnosti sistema, latencije ili očekivanog opterećenja. Umesto neodređenih zahteva poput "aplikacija mora biti brza", dokument treba da definiše konkretne metrike koje će kasnije biti proveravane u produkciji.
Bezbednost i privatnost ne smeju ostati za kraj
Jedna od ključnih poruka vodiča jeste da se bezbednost i zaštita podataka moraju razmatrati još tokom dizajna sistema.
Dokument bi trebalo da identifikuje potencijalne napade, tačke poverenja između sistema, način zaštite osetljivih podataka, kao i strategiju logovanja i monitoringa. Na taj način mnogi problemi mogu biti rešeni pre nego što razvoj uopšte počne.
Autor preporučuje da se u dokument uključe i otvorena pitanja, alternative koje su razmatrane i razlozi zbog kojih su pojedina rešenja odbačena. To olakšava kasnije donošenje odluka i sprečava da se iste rasprave ponavljaju tokom razvoja.
Dizajn dokument nije formalnost već alat za kvalitetniji razvoj
Glavna poruka vodiča jeste da Software Design Document ne služi da dokumentuje svaku tehničku odluku, već da identifikuje one koje će biti najskuplje ili najteže promeniti kada razvoj odmakne.
Dobro napisan dokument omogućava timovima da rizike otkriju na papiru, a ne u produkciji. Upravo zato velike tehnološke kompanije ulažu značajno vreme u fazu dizajna, jer je mnogo jeftinije promeniti nekoliko stranica dokumentacije nego hiljade linija koda.
0 komentara