Doporučené postupy v programování

# Otázka na úvod

<p class="center" style="margin-top: 2em; font-size: 1.5em;"><strong>Kam zařadit vývoj software?</strong></p>
        <br />
        <p class="fragment key-point" style="font-size: 1.5em;">Věda?</p>
        <p class="fragment key-point" style="font-size: 1.5em;">Řemeslo?</p>
        <p class="fragment key-point" style="font-size: 1.5em;">Umění?</p>

Notes:

- Věda, zvlášť v našem oboru, to je algebra, logika, diskrétní matematika, ..., teorie informace, atd. Věda, to je čistý svět jasných (jak pro koho) pravd, nevyvratitelných důkazů a (v našem případě) turingových strojů.
        - Cožpak věda nestačí? Zdá se že ne - jedna věc je něco vymyslet, druhá věc je něco realizovat. Matematická formule se nedá spustit ani nenajde článek na webu, stejně jako v projektu na barák se nedá bydlet. Takže vývoj software je také proces, jehož výsledkem je něco hmatatelného.
        - Cožpak věda a řemeslo nestačí? Co je to umění? Zajímavá je definice umění jako "dokumentace tisíce zajímavých rozhodnutí".
          - **dokumentace** ... dá se to sdílet s ostatními ...
          - **tisíce** ... mělo by v tom být vidět úsilí ...
          - **zajímavých rozhodnutí** ... sada rozhodnutí, které stojí za to zaznamenat ...
        - "The creation of art is not the fulfillment of a need but the creation of a need. The world never needed Beethoven's Fifth Symphony until he created it. Now we could not live without it." ~ Louis Kahn.
        - Umění poskytuje prostor pro kreativitu, intuici, estetiku, nápady přicházející znenadání a odnikud, nadšení a zápal. Existuje snaha některé aspekty formalizovat a přesunout je do kategorie "řemeslo". Na některé typy projektů to funguje, ale eliminovat esenci umění z programování asi nejde.

# Vývoj implikuje proces

## Vývoj software je jako...

- psaní (knihy, článku, dopisu)?
        - pěstování plodin?
        - pěstování ústřic (kvůli perlám)?
        - stavba (katedrály, rodinného domu, psí boudy)?
        - ...?

Notes:

- Psaní knihy je většinou individuální záležitost, kniha když se dopíše tak je hotová, při psaní knihy je důraz kladen na originalitu.
        - Při pěstování plodin se zasadí semena, vyrostou rostlinky, o ty se člověk stará až nakonec přinesou zasloužené plody.
        - Pěstování ústřic zachycuje růst a vývoj softwaru jako proces nabalování tenkých vrstev na nějaké malé jádro.
        - Představa "stavby" software se zdá užitečnější než představa jeho "psaní" nebo "pěstování". Je kompatibilní s tím, co naznačuje metafora "ústřičné farmy", ale navíc poměrně intuitivně implikuje potřebu různých fází plánování, příprav, vlastní stavby, konečných úprav, inspekcí v průběhu a na závěr stavby, a koneckonců i údržby.
        - Další podobnosti: projekt, schválení projektu, příprava stavby, základy, hrubá stavba, zastřešení, vnitřní rozvody, omítky, malování, vnitřní vybavení, zahrada. Ale také např. náročnost a cena změn prováděných během stavby, jako třeba posunutí zdi.
        - Stavební metafora navíc škáluje s velikostí projektů. Jinak se připravuje stavba rodinného domu, stadionu pro 50000 lidí, katedrály, nebo psí boudy. S rostoucí složitostí vyniká potřeba vyšší míry organizace a roste závažnost důsledků špatného plánování. A konečně, u stavby je prostor i pro umění.

# O čem bude tento předmět?

## O vývoji software...

# O čem bude tento předmět?

## ... a zejména o aktivitách, které se týkají programování ...

# O čem bude tento předmět?

## ... tedy o psaní kódu a souvisejících činnostech.

# Jak to souvisí s vámi?

## Programování ve škole

- **složité** problémy v **jednoduchém** kontextu
        - důraz na vědecký/matematický aspekt izolovaných problémů
        - kvalita návrhu, čistota kódu a jiné řemeslné aspekty často vedlejší (až na výjimky)

## Programování ve firmě

- **jednoduché** problémy ve **složitém** kontextu
        - v horším případě **složité** problémy ve **složitém** kontextu
        - důraz na funkčnost, udržovatelnost, a včasné dodání

</div>
        <div class="fragment">

## Důsledkem jsou

- problémy při realizaci složitějších projektů (semestrálky, diplomky)
        - potenciální ekonomické ztráty

</div>

Notes:

- Za výstižný postřeh ohledně rozdílu mezi programováním ve škole a v průmyslu vděčím T. Pochovi.
        - Problémy např. na OS – semestrálky přes 5KLOC, neznámé prostředí, velký rozsah abstrakcí.
        - Umělecký aspekt si musí najít každý sám.

# Jak vypadá špatný kód?

## "Routine from hell"

