Top 10 chýb začínajúceho programátora

Začínajúci programátori toho majú veľa spoločného. Či už je to chuť do niečoho nového, veľké plány do budúcna, alebo cieľ vybudovať svoju vysnívanú appku. Medzi týmito skvelými ambíciami majú spoločné aj úskalia samotného programovania.

Nasledujúci zoznam predstavuje 10 najčastejších a najvýznamnejších chýb. Chyby nie sú zoradené podľa závažnosti.

Chyby nebudeme len vymenovávať, ale ponúkneme aj riešenia či spôsoby, pomocou ktorých môžeme tieto chyby postupne odstrániť.

Na záver spomenieme jedným riadkom ďalšie chyby, ktoré sa už nedostali do zoznamu, avšak stále sú významné.
O tejto téme sme nahrali podcast.

Chaotické programovanie

Nesprávne odsadenie kódu, nekonzistentné používanie malých a veľkých písmen v premenných a v názvoch metód či chýbajúce bodkočiarky. A ešte k tomu nezrozumiteľný kód a nezmyselné pomenovanie premenných ako napr. ‘tmp‘. Všetci sme toho boli svedkami, či už sme si tým prešli sami, alebo sme to videli u iných.

Chaotické programovanie je jeden z najčastejších prejavov začínajúceho programátora. Je to úplne normálne. Nikto učený z neba nespadol. Človek však môže zmeniť svoju pozornosť a sústredenie na kód, ktorý píše. Dávať si pozor na odsadenie, na konzistentnosť veľkých a malých písmen. Písať kód radšej pomalšie.

Čo sa týka zmysluplných názvov metód a premien, tu môžu pomôcť princípy clean code. Jednotlivé princípy sme vysvetľovali v podcastoch a venovali sme sa aj spôsobom, ako ich môžeme uplatňovať.

Vyhýbanie sa debuggovaniu

Debuggovanie je vynikajúca pomôcka a neoddeliteľná súčasť programátorského repertoáru. Pomocou debuggovania si vieme odkrokovať program, prezerať si, kadiaľ nám skáče kód, a aké hodnoty majú naše premenné. Programátori často používajú tento tool na to, aby odhalili bug v programe.

Začínajúceho programátora môže vystrašiť, keď zapne debug režim a vidí všetky tie možnosti, čo môže stlačiť ako napr. F8 či F9. Všetkými desiatimi vám však odporúčame postaviť sa tomu a venovať debuggovaniu nejaký čas, aby ste vedeli ako sa tento tool používa, lebo na revanš vám to môže ušetriť veľa času v budúcnosti.

Začínajúci programátori zvyknú vypisovať do konzoly stavy premennej alebo iba pomocné slovíčka, aby vedeli, čo ich program urobil/neurobil. Robia to aj pokročilí programátori, avšak často to nemusí stačiť.

Kopírovanie kódu bez premýšľania

Každý používa internet, resp. stackoverflow na zisťovanie, čo sa ako robí. Často tam hľadáme aj riešenia na problémy, ktorým práve čelíme. Prescrollujeme na to, ktoré má najviac odpovedí, a skopírujeme ho do nášho programu.

Zamysleli sme sa však nad tým, čo skopírovaný kód robí? Ako rieši náš problém? Rozumieme tomu kódu? Nerobí náhodou aj niečo, čo nechceme? Tieto otázky by sme si mali položiť pred každým skopírovaním.

Je to dôležité najmä preto, aby sme sa pritom niečo nové naučili, ale aj nato, aby sme si daným kódom nezaviedli do nášho programu bug, ktorý budeme neskôr hľadať niekoľko hodín. Radšej si ten kód treba poriadne pozrieť a skopírovať ho až vtedy, keď vieme, čo robí každý jeden riadok.

Písanie kódu bez plánu

Často sa nám môže pri nejakých menších (možno aj väčších) programoch stať, že si jednoducho zapneme naše obľúbené IDEčko a začneme kódiť bez premýšľania. Či už je to zadanie do školy, alebo si skúšame nejakú programátorskú úlohu. To, samozrejme, nie je zlé; je to jednoznačne lepšie, ako keby sme to ani nezačali robiť.

No potom sa môžeme dostať do niekoľkých problémov:

• Môžeme sa v našom riešení zamotať, lebo na začiatku sme mali len malý náznak nápadu a neskôr sme riešenie menili, ako sme to cítili.
• Zistíme, že riešenie, s ktorým sme začali, nie je správne, tak ho prerábame, vyrábame špagety a motáme sa dokola.
• Po nejakom čase nám napadne, že sa to dá vlastne urobiť oveľa jednoduchšie, tak vymažeme celý kód a začneme odznova.
• Naše prvé riešenie je úspešné (to sa skoro nikdy nestáva).

