Po meni, algoritmi su i izmisljeni da bi olaksali posao. Ali, ja ih ne koristim jer mi na kraju papir postane pun prezvrkanih delova... Najcesce se usredsredim na najtezi deo zadatka i njega resavam pomocu nekih proba, crteza, ... Ovo vazi za manje delove programa koji se na kraju uklope u veci program.

Na pocetku programa, kada imamo ispred sebe prazan papir, najvazniji problem je osmisliti arhitekturu programa ( ili ti, koje su nam klase potrebne )

Inace, "idealnu" arhitekturu veceg programa je skoro nemoguce projektovati iz prvog pokusaja cak i sa modernim mehanizmom OOP.
Najbolje je izgraditi deklaracije svih klasa ( koje su do ovog pocetnog stadijuma programa pronadjene ) i napraviti neku logicku vezu izmedju njih da bi se videlo kako ce nas dizajn raditi. Tek posle se bacamo na dodavanje funkcionalnosti svim klasama u programu i na resavanje pojedinacnih problema. Tada ce se verovatno javiti potreba za novim klasama ili za ubacivanjem funkcionalnosti na visi nivo u hijerarhiji klasa koje cine nas program da bi postigli dobar dizajn.

Ja pocnem sa velikom kolicinom brainstorming-a ...

Prvo u glavi pokusam da razradim sve koncepte, procitam dosta literature i helpa kako bih bio siguran da
svi pojedini delovi software-a mogu da se implementiriaju na taj i taj nacin ...

Za sve sto radim prvi put i nisam siguran kako ce funkcionisati (pogotovu ukoliko se oslanjam na postojeci
API koji nisam koristio), potom pravim niz mini test aplikacija koje sluze kao proof of concept ... (da budem
siguran da cu ideju moci realizovati i implementirati to na dati nacin ...)

Alate za modelovanje koristim samo za baze podataka ... tu (naravno u zavisnosti od kompleksnosti baze) potrosim
dosta vremena, misaono razradjujuci sve potencijalne slucajeve ...

Na kraju prelazim na UI komponente, takodje ako je potrebno radim proof of concept mini aplikacije ...

Kada radim mini aplikacije ne vodim racuna o iskoristivosti koda ... (obicno su to aplikacije koje se pisu za pola sata
i to radim nemarno tako da bi bilo neozbiljno da taj kod posle ponovo koristim)

Kada sam sve to dobro izbistrio, sedam i krecem uglavnom od kostura (ajde da kazemo da gradim hijerarhiju klasa, mada
nije uvek slucaj da je program 100% OOP) i kreiram nesto sto bi se moglo nazvati interface-om za svaku klasu, odnosno
zaglavlja procedura/funkcija i naravno strukture podataka ...

Do sada u zivotu nisam napravio dijagram algoritma ni na papiru ni u nekom alatu za modelovanje ...

U algoritmu, REDOSLED pozivanja naredbi (ili funkcija, procedura) je uvek isti. U OOP-u, mozete da birate redosled kojim cete pozivati metode klase, tako da tu nestaje potreba za nekim algoritmom (ili crtanjem istog). Cak i ako imate neku slozenu proceduru u klasi (obavlja neku komlikovanu obradu), ona se moze razbiti na vise manjih funkcija i procedura (metoda), tako da mozete te metode da KOMBINUJETE (pozivate) na proizvoljan nacin i zeljenim redosledom.

Ono sto je po meni problem kod svih programa (bez obzira na velicinu), jeste cinjenica da pre ili kasnije morate da ih doradite, izmenite itd... Ako niste pazljivo pratili razvoj programa, kroz dokumentaciju, prikladne komentare u kodu itd.. (ili je vise ljudi ucestvovalo u njegovoj izradi), prosto je nemoguce za kratko vreme uvideti gde se sta SME i MOZE menjati, a da ne ugrozite neki drugi deo koda u programu, odnosno da se ne pojave bagovi u delovima programa koje (kako to?) niste menjali. Narocito je tesko kada otvorite neku npr proceduru, a ona razvucena na 5 strana, i bez ikakvog opisa, i jos sve nabacano... U toj shumi tesko cete se snaci.

Dale: sta god da radite, kakav god program: OBJASNITE SEBI I DRUGIMA STA JE PISAC TIME HTEO DA KAZE! )koji je bio zadatak, kako ste ga resili i sta ta metoda treba da radi!)
Onog trenutka, dok pisete kod, mozda Vam je jasno sta hocete, ali posle nekog vremena (mesec, dva), ne da vam nece biti jasno, vec necete znati ni da li ste vi pisali tu glupost... :)

poz.