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

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

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’

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.