Tento prístup má svoje výhody a určite aj veľa zástancov. Napriek tomu si myslíme, že sa to dá robiť lepšie.

Odporúčame sa pred problémom niekoľko minút (pokojne aj desiatky) poriadne zamyslieť nad spôsobom, akým vyriešime daný problém. Hoci nám môže prvé riešenie napadnúť hneď, pokračujme v rozmýšľaní. Nedá sa to urobiť jednoduchšie? Určite to takto dokážeme spraviť? V tejto fáze sa hodí papier a pero, robíme to aj my.

Príliš veľa energie a času venovanému výberu jazyka či frameworku, ktorý sa ideme naučiť

Začínajúci programátori to nemajú ľahké. Niežeby nebolo na internete dostatok informácií, ale je ich až priveľa. A nielen informácií, ale aj tutoriálov. Dobrých, zlých, krátkych a príliš dlhých. Keď sa človek rozhodne, ktorý jazyk sa ide naučiť, mal by si na to vybrať aj tutoriál.

Problém však nastáva, keď je človek z takého rozhodovania doslova paralyzovaný (analysis paralysis). Treba si uvedomiť, že výber programovacieho jazyka či frameworku nie je navždy. Najviac to platí pre prvý jazyk, ktorý sa začínajúci programátor ide učiť, lebo práve ten je najmenej dôležitý. Na druhej strane je dôležité naučiť sa koncepty, ktoré sú spoločné pre všetky jazyky, ako napr. premenné, funkcie, cykly, algoritmy. Tieto koncepty sú rovnaké pre skoro všetky jazyky a naučíme sa ich bez ohľadu na to, či začneme s Javou, Pythonom alebo C++.

Keď sa naučíme základné koncepty, môžeme skúšať hocijaké ďalšie jazyky.

S frameworkami je to takmer to isté. Začínajúci frontend programátor sa napríklad môže rozhodovať, či sa začne učiť React, Vue.js alebo Angular. Je to v podstate jedno, lebo framework sa ide naučiť preto, aby v ňom vedel niečo nakódiť, a nie preto, lebo s ním bude pracovať až dovtedy, kým si nenájde prácu, v ktorej by daný framework používal. Frameworky majú tiež podobné koncepty a ak ovládame jeden, oveľa jednoduchšie sa naučíme ďalší.

Ak riešenie funguje, netreba ho meniť

Tento bod celkom súvisí s písanie kódom bez plánu. Dajme tomu, že sme si ten plán predsa len nakreslili na papier a ideme programovať. Eventuálne sa nám podarí vytvoriť riešenie, ktoré funguje. Končí sa tu naša robota?

Hoci nám riešenie funguje, mali by sme sa zamyslieť nad tým, či sa nedá zlepšiť. Je veľmi malá pravdepodobnosť, že už nemôže byť lepšie. Mohlo by to byť jednoduchšie? Rýchlejšie? Na menej riadkov? Pochopiteľnejšie? Čistejšie?

Ak ti na tomto bude záležať, veríme, že sa staneš lepším programátorom. Aj keby malo ísť len o zadanie do školy.

Všetko sa učiť naraz

Ak si ako my, tak si sa tiež určite neraz našiel v situácii, že nevieš, čo sa máš skôr začať učiť. Chceš vedieť React? Vyvíjať mobilné appky? Cross-platformové appky pomocou flutter alebo react native? Chcel by si sa konečne naučiť C#? Alebo vyvíjať hry? Nie si sám.

Mať veľké ambície a chuť je dobré, ale učiť sa viacero vecí naraz už nie je. Dve veci naraz je možno ešte v pohode. Napríklad učiť sa frontendový aj backendový jazyk alebo sa učiť Unity framework (na vývoj hier) a vyvíjanie android appiek pomocou kotlinu. Odporúčame sa však učiť naraz jednu, maximálne dve nové technológie, lebo inak v tom budeš mať chaos.

Predstav si, že sa máš učiť nový jazyk, napr. angličtinu, nemčinu alebo čínštinu. Dokázal by si sa učiť všetky naraz? Ak áno, tak si mimoriadne nadaný a gratulujem, ale je veľká pravdepodobnosť, že táto snaha by bola veľmi neefektívna, lebo naučiť sa nový jazyk nie je nikdy jednoduché. Treba sa na to poriadne sústrediť a venovať tomu čo najviac času. S dvomi jazykmi naraz sa to ešte celkom dá, aj keď sa nám môžu začať miešať. Ale učiť sa tri, nebodaj viac, naraz, to už nie je veľmi reálne.

