24 септембар 2016

SOLID

Uvod
Postoji  mnogo načina da nešto napravimo. Granični tagovi su Perfektno,  Solidno,   Loše i Uočljivo loše. Pošto Perfektno ne postoji, Uočljivo loše ne prolazi  ostajemo na opsegu od Solidnog do Lošeg. Ovde je tema od lošeg do solidnog.
https://en.wikipedia.org/wiki/SOLID_(object-oriented_design)
Pitanje  Čemu ovolika teorija?
Ako pravimo program onda je najbolje da sednemo i uradimo ga na najjeftiniji način , sa onim što imamo i šta nam prvo padne na pamet. I tako se to nekada radilo sa puno uspeha. Samo oni programi koji se više nisu menjali su bili uspešno odradjeni.  Velika verovatnoća za tako uspešne programe je da ih više niko ne koristi.  Nameće se zaključak da su dobro isprogramirani samo oni programi koje više niko ne koristi. Ako je to još isplativo eto ga i BIZNIS MODEL. 
Problem: 
Biznis od nas traži da radimo očekivano isplative stvari. Kažu - novac leži samo tamo gde stižu novi zahtevi. Nažalost, treba da smanjimo programiranje i počinjemo sa projektovanjem. Kako je projektovanje sada deo biznisa moramo da se uklopimu u šemu  - što veći prihodi i što manji troškovi. Prihodi mogu da budu veći tako što ćemo da podignemo jediničnu cenu (što nije do nas), ili da počnemo da prodajemo više komada. Da bi prodavali više moramo program da prilagodimo različitim situacijama, zahtevima, tržištima, kanalima distribucije, zahtevima dilera. Da prevedem na CEO zahtev – ne treba mi program već komponenta koja se vrti na desktop računaru, web-u, cloud- u,googlovom servisu, amazon servisu, Smart telefonu, TV , frižideru .
Nije teško zamisliti ERP komponetu koja je ugradjena u magacinski  frižider i povlači utrošak prema normativu; zatim skida sa lagera sirovine ; onda kada temperature dostigne – 3 stepena po tehnoločkom postupku roba se sprema za  distribuciju samoupravljivim kamionom koji ima drugu ERP kompnentu koja radi logistigu transporta. Ovu prethodnu  rečenicu sam počeko kao šalu. 
Elem, sa druge strane su troškovi  - nemoj trošiti novac na održavanje već samo radi ono što je zahtevano da se doradi (jer je očigledno za naplatu).
Ključna rečenica – neću da zavisim ni od jednog dobavljača već mi to napravi prema nekom standardu da mogu da ugradjujem šta hoću, kako hoću i kada hoću, ali napravi tako da kupac zove mene i odradimo kako ja hoću, kada ja hoću i šta ja hoću.

Pandora1:
Mi smo našem kupcu dobavljač. 

Mi programeri moramo da shvatimo da smo u biznis modelu dobavljači (troškovna strana) i da je prema ideja biznisa da budeno što jeftiniji. To možemo da postignemo na dva načina. Jedan je da tražimo manju platu, a drugi je da budemo produktivniji. NAŽALOST TO JE TAKO. Ako naletite na neki drugi model biznisa molim vas da me obavestite jer bih rado učestvovao u svemu tome. Samo, ovakvi biznisi imaju tendenciju da se uruše pa je pitanje koliko će  trajati.

Pandora2:
Mi smo našem dobavljaču kupac.

Premisa:
Lako je samostalno programirati jednokratni program koji treba sada i nikad više. Izazov je timski napraviti projekat koji će imati svoju vremenku liniju.

Ključne rači:
TIM, ŽIVOTNI CIKLUS

Publika:
Samo oni koji rade u većem timu na sofveru sa dužim životnim ciklusom. Za potebe ovog teksta zadnju etapu u životnom ciklusu ćemo posmatrati kao prelazak na viši nivo (ako smo bili dobri!).

Pred zaključak:
Ako smo rešili da pravimo kuću možemo da biramo TRI varijante. Prva, da odustanemo, druga da sve sami radimo ili treća da radimo sa arhitektama, majstorima, izvodjačima, konsultujemo ženu, taštu, gradsku gradjevinsku administraciju i potrebe komšijinog kućnog ljubimca. Najviše je onih koji su odustali (pre ili kasnije). Iako znam neke ljude koji su sve ovo sami odradili, ipak velika većina nas nije sposobna sama sve da napravi. Tu kreće problematika - Prvo moramo da nadjemo mesto obezbedjeno infrastruktrom, put,voda,struja internet, gas, grejanje  i plus još po-nešto šta će se tek pojaviti. Drugo, moramo da dobijemo dozvole, sertifikate, da se uklapamo u okruženje. Treće arhitekta, izvodjač, podizvodjač… Na kraju - renoviranje…  Dakle, postoji neki redolsed i neka instalacija, pa moramo da ovladamo tom problematikom. Tj. ako nismo sposobni sami da pravimo kuću moramo da se osposobimo da vodimo ceo projekat. U suprotnom pitanje je kakva će nam kuća biti. Poznavajući  majstore kao takve izazov je veliki. Nažalost takav je upliv otudjene veberovske filosofije 

