Vlákno názorů k článku Cibulová architektura aneb jak nepřipravovat špagety od anonym - Dobrý den, podle příspěvků se zde sešla řada zkušených...

Dobrý den,
podle příspěvků se zde sešla řada zkušených programátorů. Já toho využiju a zeptám se takto do pléna na radu.
Jsem odborností strojař a v rámci svého působení se učím programovat v Pythonu. Pokud rozlišujete kodery a programátory, pak jsem zatím koderem. Používám OOP a učím se postupně data structures a design patterns. Dosud jsem psal převážně jednoúčelové skripty, kdy jsem nic moc nepotřeboval. Našel jsem si příslušnou knihovnu, udělal pár tříd a bylo hotovo. Můj "interface" s kolegy je převážně nějaký textový soubor s daty a výsledky.
Začínám ale pracovat na větší aplikaci a rád bych se naučil, jak to dělat dobře. Tedy jaké jsou best practises v oblasti architektury. Hledal jsem na to nějakou knihu, která by mě uvedla do tématu, ale našel jsem pouze tuto: amzn.to/2tbgE3s a nejsem si jistý, jestli je to, co hledám.
Rád bych se proto obrátil na Vás - zkušené programátory, zda byste mě mohli odkázat správným směrem. Hledám tedy něco, od čeho bych se mohl odpíchnout při programování své první větší aplikace. Nerad používám čistě přístup pokus-omyl. Raději si o problematice nejdříve něco nastuduju, abych věděl, co vlastně dělám. Zároveň aplikaci nechci jenom nějak zbastlit, ale rád bych u toho pochopil všechny důležité principy a jako výsledek dostal kvalitní aplikaci, se kterou půjde dál pracovat. Vůbec mi nevyhovují online kurzy, nejlépe se mi učí z knih, či online textů (které si můžu vytisknout).
Pokud tedy víte o knihách, článcích, skriptech nebo přednáškách, které by mi v tomto smyslu pomohly, budu velice rád, když se o ně podělíte.

Často tady u článků čtu "nářky" nad (ne)kvalitou začínajích programátorů. Rád bych se z této množiny posunul někam dále. Berte to tedy i tak, že teď máte možnost někoho popostrčit správným směrem.
Kdyby byl někdo ochotný k příležitostnému mentoringu/code review, byl bych velmi vděčný.

Snad to není příspěvěk zcela mimo, případně se omlouvám.
PS: a.jelinek zavinac pm.me

Obavam sa ze ak sa chystate robit vacsiu aplikaciu v Pythone caka vas prepis.

To jsi mu fakt poradil.

??? Jak to mám chápat?

Několik základních rad (vycházím ze zkušenosti):

1. Než začneš psát, zkus si základní věci rozvrhnout na papíře
2. Nenech se svést ke zneužívání jednoduchých datových struktur. Žádný dict dictů dictů v situacích, kde je struktura dat pevně daná a známá - hezky to zabal do tříd s konstruktory apod.
3. Používej srozumitelné identifikátory tříd, proměnných apod. Ušetřené písmenko fakt v těchto situacích nestojí za to.
4. Jednotlivé stavební bloky dělej co nejsamostatnější, nemíchej jednotlivé vrstvy mezi sebou a to ani v komentářích - nepiš do funkcí a metod, kdo je používá a proč.
5. Nesnaž se vynalézat kolo; pokud existuje stabilní použitelná knihovna, používej ji.
6. Nauč se dobře pracovat s nástroji typu pylint a vyjdi jim vstříc - pokud danému kódu pylint nerozumí a píše chyby, zkus to napsat jinak.
7. Nepiš nic, co nepotřebuješ. Soustřeď se na funkčnost, která je pro aplikaci nezbytná.
8. Zkus si časem nastudovat jiná paradigmata, zejména funkcionální programování. Otevře Ti to oči.
9. Nauč se porozumět složitosti algoritmů, ať se nezabýváš mikrooptimali­zacemi, které nic podstatného nespraví.
10. Pořád se snaž zlepšovat svoje postupy a nástroje. Co můžeš, zautomatizuj.

Příručka Ti možná pomůže, ale je potřeba si udělat pořádek v hlavě a přemýšlet nad vším samostatně a kriticky. Zároveň nezůstávat v zóně komfortu.

26. 1. 2020, 12:43 editováno autorem komentáře

k bodu 3.
Moc to neprehanej protoze nazvy KeyManagerSer­visniUnitTestMo­dul a KeyManagerSer­visniUnitRunMo­dul se fakt tezko rozlisuju.

Dlouhy nemusi znamenat srozumitelny a naopak. Tohle je doufam jasne.

Za mě doporučím určitě se podívat na prvních 6 částí Clean Coders. Je to o tom jak strukturovat kód a pak unit testy. https://cleancoders.com/videos?series=clean-code&subseries=fundamentals .