Naučiť sa programovacie jazyky a frameworky nie je až také ťažké ako naučiť sa po nemecky, ale podobá sa to tým, že sa nám môžu začať pliesť, budeme mať väčšie problémy so sústredím a v neposlednom rade nám zaberie veľa úsilia tzv. „context switching“, t.j. keď musíme prepnúť z jedného „sveta“ do druhého.

Neznalosť jazyka a knižníc, nesprávne používanie

Ďalšou veľmi častou chybou začínajúcich programátorov je nesprávne používanie balíčkov, ktoré nám ponúka daný programovací jazyk či knižnica.

Uvedieme príklad, ktorý je síce trošku dlhší, ale zato náučný. Ak sa ti ho nechce čítať, tak pokojne prejdi na ponaučenie z príbehu.

Zadanie:
Dajme tomu, že mám úlohu, v ktorej užívateľ píše do konzoly čísla (id) produktov, ktoré si chce kúpiť. Tieto čísla píše až dovtedy, kým nestlačí „q“. Keď konečne stlačí „q“, treba vypísať všetky produkty, ktoré si chce kúpiť.
Úlohu robíme v Jave.

Prvé riešenie. Neznalosť jazyka Java:
Najprv potrebujeme spôsob, akým budeme držať produkty s ich príslušným id. Ako prvé nám môže napadnúť vytvoriť list produktov, v ktorom máme toľko inštancií produktov, koľko ich je. Každý produkt by obsahoval aj premennú id. Ďalej by sme si vytvorili list, do ktorého by sme pridávali čísla produktov, ktoré užívateľ napísal do obrazovky. Keď konečne stlačí „q“, musia sa vypísať všetky produkty, ktoré si chce „kúpiť“. Treba však myslieť aj na to, že ak napísal viac ako jedenkrát číslo 3, tak produkt s týmto id vypíšeme iba raz. (Keď vám niekto 3x za sebou povie, že si chce kúpiť nový Playstation 5, neznamená to, že si ho chce kúpiť trikrát, ale že si ho chce fakt veľmi kúpiť :D).

V prvom rade potrebujeme získať unikátne čísla produktov. Vytvoríme si funkciu, ktorá má na vstupe list čísel a vráti list čísel bez duplikátov. Trocha sa potrápime, ale zvládneme to.

Ďalej môžeme začať vypisovať produkty. Začneme v cykle prechádzať čísla produktov. Pre každé číslo si prelistujeme všetky produkty, až kým nenájdeme ten, ktorý pasuje s aktuálnym číslom. Keď ho nájdeme, tak ho vypíšeme. A to je všetko.

Fungovali by toto riešenie? Fungovalo. Dalo by sa to urobiť lepšie? Samozrejme. Použili sme vhodné dátové štruktúry, ktoré nám Java ponúka? Vôbec.

Druhé riešenie. Využitie toho, čo nám Java ponúka:
Pre uloženie produktov budeme používať mapu, konkrétne HashMap, v ktorej kľúč je číslo (id) a hodnotou je produkt. Pre ukladanie čísiel produktov, ktoré si chce užívateľ kúpiť, budeme používať Set, čo je niečo ako list, ale nemá duplicitné elementy. To nám zaručí táto dátová štruktúra sama o sebe a teda nepotrebujeme vytvárať funkciu, ktorá nám odstráni duplicitné čísla produktov.

Keď teda užívateľ napíše „q“, potom nám stačí iba v cykle prejsť všetky čísla produktov zo setu a pre každé číslo nájsť obyčajným get príkazom z mapy (na základe čísla) daný produkt a vypísať ho.

Ponaučenie:
Ak nevieme, čo nám jazyk, framework alebo nejaká knižnica ponúka, ľahko sa môže stať, že budeme robiť niečo, čo sme vôbec nemuseli, a 3x dlhšie, lebo znova objavujeme koleso.

Ak sa učíte niečo nové, je fajn si o tom niečo naštudovať. Môžeme začať s „hello world“ tutoriálom, ale skôr či neskôr je dobré pozrieť sa na to, aké dátové štruktúry jazyk ponúka, zhliadnuť pokročilé tutoriály či poriadne si prečítať dokumentáciu.

Skúsenosti a čas nám v tomto ohľade pomáhajú najviac, no s lepšou znalosťou danej technológie budeme efektívnejší.

Vyhýbanie sa testom

