Final Code Review Instructions

Deadline: Pondeli 17/01/2022 - 11:30:00

Jsou 3 zakladni hodnotici kriteria (od nejdulezitejsich k mene dulezitym):

1. Celkova citelnost, prehlednost a srozumitelnost kodu

Priklady problemu v kodu z minulych let:

Duplicita kodu

Plati hlavne u stylovani komponent:

• napr. kdyby se vsude pouzivalo <button class="button" /> je to duplicita kodu (znalost o tom, jake classy potrebuje spravne nastylovany button se rozleze po cele aplikace - v budoucnu by to bylo tezke zmenit)

  • spravne reseni je vytvorit komponentu <Button />, ktera tuto znalost zapouzdri (kdyz budu chtit modifikovat vzhled, tak to upravim v jednom souboru a vsude se to spravne projevi)

• obdobne to plati i pro:

  • CSS-in-JS (styled components a podobne): jestli si kazda stranka vytvari svoje verze komponent pomoci copy&paste, tak je to problem
  • UI knihovny (Material Desing a podobne): jestli se ve vetsine kodu pouziva napr. button se stejnou variantou a velikosti (<Button variant="outlined" size="small" />)
  • (v obou pripadech je lepsi vytvorit svuj "atom", ktery bude nastavovat zakladni hodnoty s moznosti je prepsat)
  • vyjimku tvori layoutovaci styly/classy (jako margin, padding, flex atd.)
    • jejich poziti napric aplikcaci se asi neda vyhnout

• cilem vetsiny aplikaci by melo byt vytvorit si vlastni design system

  • pro aplikace stavene na UI knihovnach to nemusi platit v casti "atoms",
  • ale nejake "melocules" a "organisms" atd. specificke pro danou aplikaci by v design systemu mely byt

Poznamka: casto tu zminujeme "atoms"/"molecules"/"organisms" - neni tim mysleno to, ze musite pouzivat Atomic Design - spis jsou tim mysleny ruzne druhy/velikosti komponent. To jak je projekt strukturovan je na vas (jen je potreba aby to bylo nejak srozumitelne a prehledne).

Megakomponenty

Sobor s komponentou ma vic jak zhruba 200 radku.

Megakomponenty jsou casto ty komponenty, ktere resi styly, layout, logiku a obsah zaroven. Komponentak by idealne mela resit jen jednu z techto veci:

• styly: "atoms" / design system
• layout: "molecules" / "organisms" / "templates"
• logika: "pages" (nekdy i "organisms")
• (open neni potreba dorzovat nazvoslovi Atomic Design, ale je potreba kod prehledne clenit)

Pravidlo s 200 radky neni striktni. Jestli bude kod prehledny, tak muze mit i vic radku. Prikadem vyjimek muze byt, napr.:

• soubor obsahuje hodne statickych textu (homepage, about us, atd.)
  • je ale dobre aby kazda cast neobsahovala hromady stylu nebo "atomu"
  • stranka by mela stavet hlavne na "molecules"/"organisms" jako <Feature title="..">...</Feature> <Hero img="..">...</Hero>
  • i velkou homepage lze rozbit na mensi casti:
• velky formular s hodne fieldy
  • podobne jako v predchozi casti, jestli se v ramci souboru vsude vyskytuje <label />, <input />, <ErrorMessage /> a napojeni na Formik, tak je lepsi vytvorit neco jako FormikField v Qackeru, ktery to vse zapouzdri (tady je kod FormikField a Field)

Nekonzistentni Formatovani Kodu

• z velke casti citelnost kodu ovlivnuje i formatovani (odsazeni, zalamovani radku, atd.)
• frontend i backend by kazdy mel mit jeden zpusob formatovani napric celym kodem
  • pripadne muze byt i stejny zpusob pro frontend a backend
• nejjednodussi je na kod pustit Prettier 😉

2. Zakladni README.md soubory pro frontend i backend

• jednoduchy popis toho jak spustit lokalni prostredi a co vsechno je potreba nastavit (napr. v .env souborech, jak naseedovat databazi atd.)
• opravdu staci strucne 😉
• priklad README.md

3. ESLint

• frontend by nemel hlasit zahne ESLint errory/warningy

Final Note

• jestli mate novejsi cast codebase v lepsim stavu, nez zbytek, tak mi dejte vedet do chatu kde ji najdu, mate tak moznost ziskat trochu lepsi hodnoceni