Nedavno sam naletio na ovaj vrlo zanimljiv tekst što me navelo na razmišljanje jer sam se prepoznao u tome.
Autor gore navedenog teksta naišao je na vrlo zanimljiv naslov “Why I wrote 33 VSCode extensions and how I manage them” gdje se među komentarima moglo vidjeti sljedeće:
My problem with adding plugins or extending my environment much past the default is that eventually I have to deal with a co-worker’s non-extended default installation. I end up relying too much on the add-ins.
Shvatio sam da sam i ja do nedavno na takav način, za onih “što ako” 5%, donosio odluke. Komentar koji mi je posebno “zapeo za oko” kaže:
I strongly dislike the reasoning that suggests you should hamstring yourself 100% of the time to accommodate a potential situation that may affect you 5% of the time.
“I don’t use multiple monitors because sometimes I’m just with a laptop”.
“I don’t customize my shell because sometimes I have to ssh to a server”
“I don’t customize my editor because sometimes I have to use a coworkers editor”.
Sada vidim koliko takav način razmišljanja nije imao smisla, ali tada mi se sve to činilo sasvim logično i vrlo sam odlučno branio svoje stavove.
Sjećam se da dugo vremena nisam htio koristiti nikakvu drugu temu niti većinu proširenja za Visual Studio Code ili Sublime Text jer što kada budem morao koristiti PC od kolege, a on koristi zadanu temu ili nema određeno proširenje.
Znači u startu sam se ograničavao i umjesto da sebi olakšam 95% slučajeva ja sam više razmišljao i radio na preostalih 5% jer tada nisam shvaćao sljedeće – optimizacija za 5% je primjer optimizacije za scenarij “što ako”.
Činio sam sve što je u mojoj moći da svoje razvojno okruženje učinim dovoljno generičkim da može raditi svugdje i da mogu biti spreman za onih 5%, ali sam zapravo otežavao sam sebi 95% vremena, a to je vrijeme koje je najvažnije.
Takve vrste odluka ne utječu samo na razvojno okruženje nego i na kod.
Personally, I often try and over optimize before I’ve even begun. Consequently I get overwhelmed and rarely build any of the ideas I was thinking about. – izvor
Ako se nešto ide programirati da bi odgovaralo “što ako” scenariju to znači da vjerojatno u potpunosti ne odgovara traženoj specifikaciji. Možemo mi kao developeri misliti što god hoćemo i htjeti unaprijed napraviti pripremu za sve moguće scenarije, ali ako to nije traženo po specifikaciji može doći samo do još više grešaka koje će samo oduzimati dodatno vrijeme za rješavanje, a do tih grešaka nije niti trebalo doći.
Premature optimization is the root of all evil.
Ipak, kada vidimo na koji način radi Google i druge velike tvrtke opet je moguće doći do izgovora za “što ako” scenarij i raditi nešto što nam realno nije potrebno pri čemu fokus opet odlazi na dio od 5%.
Ako neka velika tvrtka nešto koristi na određeni način to ne znači da taj način odgovara svim ostalim tvrtkama.
Instead of just getting your app up and running and seeing how it goes, you try to make decisions so that your application can be developed by 100 different teams sprawling across 5,000 developers.
Do 5% može doći i prilikom procesa implementacije tj. postavljanja aplikacije u produkciju.
To često može uključivati mjesece potrošene na detalje poput savršenog skaliranja, automatizacije određenih procesa i sl. što na kraju ne dovede do očekivanih rezultata jer sva dostupna rješenja, ma koliko tvrdila drugačije, ne mogu dati odgovor za sve vrste scenarija. Velike tvrtke koje su ta rješenja kreirala i koje ih koriste iza toga skrivaju mnoštvo specifičnih prilagodbi da bi sve radilo na određeni način.
When you try to optimize your deployment strategy to handle a billion requests a second from day 1, you’re just setting yourself up for an endless loop of theory based research.
Zaključno, energiju je pametnije usmjeriti prema 95% i vidjeti kako će se stvar ponašati. Ovisno o povratnim informacijama raditi dodatne optimizacije. Drugim riječima, raditi optimizaciju onda kada postoji realna potreba za tim, a ne zbog “što ako” slučajeva.
