Forumi » Tutorijali i uputstva

Kako projektovati softver u tri pitanja?

    • 378 postova
    09. август 2016. 11.45.33 CEST

    Kroz ove korake izbeći ćete pisanje "lazanja" ili "hipster" koda.

     

    Jedina stvar koja je konstantna – to je činjenica da se sve menja…

     

    U svetu programiranja je to naročito tačno. Toliko da se kvalitet koda može proceniti na osnovu toga koliko lako može da se promeni ili adaptira.

     

    Uvek ćemo imati još jedan korisnički zahtev ili ćemo praviti izmene u poslednjem trenutku, što je ponekad jako naporno. Zbog toga je bitno da projektujemo softver, koji može da se prilagodi novim uslovima i novim zahtevima korisnika brzo i bez previše rada sa naše strane.

     

     

    Biti programer je teško

     

    Stvar koja je vrlo zanimljiva u vezi sa programiranjem je to što u većini slučajeva zapravo nemaš dovoljno znanja o domenu za koji praviš softver. Na primer, čast izuzecima, retko koji programer ima znanja o komplikovanom svetu finansija, a upravo je FinTech jedna od najaktivnijih grana razvoja startupa danas. Medicina, pravo, prosveta su sve oblasti za koje je potrebno završiti poseban fakultet, a opet, velika je verovatnoća da ćeš kao programer praviti softver baš u nekoj od njih.

     

    Tačno je da se uz malo prakse čovek (programer) svemu nauči. Ali ovaj članak je u vezi sa tehnikom projektovanja koda, koja se može primeniti od samog starta i koja je jako korisna kada treba doneti važne odluke na početku.

     

     

    Šta je loš kod?

     

    Prvo bih želeo da iznesem neke od ustaljenih naziva za veoma loš kod, i objašnjenja za iste, jer na greškama se uči:

     

    Špageti kod – kod u kojem svaka komponenta zavisi od svih ostalih komponenti i ne može se izdvojiti jer je previše upetljana sa ostatkom koda. Ukratko takav kod je vrlo teško menjati deo po deo, već samo u celini.

    Lazanja kod – kod u kojem ima previše slojeva. To nastaje kada u početku pokušavamo da napravimo što više apstrakcija za problem o kojem ne znamo dovoljno. Na primer: previše klasa, ili previše modula ili servisa.

    Hipster kod – previše frameworka. To nastaje kada problem rešavamo ubacivanjem svakog novog alata koji je trenutno “u modi”. Zbog toga smatram da je “choose your own framework” filozofija ogledalo lenjosti CTO-a i često viđam kompanije koje imaju problema sa tim pristupom – iako u teoriji dobro zvuči.

     

     

    Šta je dobar kod?

     

    Dobro, pošto smo ovo razjasnili, možemo se vratiti u prastara vremena, kada su Drevni (stara napredna civilizacija) uspostavili neke od osnovnih principa programiranja koji i danas važe:

     

    Otvoreno/zatvoreno (Open/Closed) – Sveti gral programiranja, kaže da bi za dodavanje novih opcija trebalo pisati isključivo novi kod, a da je stari kod zatvoren za izmene. To se postiže time što se unapred predvidi način na koji će se softver razvijati u budućnosti i u skladu sa time se postave dobri temelji koji to dozvoljavaju.

     

    U praksi ovo je nemoguće postići u potpunosti, ali ovde će biti reči o nekim generalnim smernicama koje nas postavljaju na pravi put.

     

    Jedna odgovornost (Single responsibility) – Ako jedan deo koda radi mnogo različitih stvari, onda svi ostali delovi koda zavise od tog jednog dela i vraćamo se na špageti kod.

     

     

    Kako doći do dobrog koda?

     

    Do dobrog koda se može doći postavljanjem pravih pitanja na početku projektovanja.

     

     

    1. Pitanje

     

    Iz kojih osnovnih delova se sastoji ovaj novi feature?

     

    Ovde se oslanjamo na dosadašnje iskustvo i znanje iz oblasti projektovanja softvera, da podelimo feature na manje delove prema onome što nama lično ima smisla. Na primer pokušavamo da uočimo neke obrasce koji su nam već poznati, kao što su:

     

     

     

    2. Pitanje

     

    Koje komponente izgledaju kao da su vrlo usko povezane jedna sa drugom – da li postoji špageti kod u najavi?

     

    Ako je odgovor na ovo pitanje pozitivan, onda se treba vratiti na pitanje 1. Generalne smernice kako se može razrešiti ovaj problem su:

     

    Parametri funkcija bi idealno trebalo da budu samo prosti tipovi, ili ako to nije moguće, onda treba izbeći kompleksne objekte kao parametre funkcija. To je zato što kompleksan objekat kao parametar funkcije zahteva da ta funkcija zna mnogo o strukturi tog objekta što ih usko vezuje i smanjuje generalnost date funkcije.

     

    Treba koristiti Mediator projektni obrazac ako postoji veliki broj komponenti koje međusobno komuniciraju. Mediator je direktna implementacija implicitnog pozivanja i pomaže pri razdvajanju objekata.

     

    Stavljanje jačeg akcenta na single responsibility principle. Prosti objekti (koji rade samo jednu stvar) po definiciji ne zavise od mnogo spoljnih faktora.

     

     

    3. Pitanje

     

    Koliko često očekuješ da se ova komponenta menja?

     

    Ovo poslednje pitanje je najvažnije i upućeno je nekome ko ima znanja iz domena u kome pravimo softver, na primer stručni savetnik, klijent, i sl… Ponekad odgovori koje sam dobio na ovo pitanje se nisu ni malo slagali sa mojom intuicijom, što bi dovelo do pogrešne arhitekture softvera.

     

    Najvažnije je da razdvojimo komponente koje očekujemo da se često menjaju od onih koje bi trebalo da budu relativno stabilne.

     

    To se uglavnom rešava primenom sledećih obrazaca:

     

     

     

    Ovo zvuči očigledno, međutim problem leži u tome što je programeru (opet čast izuzecima) vrlo teško da zaključi šta će se menjati često, a šta se neće menjati skoro uopšte – na primer u medicini, pravu ili nekoj drugoj neinženjerskoj oblasti.

     

    Bonus: ako se nađete u situaciji da želite da postavite sledeće pitanje klijentu:

     

    Zbog čega želiš da uradiš to baš na taj način?

     

    – to znači da ste upravo ispustili priliku da postavite 3. pitanje, a ne da u tom trenutku uđete u raspravu sa klijentom o tome kako je vaše rešenje bolje i optimalno. Znam da verovatno jeste – ali ako se posmatra izolovano od spoljnih (često iracionalih) faktora. Osoba koja je naručila softver uglavnom ima širu sliku u glavi o svojim potrebama u budućnosti od vas i to treba iskoristiti.

     

    Izvor:startit.rs


    Poslednja izmena: 09. август 2016. 11.51.58 CEST"