KONFERENCIJA CHANGE

Developeri, znate li ocijeniti kada izmišljati ‘toplu vodu’, a kada koristiti tuđa rješenja?

Sviđa vam se članak?

Preporučite ga prijateljima i kolegama putem društvenih mreža!

Developeri se tijekom rada često susreću s jednom velikom dilemom: Kako ocijeniti kada neku funkcionalnost razvijati sami, a kada koristiti tuđu pamet? Upravo je to bio glavni fokus predavanja Alana Pavičića, održanog u sklopu konferencije Change koja je u prošlu subotu, u prostorima zagrebačke tvornice čokolade Kraš, okupila više od 300 sudionika.

alan_pavicic_cover

Kako ocijeniti kada neku funkcionalnost razvijati sam, a kada koristiti tuđa rješenja? Upravo je to bila glavna tema predavanja Alana Pavičića, održanog u subotu na konferenciji Change.

Na konferenciji Change, u organizaciji tvrtke King ICT, održana su 22 predavanja podijeljena u dva tracka, a bila su namijenjena developerima koji se bave razvojem enterprise softvera. Tematika na konferenciji fokusirala se većinom na Java i .NET enterprise development, uz pokoje predavanje o tuningu baza podataka ili performansama.

Koristiti tuđe rješenje ili razvijati vlastito

U mnoštvu specijaliziranih predavanja, izdvojilo se jedno koje nije bilo toliko usmjereno na tehnologiju, već više na filozofiju samog razvoja. Riječ je o onome Alana Pavičića na temu Custom vs. Modular Software Development.

Većina nas developera barem se jednom susrela s dilemom: Koristiti tuđe rješenje koje je već dostupno ili krenuti u razvoj vlastitoga? Postoje brojni razlozi i za jednu i za drugu opciju. Kako je Alan Pavičić rekao na predavanju, velik dio developmenta danas se svodi na pisanje Turing kompletnih konfiguracijskih fileova. Malo toga je danas potrebno ‘programirati’ ručno. Za skoro sve postoji library. Rijetko koji developer se susreće s Big O notacijom i sličnim pojmovima.

Stoga se velik postotak developmenta danas svodi na povezivanje tuđe pameti u jednu funkcionalnu cjelinu i stvaranje neke dodatne vrijednosti u takvoj cjelini.

Not Invented Here (NIH) sindrom

Velik broj organizacija pati od takozvanog NIH sindroma. Wikipedia ga opisuje kao tendenciju prema izmišljanju “tople vode”, odnosno razvoju nečega što je već dostupno, zasnovanome na vjerovanju kako je in-house development brži, bolji, sigurniji i jeftiniji nego korištenje već gotovih rješenja.

Naravno, time organizacije često same sebi stvore dodatne probleme. Kako je istaknuo Pavičić, NIH sindrom se često manifestira dužim vremenom razvoja neke funkcionalnosti, nedostatkom standardizacije te puno težim pronalaskom bugova i duljim vremenom potrebnim za debuggiranje. Što je zapravo i logično. Naime, ukoliko postoji zajednica koja razvija, koristi i održava neku funkcionalnost, utoliko je veća vjerojatnost da će bugove pronaći i ukloniti brže od vaše organizacije. Naravno, osim ako vaša organizacija nije veličine Microsofta ili Oraclea. Neke od prednosti korištenja tuđih modula su brže vrijeme izlaska na tržište, kraće vrijeme razvoja te korištenje funkcionalnosti koje nisu trivijalne za implementaciju (kriptografija je jako dobar primjer).

Ovakvi su primjeri vidljivi čak i kod organizacija koje su stručnjaci u sigurnosti. Theo de Raadt, osnivač i vođa projekata OpenBSD i OpenSSH, kritizirao je OpenSSL zbog razvoja rutina za upravljanje memorijom umjesto korištenja onih iz standardne C biblioteke te je prema njemu to glavni razlog za popularni OpenSSL Heartbleed bug koji je zahvatio većinu svjetskih Linux servera.

Proudly Found Elsewhere (PFE) sindrom

bakic_change_king_ict