Off topic:
 Ovo je ujedno i  savremeni paradoks novih tehnologija -Ako nismo sposobni za prosto onda  će se od nas tražiti da budemo sposobni za složeno. Ili ti lenjost je najveći pokretač znanosti, čime se strast lenjstvovanja podiže na još veći nivo. 

Off topic of off topic:
U ovom ciklusu najčešće korišćen stručni termin je  - "Kako te je ovaj pre mene zajebao, ja sad ništa ne mogu". Jer što te je prethodnik više zavalio to sledbenik može više da iskoristi, a sve u stilu da će i sledbenik nekom biti prethodnik.

Primeri:
Primetio sam da se u IT tutorijalima uzimaju primere iz vanprogramesrke prakse. To je odlika samo onih predavača koji ili nemaju iskustvo ili se obraćaju početnicima. Tako ću i ja da uzmem primer iz gradjivinarstva :) Ali, ajde da podgrejem sujetu  (moju I vašu) sa nekim situacjam iz ERP okruženja.

Naručio sam vrata. Majstor kaže "2000 eura i evo ruke". Ja mu moram reći – Zanima me specifikacija po komadu, izrada, transport, montiranje. Tj. moram da svedem na najnižu jedinicu mere inače ću u potpunosti da zavisim od tog majstora. Odvojiću svaki korak jer ako mi se žuri, a majstor nije završio sva vrata ja ću uzeti samo ona što je završio. Ako nema vremena da montira ja ću angažovati drugoga  koji će da ispoštuje univerzalnu procedure za montiranje , iako ne zna da pravi vrata .Ako sve ovo treba da radi jedan mastor  obično ću morati da čekam na kraju i molim ga. Naravno, ako ispadne još nepredvidjenih troškova moraću da ih učtivo platim. Ovako mogu da montiram ulazna vrata, da čuvam tu material dok se sve ne završi, pa tek na kasnije ostala vrata… ERP – poručivnje robe. Razbiću na pronalaženje zaliha kod centralnog magacina, izračun prodaje u periodu, izbor algoritma za optimalne količine, izrada porudžbenice, izrada zahteva za isporuku. Zašto – ako dodam novi mode optimizacije mogu jednostavno da ga implementiram i dodelim pojedinim maloprodajama, jer se ostali koraci nisu ni menjala. Tj. ako rešim da automatki generišem poručivanje za prodavnice postoje sve komponete samo biram koje su to prodavnice i umesto da svaka generiše svoju ja ću da pustim cron. Još bolje, napraviću eksterni servis da i ostali kupci mogu da naručuju. Rešim da izmenim poručivanje prema raspoloživim zalihama a ne prema stvarnim, opet je sve tu samo dodam novu metodu za raspoložive, a svi koraci su isti. Rešim da poručujem iz više magacina po mestu isporuke, opet je sve tu ….

Naručujem vrata od stolara. On me pita "koja ćeš vrata". Ja gledam projekat i dajem mu dimenzije. Što se tiče kvaliteta kažem mu da  pošalje ponudu. Tj. vrata su zatvorena i kada se zatvore znam koliki je ram, a što se tiče "kvake" za otvaranje možeš da staviš različite – skuplje jeftinije, na daljinski, sa zaključavanjem . Zamislite da u sred gradjenja kuće skontam da treba da imaj jednu sobu pod ključem ,  a stolar kaže nemem vrata sa zaključavanjem ili još gore imam takva vrata, ali sa drugim dimenzijama. Tj. ako želim da zaključavam vrata moram da štemam zid, a tu je prošla struja, moram da zovenem elektirčara, parket treba da se seče … U ERPu - imam dokument koji se knjiži u fin evidenciju. Hoću da napravim knjiženje u PDV evidenciju ali neću da diram logiku knjiženja u finasijsko. Iako na prvi pogled postoji zavisnost izmedju PDVa I Finasijskog ne bih to dvoje da dovodim  u vezu već odvajam logiku. Lakše mi je da napravim kontrolu ispravnosti i nju da okinem na kraju nego da menjam nešto na knjiženju u finasijsko što radi godinama dobro. Drugi primer dokument je entitet koj ima jedan child (tip stavke). Prijemnica ima stavke artikala koje kupujemo. Ne mogu da imam prijemnicu bez i jednog artikla, ali mogu da proširim model kada se pojavi prijemnica koja osim artikal ima zavisne troškove. Tj. kada proširim model ne sme da imam metodu koja mi vraća sve stavke (svih tipova) jer će mi se pomešati artikli i zavisni troškovi dobavljača.

