Labai smagu gauti klausimų apie programavimą. Šis Arno klausimas tikrai universalus ir vertas pilno blogo įrašo:
Ar dirbant programuotoju įmonėje yra normalu googlinti ir taip ieškoti solution'ų sprendimui?
Taip pat, kai gauni praktinę užduotį dėl įsidarbinimo, ar nėra blogai, kad sprendimas būna pasiremtas stackoverflow ar kokiu kitu web'u?
TL;DR
Taip. Googlinti, ieškoti atsakymų Stack Overflow, programuotojų bloguose, forumuose, GitHub'e ir panašiose vietose yra gerai, naudinga ir dažniausia būtina. Tieisiog nėra prasmės išradinėti dviračio kai dauguma problemų jau išspręstos.
# Kada mes dažniausia gūglinam
Pradžiai norėčiau apsibrėžti kodėl ir kada mes gūglinam. Čia kaip universitete, ieškoti ir naudotis šaltiniais yra skatinama, net privaloma, bet už nusirašinėjimą baudžiama itin griežtai.
Sutardami kokios priežastis veda mus į informacijos paieškas, galėsim įvertinti kurios iš jų teigiamos, o kurias geriau praleisti.
# Reference - kai norime pasitikrinti kokią nors informaciją
Programavimas, kalbos, frameworkai ir visi programavimo dalykai yra ganėtinai sudėtingi ir platūs. Neįmanoma atsiminti visko, tenka dažnai tikrintis ir žiūrėti kaip teisingai atlikti mums reikiamas užduotis. Mano Chrome'as praktiškai visada turi bent vieną tabą su MDN (Mozilla Developer Network).
Net nemėginu įsiminti kaip veikia koks nors Range API, nes mano galva tai nėra pati svarbiausia informacija kurią turiu kišti į galvą. Taip, dažnai ką nors žiūrint ir tikrinantis informaciją įsimenu. Buvo laikas kai galėjau mintinai surašyti viso puslapio HTML ir CSS su Boostrapu, gal tik reikdavo pasitikrinti jų navbar'ą, nes tas tai tikrai buvo itin painus.
Tai sutariam, kad tikrintis dokumentaciją, žiūrėti kaip teisingai užrašyti dalykus yra gerai.
# Research - kai ieškome sprendimu iškilusioms užduotims
Pats paprasčiausias researcho pavyzdys būtų "how to…" paieškos. Tarkim "hide text with jQuery", "do random sh with regex", etc. Dažniausia mes turim užduotį, bet niekada nesam šito darę. Vietoj burtų ir alchemijos praktikavimo, ieškome būdų kaip tai atliko kiti.
Net jei esam kažką darę, verta pasitikrinti, paieškoti kaip į situaciją reagavo kiti programuotojai, nes taip mes mokomės. Ieškoti, tirti, reasearchinti problemas yra mokymosi proceso dalis.
Galbūt šitas patarimas koreliuoja su patarimu mokytis darant tikrą projektą. Mes retai kada sugalvojam tiesiog iš niekur ką nors tyrinėti, bet realybėje susidūrus su problema, nebelieka nieko, tik ieškoti kaip ją išspręsti.
Nebūtinai tyrimas yra toks primityvus kaip pavyzdžiuose aukščiau. Darant sudėtingesnius reikalus, jis tampa sudėtingesnis ir gylis priklauso grynai nuo ieškotojo smalsumo.
Atsimenu kai ieškojau kaip teisingai įgyvendiniti slaptažodžio priminimą, perskaičiau nemažai postų apie techninius problemos aspektus, apie vartotojų informacijos saugojimą, privatumą, tapatybės nustatymą, apie pačių internetų saugumą ir dar tikriuasia kažką pamiršau paminėt.
# Resolution - kai bandome išpręsti pastrigimą
Jau matau, kad vos ne acronymą čia lipdom. Bus koks 4Rs of Googling 😄
Turbūt mažiausia malonus googlinimas kai turim aiškią problemą, bet negalim rasti jai sprendimo. Kode slepiasi bugas (ar keli), konsolės spjaudosi errorais, įrankiai neveikia kaip turėtų. Tokios situacijos varo į neviltį, mes pastringam net neįsivaizduodami kaip išsikapanoti.
Ieškom informacijos, kol išsprendžiam savo pastrigimą. Kartais tai atsitinka greitai, kartais turim kapstyti gan giliai, dar kitais kartais begooglindami nukeliaujam į paralelines visatas ir ten suvokiam, kad problema slypi kažkur tarp mūsų klaviatūros ir tarp to kaip fizikos dėsniai veikia tranzistorius.
Tikriausia ką noriu pasakyt, tai pasidalinti savo patirtimi tokiose situacijose:
- Geriausia naudotis rubber duck debugging technika. Kai smulkiai ir detaliai ančiukui aiškindamas kas vyksta ir neveikia pats suvoki kas ne taip. Gerai veikia ir aiškinant kitam žmogui, bet naudojamas to žmogaus laikas.
- Žinau, kad norisi kuo greičiau problema atsikratyti, bet čia reikia pradėti elgtis atvirkščiai. Net kai atrodo, kad jau viską perskaitei, skaityk dokumentacijas ir kitų žmonių problemas (GitHub issues, forumus, Stack Overflow) dar kartą. Itin atydžiai ir lėtai. Didelė tikimybė, kad pačioj dokumentacijoj viskas aiškiai parašyta, tereikia perskaityti kruopščiai, sąmoningai suvokiant kiekvieną žodį.
- Klausk. Jei nuoširdžiai atlikai 1 ir 2 punktus, tavo klausimas bus kokybiškas ir trolių gali nebijoti. Klausimai kurie remiasi dokumentacijomis ir kita surinkta medžiaga yra naudingi programuotojų bendruomenei. Klausdami ir aiškindamiesi kažkokį dar neišaiškintą dalyką mes padedam ne tik sau, bet ir kitiems, susidursiantiems su panašia bėda.
# Random - kai googlinam iš tingėjimo
Pradedantieji dažnai nori greitų atsakymų. Radau, nukopijavau, VEIKIA!
Neaišku kodėl, neaišku kaip, net nesvarbu. Tiesa ta, kad programavimas yra daug laiko ir kantrybės reikalaujantis reikalas. Noras ką nors sumesti greitai ir neskausmingai prasilenkia su realybe (bent karjeros pradžioj).
Šitokį googlinimą pateisinu tik tada, kai rasti pavyzdžiai panaudojami savišvietai, jie tyrinėjami ir aiškinamasi kodėl ir kaip jie veikia. Bet tikriausia čia jau pasidaro research.
# Googlinimas ieškant sprendimo darbo interviu užduočiai
Įsidarbinimo proceso užduotys turėtų būti ne kasdienis iššūkis. Leisti atlikti ką nors, ko nesi daręs arba ko programuotojai įprastai per daug neveikia.
Man patiko užduotis, kai kažkokį nesudėtingą webapp'siuką turėjau sumesti be frameworko (vanilla JS). Įprastai šito mes neveikiam, bet buvo smagu pamatyti kiek daug pagalbos susilaukiam iš frameworko ir ką jie už mus atlieka.
Kartu dar turiu tokį disclaimerį. Aš esu iš tos stovyklos, kur tiki, kad sudėtingos teorinės užduotys yra visiškas bull. Taip, jos turi savo vietą ir svarbą, bet gal ne samdant entry lygio web/UI developerį.
Grįžtant prie užduoties, tai taip, aš nežinau kaip be bibliotekos veikia AJAX'as. Ieškau dokumentacijos, ieškau sprendimo ir darau. Taip, nusikopijuosiu pavyzdį, tada pritaikiysiu jį savo situacijai.
Per darbo interviu užduotis stengčiausi suvokti ką ta užduotim norima patikrinti. Atsimenu kažkur girdėjau apie užduotį kurią duodavo Spotify inžinieriams kandidatams. Reikdavo tiesiog padaryti upload fieldą ir rodyti kiek procentų failo jau užsiuploadino. Frontendas + Node.
Dauguma kandidatų nepraeidavo užduoties, nes jie tiesiog backende įsimesdavo uploadus (ir procentus) valdančią biblioteką. Iš užduoties apibūdinimo, mes galim suvokti, kad norima tikrinti kaip suvoki uploadinimo procesą ir kas tuo metu vyksta, o ne kaip gali šitai įgyvendinti.
Šiuo atveju, StackOverflow būtų visai gera vieta daryti savo tyrimą (research), bet sprendimo įgyvendinimą reiktų atlikti pačiam.
# Googlinimo pavojai
Vietos kur galima save prigauti veikiant blogus dalykus, kur reiktų pasisaugoti.
# Būtina suprasti kaip veikia rastas sprendimas
Žinau, esu ir aš naudojęs kodo gabaliukus kurių nesuprantu. Norėjau kuo greičiau atlikti užduotį, nesuprasdamas, kad greitis toje situacijoje nebuvo reikalingas, o galbūt net buvo ir kenksmingas.
Kopijavimas be supratimo gali būti ir pavojingas. Ypač komandinės eilutės komandos ir skriptukai. Turbūt tikrai pavojingos komandos bus išimtos, paslėptos, nubalsuotos žemyn, bet tiek pat pakenkti gali ir su normaliom, iš pažiūros eilinėm komanom, naudodamas jas neteisingai.
Atsimenu kai kažką instaliavau ir neveikė, sugalvojau (o gal radau patarimą) panaudoti
sudo. O taip, instaliuoti pavyko, bet to kaina buvo path'ų, versijų ir dar kažkokia maišaklynė man kainavusi labai daug ieškojimų, perrašinėjimo ir mokymosi kaip iš vis veikia operacinė ir kaip suremontuoti ką sulaužiau.
Nekopijuok! Perskaityk, pasistenk suprasti, pažaisk su pavyzdžiu kaip įmanoma labiau izoliuotoj aplinkoj ir naudok tik suvokęs kas realiai vyksta.
# Kapstykis giliau
Ne visais rastais atsakymais galima pasitikėti. Geriausia taisyklė yra nepasitikėti niekuo, į visą svetimą kodą žiūrėti gynybiškai. Tol, kol suprasi kaip jis veikia, ką atlieka ir kodėl pasirenkamas būtent toks spredimo būdas.
Pirma kapstymosi giliau pagalba yra komentarai. Kiekvienas StackOverflow klausimas, kiekvienas blogo postas turi komentarus - ieškok sprendimo vertinimo ten. Jei neturi komentarų, tai jau pavojaus signalas, gal reiktų su šia info elgtis atsargiau.
Komentarai turi naudingos informacijos. Net patys neišsamiausi komentarai, kurie nepateikia priežasčių, gali parodyti, kad kažkas su pateiktu sprendimu yra blogai.
Jei radai kokias nors nepažįstamas funkcijas, komandas, eik ir skaityk jų dokumentacijas. Šitas punktas papildo ankstesnį, tiesiog reikia aiškintis kol rastas sprendimas bus aiškus. Bus aišku kaip ir kodėl jis veikia.
# Aklas kopijavimas neveikia
Neveikia dėl labai paprastų priežasčių. Šitas priklauso nuo programavimo kalbos, bet galiu beveik garantuoti, kad rastas sprendimas parašytas kitokiu kodo stiliumi.
Ar nori turėti savo JavaScript'e kažkokį gabaliuką, katras atrodo kaip fanerinė plokštė įsprausta ten, kur turėtų būti galinis mašinos stiklas?
Rasti pavyzdžiai dažniausia neapgalvoja tavo softui keliamų unikalių reikalavimų: gal reikia palaikyti senas/keistas naršykles, gal pateikta tik nedidelė sprendimo dalis, gal atsakymas veikia tik su kažkokia papildoma biblioteka (kurios naudoti nenori/negali).
# Gūglinimas yra mokymosi proceso dalis
Pabaigai, kviečiu paskaityti postą apie mokymąsi kai prireikia. Gūglinimas ir ieškojimas sprendimo prieš akis iškilusiai problemai yra kaip tik šitai.
Just-In-Case vs. Just-In-Time Learning - štai jums postas, kurį galit skaityti, jei norit šią gūglinimo problemą researchinti giliau.
Nuo savęs tik noriu pridėti, kad Gūglas, Wikipedia, Quora, forumai, blogai, StackOverflow (ir spin-off'ai) kartu ir YouTube yra nuostabios vietos mokytis. Kombinuojant jas su tikro gyvenimo problemomis ir jų sprendimais galima išmokti beveik visko ko tik prireikia.
Būtina ir reikia googlinti net pasikartojančius dalykus. Tol kol tie dalykai pataps kasdienybe, įprastybe. Tada gūglinsim sudėtingesnius.