```cpp stretch small
        void HandleStuff( CORP_DATA & inputRec, int crntQtr,
           EMP_DATA empRec, double & estimRevenue, double ytdRevenue,
           int screenX, int screenY, COLOR_TYPE & newColor,
           COLOR_TYPE & prevColor, StatusType & status, int expenseType )
        {

int i;
        for ( i = 0; i < 100; i++ ) {
           inputRec.revenue[i] = 0;
           inputRec.expense[i] = corpExpense[ crntQtr ][ i ];
           }
        UpdateCorpDatabase( empRec );
        estimRevenue = ytdRevenue * 4.0 / (double) crntQtr;
        newColor = prevColor;
        status = SUCCESS;

if ( expenseType == 1 ) {
             for ( i = 0; i < 12; i++ )
                   profit[i] = revenue[i] - expense.type1[i];
             }
        else if ( expenseType == 2 ) {
                  profit[i] = revenue[i] - expense.type2[i];
                  }

else if ( expenseType == 3 )
                  profit[i] = revenue[i] - expense.type3[i];
                  }
        ```

</div>

# "Routine from hell"

## Jak na vás příklad působí?

- nutkání konat násilné činy (na autorovi)... 
        - kód nic moc, ale to je život, s tím se nedá nic dělat...
        - normálka, nechápu proč je kolem toho takový povyk ...

## Jak špatný ten kód byl?

- dalo by se na něm najít alespoň 15 vad
        - od formátování, přes názvy proměných a číselné konstanty, počet a
          uspořádání parametrů, až po fakt, že dělá řadu věcí, které spolu
          nesouvisí

</div>

Notes:

- Co se stane, když tento kód vložíte do ChatGPT s prosbou o refaktoring?
          - Model pravděpodobně začne hádat význam proměnných na základě běžných vzorů, čímž může nepozorovaně změnit logiku.
          - Mohl by třeba předpokládat, že `crntQtr` bude nabývat hodnot 1-4 (a dělí se jím), ale zároveň se používá jako index do pole, kde se spíše dají očekávat hodnoty 0-3.
        - Špatný kód se pomoci AI aktivně brání, [případně mu není pomoci](https://chatgpt.com/share/69936ff6-e2b8-8003-8ba4-3530bf6daabb).
        - Nástroje pro AI refaktoring není vhodné používat na kód, kterému fundamentálně nerozumíte.

# Proč ..., když mi ho vygeneruje AI?

## Posun role: autor → editor & auditor

- Generování kódu je levné, **porozumění** je drahé
        - Ověření správnosti vyžaduje vyšší senioritu než jeho napsání
        - Nepřehledný (spaghetti) kód se nedá efektivně auditovat

## Kód je "prompt" pro další generování

- LLM používá váš stávající kód jako kontext a přizpůsobuje mu výstup
        - **Garbage In, Garbage Out**: nekonzistentní kód AI mate

## AI má (také) omezený kontext

- Kvalitní abstrakce komprimuje informace
        - Špatný kód znečišťuje kontext modelu

Notes:

- S nástupem AI čitelnost kódu neztratila na důležitosti: s AI
          nástroji můžete sice extrémně rychle produkovat kód, ale také
          extrémně rychle akumulovat technologický dluh.
        - Velkým jazykovým modelům se nejlépe pracuje s modulárním kódem
          a dobrou abstrakcí — dobrá abstrakce komprimuje informace.
        - Role programátora se posouvá k review a designu. Pokud nemáte
          jasně pojmenované proměnné a oddělené funkce, nemůžete
          vygenerovanému kódu věřit.
          - Psaní kódu má kognitivní "složitost" O(N).
          - Čtení/ladění cizího kódu má "složitost" O(N^2) (rekonstrukce
            modelu, nutnost zvažovat interakce).
          - Rychlé vygenerování fungujícího, ale nepřehledného kódu pomocí
            AI tak může být jen **zdánlivá úspora**.

# Inherentní vs. zavlečená složitost

## Inherentní složitost (essential complexity)

- vlastnosti, které nějaká věc musí mít, aby byla tou věcí
        - vychází z podstaty daného problému, nelze odstranit

</div>
        <div class="fragment">

## Zavlečená složitost (accidental complexity)

- vlastnosti, které věc má, ale nedefinují ji (dáno řešením, ne problémem)
        - dlouhodobě se snažíme o její eliminaci (jazyk, správa paměti, formátování)

</div>
        <div class="fragment">

## AI jako zesilovač složitosti

- AI odstraňuje bariéru psaní ("friction of typing")
        - Umožňuje generovat zavlečenou složitost rychlostí blesku
        - Programátor jako kurátor/strážce architektury a kódu

</div>

Notes:

- AI funguje jako zesilovač složitosti. Tím, že odstraňuje fyzickou
          bariéru a zdržení spojené s pouhým psaním textu, umožňuje velmi
          rychle generovat obrovské množství "boilerplate" kódu — udělat
          z projektu "Big Ball of Mud" vám nezabere 10 měsíců, ale 10 dnů.
        - Role programátora se posouvá více do role kurátora/strážce
          architektury, čistého designu a čistého kódu, jehož úkolem je
          zajistit, aby AI asistenti nezaplavili projekt nepřehledným balastem.