Hm, oblast je malo sira za nesto "na brzaka", ali hajde da pokusam da predstavim svoje gledanje na to.
Design patterns (ima i drugih naziva za istu stvar) su vrlo vazni u developmentu srednjih i vecih projekata, kada postoji vise ljudi koji na tom projektu rade.
Kod nas, na zalost, o takvim stvarima se mnogo ne razmislja, niti uci nesto na skolama i fakultetima - jer prave skole za IT i nemamo. Mozda mogu da te nauce da razmisljas sistemski, da se koristis nekim alatima i jezicima, ali se malo poklanja paznje timskom radu, pogotovo u domenima projektovanja i dokumentacije.
U principu, cim projekat odmakne malo dalje od "express knjigovodstvenih programa za 7 dana" i vodjenja video-kluba, potrebno je neko sistemsko planiranje, jer treba usaglasiti rad vise ljudi. Takodje, treba razraditi model do u detalje, da se proba da li sve stima i "na papiru", pre nego sto se krene na implementaciju, jer posle nema nazad i svako ispravljanje i prekrajanje kosta previse para i previse vremena.
Kod tog planiranja i projektovanja se razmatraju razlicite osobine projekta u njegovim razlicitim zivotnim dobima. Pazi, ne pricam ovde samo o prostijim OOD modeling alatima; ne, ide to i sire. Najveci deo logickog planiranja ide potpuno nezavisno od jezika - koriste se Use Cases analize, odredjuje data flow, cesto i tajming i najkrace rute, pa se tek onda prilazi OOD-u. Za neke jednostavne projekte, naravno, ne treba komplikovati sebi zivot, ali kada analiziras recimo rad jednog Warehouse preduzeca, koji vrsi i usluge spedicije po celom svetu, onda nema zezanja - ne mozes odmah prvi dan poceti sa "int main(int argc, char* argv[])" ili napraviti samo nekoliko skica kako bi to "otprilike" trebalo da izgleda. Elem, i nakon sto se odredi logicka struktura, hijerarhija i relacije delova projekta, implementacija se dodeljuje konkretnim ucesnicima projekta. I u toku rada, oni (ili nadlezni vodja tima) obelezava napredak - da li je nesto uopste zapoceto, koliko je odmaklo (procena u % najcesce), itd. - tako da se i u toku rada uvek ima aktuelni presek stanja glede vremenske provere; uvek se postave tzv mile-stone datumi, pa se proverava prolazno vreme. I na kraju, kada se sve i zavrsi, to ostaje kao dokumentacija za developere koji nastavljaju projekat da odrzavaju i/ili dalje razvijaju; neretno ljudi dolaze u firmu *nakon* sto je projekat uradjen, samo da bi ga odrzavali, nesto dodali i slicno.
Daklem, licno mislim da je to obavezna oblast za svakog programera koji hoce da odmakne od nivoa "ono sto sam naucio u skoli" i pomeri se od cistog fizikalisanja implementacije. OOD, dodatni alati, UML standardi, naglasak na "in team" mogu da te kotiraju mnogo, mnogo vise nego inace.
