Hlavní navigace

Názor k článku Sčítání.cz: jak to příště zvládnout lépe aneb úvahy o dnešním IT od Adam Kalisz - Co je podle Vás architektura OO? Upřímně řečeno, to...

  • Článek je starý, nové názory již nelze přidávat.
  • 7. 4. 2021 14:04

    Adam Kalisz

    Co je podle Vás architektura OO?

    Upřímně řečeno, to Vámi proklamované formální vzdělání, kterého mám já a kolegové skutečně kupu nás nedovedlo k nějakému valnému mínění o objektově orientovaném programování obecně. Typicky se tam vyučují věci (dědičnost), které jinde (třeba v Googlu) už radši zakázali, protože to byl typický zdroj chyb/ problematického kódu.
    Obecně OO svádí k tomu, psát vlastně takový pseudojazyk jen pro ten konkrétní problém a zatemňovat tím řešení, kde jde v podstatě o relativně přímočarou transformaci strukturovaných dat.
    Neřekl bych to lépe: https://www.youtube.com/watch?v=aSEQfqNYNAc

    Jinak můj kolega udělal docela užitečnou OrgStránku o Clojure, kde je podobných postřehů více: https://www.orgpad.com/o/D6TrZny7tNhYqWygzax7Wx

    Problém programování fakt není, že by někdo neuměl napsat algoritmus na vyhledávání, který už mnohem lépe a robustněji naimplementoval někdo jiný a já to můžu využít. Problém je, že máte fakt debilní API, které je naimplementované typicky chybně a v dokumentaci, pokud existuje, tohle není. Spousta věcí je zbytečně složitá. Třeba history API v prohlížeči už lže v podstatě v názvu. S historií to nemá nic společného, protože na seznam navštívených stránek se tím fakt nedostanete, můžete ale upravovat současnost (přidávat nový záznam nebo měnit ten současný) nebo přidat reakce na nějakou změnu - obojí z mého hlediska není historie. Kdyby Vám prohlížeč radši dal upravitelný (JSON) array popisujících stavy historie, které se třeba aspoň vztahují k současné doméně (kvůli soukromí), tak by se s tím pracovalo mnohem lépe. Nikdo by nemusel programovat a udržovat v podstatě žádné API. Byl by to efektivně jen get/ set, když teda přemýšlíme v OO. (Nebo třeba @/ reset!/ swap! v Clojure - kde by se tohle řešilo nejspíš přes atom, který by obsahoval vektor map, tedy posloupnost stavů.)
    Na backendu jsou zase jiné špeky, třeba jenom úžasná komplexita TLS/ X.509 a neustálý příval chyb jenom v implementacích ne-li použitích. (Mimochodem M.W.Lucasovi vyšla nová praktická kniha TLS Mastery: https://mwl.io/nonfiction/networking#tls která by toto téma mohla stravitelně osvětlit do hloubky.)

    No prostě programování v reálu je fakt mnohem méně o algoritmech a strukturách než jak se to prezentuje. Ve spoustě případů je to spíše takové sado maso v trpění různých rozhraní a protokolů, které zůstaly na půl cesty a nebo se radši neměly nikdy vytvořit. Váš příklad "pouzijeme sql nebo se tady bude hodit specializovany fts software?" je přesně to, co už není programování podle Vašeho popisu "algo/data a neumeli ani architekturu OO", ale návrh/ architektura systému.

    Mimochodem, řešení našeptávače tak, aby obsloužilo současných např. 200 000 spojení fakt není typický příklad z datových struktur a algoritmů na vysoké škole ani nikde jinde. Typicky totiž ani sám vyučující neví (možná ale tuší), jak by tohle řešil.