Naručio sam prozore sa roletnom. U sred projekta odlučim da mi na severnoj strani ne trebaju roletne. Zovem stolara I kažem da mi na dva prozora ne trebaju roletne. Zamislite kažem izvodjaču da hoću da uštetid 300 eura I kupim obične prozore, a on  kaže  - OK dodješ  nama 600 eura da ti to omogućimo. Moraju da se prepravljaju šarke , buše zidovi na tri mesta . Prilikom ugradnje mogu da se odlučim za bilo koja vrata. Bilo bi glupo da obustavim projekat zato što mi ne trebaju blindirana vrata već obična. ERP – imam cenovnik i rabatnik. Prilikom odredjivanja krajne cene sa ugradjenim rabatom imam metodu  koja računa cene i rabat za taj artikl, subjekat i datum.  Zove nabavka  i kaže da se ukinu rabate za sve kupce odredjenih atikala do daljneg . Nije dobro ako fakturiasnje ne radi (npr. izlazi poruka – “Nije pronadjen rabat”). Tj kad se prebacim na podskup hoću da mi sve radi. Kalkulator cene sa rabatom je podskup kalkulatora cene bez rabata.

Dogovaram isporuku sa dobavljačima za slavine i tražim od njih ponudu sa cenom, rok isporuke, sliku i sertifikate o kvalitetu.  Posle toga to isto tražim za kadu, pločice i zavese. Oni mi sve to dostave na jednom papiru. Pločice su hitne, zavese mogu da čekaju. Kako se žena pita za dizajn, tašta  za cenu , izvodjač za rokove ja mora da sačekam svu dokumentaciju za sve delove i da ih spojim sve na jednom mestu pa da vidimo šta ćemo. Ne tako, već ću da kažem da mi cenu dostave na jednom papiru, rokove na drugom sertifikate na trećem. Prvo pogledam samo one koji imaju sertifikate i odvojim, izvodjač pogleda samo one koji mu odgovarju sa rokovima, žena za izgled i na kraju tašta odobri nabavku prema njenom subjektivnom doživljaju budžeta.  Da nije ovog načina ne bih mogao da ugradim pločice dok tašta ne kaže da li je zavesa skupa. Tj proces odobravanja pločica sam odvojio po cenovnika zavesa, jer da sam imao dobavljaca koji odobrava celu ponudu ne bih mogoa da kupim pločice od njega dok se ne odlučimo za zavese.  ERP  - imam interfejs za knjiženje u  robno, PDV finasijsko. Bilo bi glupo da je to jedan interfej  jer može da mi se desi da imam dokument PDVnaloge koji ne idu u robno, ali ide u FIN I PDV. Tj. Magacioner može sve interne dokumente da proknjiži u robno, a da ne čeka dozvolu finasijske službe koja kontroliše PDV jer interni dokumeti ne utiču na PDV.

Stiglo se do srujnih utičnica. Dobavljaču nikad ne kažem koji prozivodjač već  mi treba roba koja ispunjava odredjene standarde.  Dobavljači šalju ponude. Počnem da radim sa jednim distributerom strane robe  i iznenada nema zaliha, stao uvoz, Izvodjač kaže da probijamo rokove, ja ostatak robe naručim od domaćeg proizvodjača koji ispunjava uslove. Sa tim domaćim proizvodjačem čim potpišemo ugovor (čitaj interfejs) da mu je roba sertifikovana možemo da ugradjujemo istu, a bez da cimamo bilo koga – arhitektu, elektirčara jer i oni rade po sertifikovanim standardima. Ne bitno, jer svi ispunjavaju uslove. ERP -Isporučio sam korisniku komponentu za elektronsko plaćanje (koristi halcom servis). Korisnik kaže da želi da testira i da mu se u xls prebaci one podatke što bi se inače slali u halcom. Mi mu isporučimo sa komponentom za upis u xls. Kada vidi da je to dobro mi tu komponentu zamenimo sa  halcom API-jem i ulazi u produkciju. Stiže paypal, naš posao je da napravimo novi paypal service koji implemnentira postojeci interfej prema paypal API . Elektornsko plaćanje smo napravili na nekoliko opcija – otvorena stavke, dospela potraživnja, isplata zarada … Nista to ne menjamo kada stigne paypal service. Samo ga implementiramo. Još ako imamo spring samo izmenimo kontekst i sve radi.

Nema zaključka -
Gradjevinski projekti su znatno jednostavniji od softverskih. Prvi razlog je što je ovo  pisanije posvećeo  programerima pa moram malo da podilazim. Drugo, gradjevinskom objektu može naslututi kraj i neko drugi će sve to da održava. Treći razlog je što gradjevinci prave vizuelne utroške koje je lakše opravdati  i prave opipljive zgrade koje je lakše prodati. Mi programeri trošimo samo vreme  za učenji i izradu koje je veoma teško opravdati. Jer da nije tako što bi izmišljali toliko tehnologija, termina pravila. Da smo bili pametni prvi model bi bio dobar. Zato je u većini zemalja, pa i u zapadnim, satnica majstora i dalje već nego satnica developera. Takodje satnica arhitekte veća od softver projektanta. To se uklapa u MARKETIG MODEL BIZNISA, a za to treba konsultovati nekog marketing stručnjaka.

ERP интегратор - преводилац са корисничког на програмерски језик

У изреци "Ако брег неће Мухамеду, хоће Мухамед брегу!" свако, и од корисника и од програмера, тачно зна шта се на кога односи. Сви...