Savladali ste osnovne koncepte jezika koji Vam je delovao primamljiv. Znate šta su promenljive, petlje, grananja…
Uspevate da naterate sebe da kod koji pišete ne bude hrpa linija, kojima je jedina svrha da – rade. Kod koji pišete sada već ima lepu strukturu i organizaciju. Liči na nešto što bi se i moglo održavati, kada za to dođe vreme. Ono početno ushićenje koje ste osetili kada ste uopšte otkrili programiranje zamenilo je jedno novo. Sada imate utisak da možete sve – ili bar želju da pokušate. Svaku funkcionalnost koju zapazite u nekoj aplikaciji pokušaćete da ugradite u svoje „čedo“. Svaki put kada to i uspete, bivate nagrađeni sjajnim osećajem.
U tom razvojnom dobu programera, možda Vam deluje pomalo čudno što neki drugi programeri, pa čak i profesionalci stalno teže ka i pričaju o korišćenju gotovih delova u svojim aplikacijama. Zašto je to tako? Šta su te „biblioteke“ i „frejmvorci“? Prvo, profesionalci osim osećajem uspeha, po definiciji, vole da budu nagrađeni i novčano. Nezgoda sa razvijanjem softvera za drugoga je što on ne samo da želi da dobije ugovorene funkcionalnosti, već ih želi i u nekom razumnom roku. Jasno je da će verovatnoća da se to dogodi biti veća ukoliko, kada je to moguće, neke delove aplikacije ne razvijate od nule, već ih dograbite gotove sa police i ugradite.
Međutim, ušteda vremena nije jedina dobit. Možda toga još niste svesni, ali važan, čak neophodan, korak u razvijanju kvalitetnog softvera, osim implementacije, je i njegovo testiranje. Gotova rešenja koja preuzimate trebalo bi da su prošla sve oblike automatizovanog testiranja, o kojima ćete čuti na našim kursevima, poput jediničnog (unit) testiranja. Osim ovih, struktuiranih i formalizovanih, oblika testiranja, rešenje koje preuzimamo do sada je i oprobano u praksi. I drugi su to rešenje ugrađivali u svoj softver, naišli su već na njegove manjkavosti i bilo je vremena da se one isprave. Biblioteke su, po cenu izbegavanja formalnih definicija, „komad“ softvera koji nudi određenu funkcionalnost, a koji je tako organizovan da se može lako iskoristiti u sklopu neke aplikacije koju razvijamo. Dovoljno je da uključimo biblioteku u svoj projekat i pozovemo određenu funkciju, koja će za nas da obavi posao.
Naravno, potrebno je da znamo šta to treba pozvati, kakve parametre očekuje data funkcija i kakva je njena povratna vrednost. Stoga, sastavni deo svake kvalitetne biblioteke je i dokumentacija. To je, pored postojanja testova, ujedno i jedno od merila po kom biramo biblioteke ukoliko više njih nudi funkcionalnost koja nam je potrebna. Ali, šta je onda radni okvir, ili „u originalu“ framework? To je, opet, gotov komad softvera koji nudi određenu funkcionalnost. Iako bismo se po tome, s pravom, mogli zapitati nije li to onda ista stvar kao i biblioteka, razlika je suštinska. Naime, za razliku od biblioteke, koju ugrađujemo kao deo svoje aplikacije, framework je gotov skelet koji sadrži implementirane određene mehanizme, za koje je neko prepoznao da se ponavljaju u svim aplikacijama određene namene.
Sada mi u taj skelet ugrađujemo svoje delove. Na taj način, framework prilagođavamo konkretnom poslu zbog kog razvijamo aplikaciju. Naravno, ništa nas ne sprečava da neki od tih delova budu – biblioteke.
Da li je to sve? Ni izbliza. Tu su još servisi. Servisi, po malo nesrećnog prepeva na Srpski, u originalu, service, pre svega označavaju uslugu. Servisi su idealni za one koji ne vole pomenute šeme sa „ugrađivanjem“. Niti servis ugrađujemo kod sebe, niti se mi ugrađujemo u servis. On živi za sebe – negde. Možda na istom računaru, možda negde u oblaku (o raznim meteorološkim fenomenima u informacionim tehnologijama možda neki drugi put). Mi ga pozovemo, on obavi posao i saopšti nam šta je rezultat. Milina!