Nenad Bakić, poznati investitor i poduzetnik posvetio je svoje predavanje društvenim promjenama, ali i kako tehnologija može smanjiti jaz između svijeta i Hrvatske.

Ipak, postoji i suprotni slučaj od NIH sindroma, a naziva se PFE sindrom. Korištenje eksternih modula za gotovo svaku funkcionalnost u vlastitom rješenju nije uvijek najpametnija ideja. Više od svih ostalih grana developmenta, današnji web development je posebno podložan ovom sindromu. Sjetimo se samo left-pad fijaska kada su React, Babel i hrpa ostalih high-profile paketa na NPM-u popucali jer su kao dependency imali modul čija je jedina svrha bila popunjavanje stringa s lijeve strane nekim znakom. Posao za koji je bilo kojem developeru potrebno svega par minuta izbjegnut je korištenjem modula koji se sastoji od čak 11 linija koda! 

Cijela saga oko povlačenja left-pada iz NPM-a je vrlo zanimljiva te ako niste čuli za nju definitivno preporučujem kao zanimljivo štivo.

Left-pad fijasko nam je pokazao kako ne treba slijepo koristiti tuđe module jer se dovodimo u situaciju kako previše ovisimo o nekom drugom. Sve ovakve trivijalne implementacije trebali bismo odraditi sami.

Kada koristiti ‘custom’ module

Pavičić je na predavanju naveo nekoliko situacija kada smatra kako je kritično koristiti in-house razvoj:

  • DSL – Domain Specific Language

Ako vaša aplikacija zahtijeva korištenje nekog DSL-a, gotovo uvijek je bolje razvijati svoj DSL te prilagoditi ga svojim potrebama, nego pokušavati prilagođavati neki general purpose jezik.

  • Core Business

Bilo koja funkcionalnost vašeg proizvoda koja predstavlja vaš core business mora se razvijati interno. Nikada nije pametno dovesti se u situaciju da vaša glavna funkcionalnost, ona koja vaš proizvod odvaja od konkurencije, ovisi o hrpi vanjskih modula i da može puknuti zbog nečijeg bunta (opet left-pad!) ;)

  • Specijalizirani algoritmi

Svi jednostavni problemi u startup svijetu već su riješeni. Nećete napraviti novi Facebook ili novu tražilicu, nećete se obogatiti nekom jednostavnom stranicom. Ono što preostaje su specijalizirane usluge koje odrađuju neke zadaće koje obični korisnici ne mogu ili ne žele rješavati. Takve usluge zahtijevaju i specijalizirane algoritme, koje ćete jednostavno morati razvijati in-house.

  • Smanjivanje dependencyja

Ponekad je pametno da neku funkcionalnost implementiramo sami ako želimo da naš proizvod ovisi o što je manje vanjskih utjecaja. Vrlo čest razlog za ovo je i rješavanje problema oko licenciranja.

  • Egzotičan hardver

Ako koristite egzotičan hardver, vrlo često nemate izbora i morate se okrenuti custom developmentu.

Rješenja iz ‘crne kutije’

change_konf_panel

Konferencija je završila panel raspravom na temu Softver i društvo, na kojoj su sudjelovali Nenad Bakić, Aleksander Radovan (King ICT), Geertjan Wielenga (Oracle) i Netokracijin Ivan Brezak Brkan.

Ovo nipošto nisu sve situacije u kojima bi trebali koristiti in-house razvoj. Kako se razvojni ekosustavi sve više šire, modularno je riječ sve zastupljenija u svim sferama developmenta. Web frameworkovi imaju tendenciju sve više funkcionalnosti izdvojiti u zasebne module.

Za sve više primjena, uz frameworke dolaze out-of-the-box rješenja koja ih rješavaju, a vrlo često funkcioniraju na principu crne kutije. Možda ih i mi developeri jednostavno tako koristimo. Često ih uzimamo zdravo za gotovo i sve se manje trudimo razumjeti što se stvarno u pozadini događa. Možemo reći kako imamo dobar izgovor za to, kako je time-to-market sve kraći i jednostavno nemamo vremena raditi sve sami.

Mislim kako će se u budućnosti uspješni od neuspješnih razlikovati upravo u sposobnosti procjene što da naprave sami, a što da koriste od drugih.