Všetci sme niekde čítali a počuli, že kód treba testovať. Že by sme mali robiť tzv. unit testy. No, samozrejme, väčšina z nás na to zo začiatku úplne kašľala. Niektorí sa dokonca možno prvýkrát stretli s testami až v robote. Dúfam, že je to skôr ojedinelé.

Nie nadarmo sa to všade píše a lektori to opakujú. Testovanie je neoddeliteľnou súčasťou softvéru. A čím má byť softvér kvalitnejší, tým si vyžaduje viac testov.

Začínajúci programátori v tom nemusia hneď vidieť pridanú hodnotu. Ak píšu program, ktorý má 50 riadkov a cvičia si tým algoritmické myslenie, tak písať testy nie je ani zďaleka nevyhnutné. Napriek tomu by sme testy odporučili z viacerých dôvodov:

• Za predpokladu, že máte testy, ktoré správne testujú váš softvér (aj keby mal 50 riadkov), tak môžete kód refaktorovať bez toho, aby ste sa báli, že niečo pokazíte.
• Testy zlepšujú kvalitu kódu, lebo písanie testov vás donúti silnejšie rozmýšľať nad problémom.
• Nájdete bugy, o ktorých ste ani netušili.
• Kvôli nájdeným a následne opraveným bugom ušetríte veľa času, ktorý by ste minuli na debugovanie a hľadanie chyby.

Ak ste niekedy počuli o chuťovke so skratkou TDD (test driven development), vraj je to super. Nikdy som to nevyskúšal, ale aj tak si som istý, že sa tým môžete len zlepšiť.

Strach a vzdávanie sa

Posledný bod v tomto zozname je asi ten najdôležitejší. Nasledujúce vety sú venované všetkým, ktorí začínajú programovať, ale neveria vo vlastné schopnosti.

Milý/á programátor/ka, nevzdávaj sa. Nie si hlúpy/a. Treba len skúšať a dať tomu viac času. Nikto nespadol z neba s tým, že vedel hneď všetko. Niekomu to ide pomalšie, inému rýchlejšie, ale to je jedno. Porovnávanie tiež nie je dobrá vec, lebo sme z neho akurát tak smutní. Síce sa ním niekedy môžeme aj vyhecovať, ale treba si uvedomiť, že sa učíme kvôli sebe, a nie preto, aby sme machrovali pred ostatnými.

Ťažké momenty prídu, či už na vysokej škole, v prvej práci, alebo doma pri prvom tutoriáli na youtube. Ak sa niekedy začneš učiť novú vec a vôbec netušíš, o čo ide, je to v poriadku. Pozri si to ešte raz, dvakrát, trikrát. Prečítaj si o tom niečo, pozri si príklady. Postupne na to prídeš, som si istý.

Neboj sa nových vecí, ktoré vyzerajú strašidelne. Každá vec sa skladá z mnohých menších a ešte menších častí a tie sú samy o sebe jednoduché. Treba pochopiť celky, myšlienku a až potom ostatné detaily.

Chyby, ktoré sa nezmestili do zoznamu

• Nezálohovanie kódu, nepoužívanie source control.
• Používanie globálnych statických premenných.
• Posadnutosť „best practices“. Všade chcieť vložiť nejaký design pattern alebo za každú cenu nemať funkciu dlhšiu ako 4 riadky.
• Neskončiť projekt, keď už to nemá zmysel. Platí to vtedy, keď napríklad robíš nejakú appku, ktorá sa ti pôvodne zdala super, avšak v polke zistíš, že je to vlastne blbosť, ale chceš to dokončiť iba preto, lebo si tomu už venoval veľa času. Radšej začni niečo nové.
• Nesprávne googlenie, alebo negooglenie vôbec. Dobrý programátor vie nielen dobre kódiť, ale aj dobre googliť.
• Keď si myslíme, že už všetko vieme.
• Nevalidovanie vstupu od používateľa (platí viac pre frontend).
• Programovanie po slovensky. V kóde používame anglické výrazy. Čím skôr si začneš zvykať, tým lepšie.

Záver

Som si istý, že si sa spoznal minimálne v jednej chybe, či už si skúsený programátor alebo ešte iba začínaš. Je to úplne normálne a nie si sám/a.

Nezabudni na svojich chybách pracovať a zlepšovať sa. Teda samozrejme za predpokladu, že sa zlepšovať chceš. Keď už hovoríme o tom, ako sa môže programátor zlepšovať, aj o tom sme nahrali podcast.

Ak si myslíš, že sme na nejakú chybu zabudli, alebo s nami v niečom nesúhlasíš, pokojne nám napíš. Či už koment alebo email. Budeme radi.