Jak už bylo zmiňováno SOLID principy, tedy kniha Clean Code.
Problém je v tom, že člověk přečte knihu a nespojí si všechny věci dohrami a až na základě zkušeností si začne uvědomovat, co kdy platí za jakých podmínek. Kdy co dodržovat a kdy je to hovadina.
Nevýhodou je, SOLID a Clean Code je částečně i dost záplata na to jak špatné je OOP a jakou komplexnost a problémy generuje. Navíc mi příjde, že Clean Code dost prosazuje OOP a nedává do kontextu s Funkcionálním programováním. Navíc je v mnoha věcech dost fanatický.
Problém SW Engineeringu je právě v tom, že se v čase dost vyvíjel a prosazovali se často věci od kterých se postupně upustilo. Takže dosud nevím o nějakém materiálu o kterém by se dalo říct: ''Tohle přečteš a seš dobrý programátor". Skutečnost je spíš taková, že člověk se musí prohrabat spoustu nesmyslama, aby přišel k něčemu dobrému. (IMHO jako tento článek)

Další věc je, že se často nevyplatí o věcech dlouho teoretizovat a jít do toho. Jak se říká "Nejlepší analýza je implementace". Tedy je lepší něco zkusit, ale mít poté možnost to dobře refaktorovat a měnit, když je to nesmysl. A na to, aby se to dalo dobře měnit potřebuješ něco z 6 částí Clean Coders. A přece jen jsme lidi a produktivita se odvíjí hodně od toho jak to člověka bavý. Zmého pohledu je zábavnější psát kód něž neco dokola analyzovat (něco čeho se také týká sOlid - Open-Closed principle).

Dostal jste tu spoustu dobrých rad, tak jen doplním ještě navíc:
* napoprvé se to nepovede, zbastlíte to a za 5 let si budete rvát vlasy, co jste to spáchal. Je to normální. Nenechte se tím odradit. Načíst se dá jen omezená množina věcí, zbytek je o zkušenosti. Zkušenost se dá nabýt od zkušených kolegů a dobrých vyučujících na VŠ. Pokud ani jedno nemáte, nezbývá Vám, než si tu zkušenost udělat sám.
* rozvrhněte systém od shora (velké logické celky, procesy, komponenty - věci které z podstaty věci patří k sobě) dolů (konkrétní moduly/třídy/fun­kce). Nedjřív myslete z pohledu uživatele, zákazníka. A až když jste si jistý, že víte co se po vás chce se zamyslete nad tím, jak by se to dalo naprogramovat.
* nebuďte líný psát automatické testy, je to opruz skoro pro každého, ale alternativa bez nich je strašná
* kdykoliv budete mít potřebu vzít kus kódu a rozkopírovat ho na víc míst, zastavte se, zamyslete a zjistěte kde vám chybí třída/metoda/funkce :)
* komentujte i zřejmé věci, API, atributy, ne zcela triviální algoritmy
* přehlednost a standardizace jsou důležitější než cool-factor, pokud je projekt větší než triviální a životnost delší než krátká (pokud tedy neděláte něco tak nového, že na to standardní řešení nestačí, ale to je jiná story). Používejte ozkoušené knihovny, technologie, principy
* pokud přejímáte řešení problému ze stack overflow či blogu, buďte si nejdřív jistý, že chápete co přesně to do detailu dělá, jinak si koledujete o problémy (výkonostní, bezpečnostní).

Přidám ještě pár připomínek k předchozím. Přijde mi z toho dotazu, že očekáváš, že po nastudování dostatečného množství knih a pouček sedneš a napíšeš dobrou aplikaci. Obávám se, že tak to nefunguje. Jednak principy se časem (trochu) mění, druhak během implementace ani nepoznáš, že jsi něco nedodržel nebo zbastlil. To se ukáže až časem, kdy to budeš potřebovat rozšířit a implementovat nové požadavky atd.

Naštěstí SW umožňuje aplikaci libovolně předělávat a považuju za jednu z klíčových dovedností toto využít. Vychází to z agilních praktik, extrémního programování a konkrétně jde o to, aby se programátor nebál nedělat nic navíc (i když ví, že to řešení časem nebude stačit) a následně to vylepšil když to stačit přestane.

Kolikrát vidim, že se na začátku projektu rozhodne technologie, architektura atd. Následně se to implementuje, přičemž se řeší hromada složitostí, aby to bylo připraveno na budoucnost (která ale bude stejně jiná než kdo čekal) a přitom se nemění architektura ačkoli už dávno nevyhovuje současnosti.

Není nic špatného když si něco nastuduješ, ale zároveň se neboj pustit do prototypů a průběžných předělávek když jsou potřeba.