TDD, DDD a Microservices - zajímá to českého programátora? rubrika: Programování: Jiné

4 meetvashek
položil/-a 7.4. 18:26

Ahoj všichni. Jsem tu nový a tak jsem zkoušel najít to co mě bere teď ze všeho nejvíc: Test Driven Development (TDD), Domain Driven Design (DDD) a architektura nazývaná "microservices". Nejmladší příspěvky na toto téma jsou rok staré a žádná větší diskuse o tom, co je v oněch zmíněných knihách: DDD od Erica Evanse, Clean Code od Roberta C. Martina? Praktické postřehy? Je o tohle téma tady zájem?

odkaz
8 Tomáš Tintěra
odpověděl/-a 11.4. 8:02

K TDD se tolik nediskutuje:

  • Jak předeslali ostatní, protože diskuse už proběhla a je to v učebnicích a hype je jinde.
  • Protože stávající code base většiny starých velkých projektů je obtížně testovatelná.
  • Protože pokrýt testy stávající codebase by byl herkulovský úkol.

Aktuální zkušenosti:
U jazyků, které jsou blíže HW je to s TDD trochu jiné:

  • Netvořím jen "běžnou" aplikační logiku, která by se dobře testovala.
  • Nikdy nemůžu otestovat všechny možnosti. Kód je často skutečně multiplatformní. To že test prochází neznamená, že bude chodit s jiným a na jiném OS. (Naše CI mám 4 kompilátory na 2 OS).
  • U mutithreadingu je také těch kombinací kombinačně moc. Správnou funkčnost nelze ověřit jen testy.
  • Nejúčinnější prevencí bugú je lépe používat nedávnými lety ověřené vzory a vyhýbat se zastaralým a nebezpečným postupům. Tedy tu správnou podmnožinu jazyka.
  • Druhé nejúčinnější mi přijde poctivé code review.
  • Řadu testů za vás de facto udělá kvalitní statická analýza. (Ne typová kontrola, ale samostatný nástroj, třeba Cppcheck, v MSVC je také dobrá.)
  • Víme, že nikdy nemůžete otestovat všechny možnosti.

  • TDD také význam u klasických GUI aplikací tvořených třeba nad Qt. Protože nejvíce bugů je z nesprávného použití nějakého prvku. Čili je třeba číst, pochopit a znát dokumentaci.

Takže testy tvořím, kde se dá. A šetří mi dost práce. Ale k čistému TDD má moje praxe daleko.

Komentáře

  • harrison314 : Mam to podobne, som v domene, kde sa mnoho veci neda jednoducho odtetovat unit testami, preto sa casto treba vynajst inak. 11.4. 9:33
  • Taco : V čem vidíš odlišnost mezi typovou kontrolou (principielně, beru v potaz, že cpp, java a spol má typy nedostatečné) a samostatným nástrojem? 11.4. 13:07
  • harrison314 : @taco: samotne nastroje kontrolju spravne pouzitie API, napriklad to ci zatvaras stream, ci nevolas nieco na objekte, ktory si pred troma riadkami nastavil na null, ci pouzivas bezpecne verzie API, ci dodrzivas nejake konvencie napr: https://www.sonarsource.com/products/codeanalyzers/sonarcsharp.html 11.4. 13:15
  • Taco : @harrison314: csharp má typy stejně na houby jako java. Takže je to jen o nekvalitě typového systému toho kterého jazyka? Chci říct, že to co popisuješ jsou určitě užitečné věci, ale nevidím v tom ten principielní rozdíl. Ale když to jazyk neumí, tak neumí - to chápu. Takže se jen ujištuji. 11.4. 19:57
  • harrison314 : @Taco: v com je typovy system C# "na houby"? Nevidis rozdiel medzi syntaxov a API, medzi jazykom a mennymi konvenciami, medzi "sprintf" a "sprintf_s"? 11.4. 22:15
  • Kit : @harrison314: Pokud do proměnné určené pro hmotnost v kilogramech můžeš uložit délku v metrech, tak je to typový systém na houby. 11.4. 22:43
  • Taco : @harrison314: Pokud ti přijde typový systém csharpu ok, tak máme rozdílné požadavky a akorád by z toho byla flamewar, to nechci. Když by @Tomáš Tintěra přispěl jak to myslel, a jinak za mě všechno. 12.4. 0:30
  • harrison314 : @Taco: tazko sa reaguje, ked si nanpisal nic konkretne. A ano pride mi v poriadku na to na co je urceny - je vybalansovany medzi praktickostou a akademickou cistotou, je OOP, umoznuje spravit velmi prisnu typovu kontrolu ale aj pouzivat dynamicke prvky. Nie je dokonaly, osobne si mylsim, ze by mohol niektore veci riesit viac, no na druhej strane nechcem aby bol preplneny vseliakymi okrajovimy featurami a divnymi operatormi. 12.4. 7:40
  • harrison314 : @Kit: suhlasim, este horsie je ked do premennej v ktorej je cislo vies vlozit string. 12.4. 7:41
  • Taco : @harrison314: nereaguj na csharp, ten mne nezajímá :) Jestli chceš, tak se rozepiš na co ten externí nástroj ještě používáš. Krom toho, co si již uvedl. 12.4. 12:25
  • Tomáš Tintěra : Lehce off-topic reakce na @Kit:V C++ můžeš mít typy na vlastní (například fyzikální) jednotky aniž by to jakkoli zpomalovalo program. A můžeš pak psát třeba 3.5_m ve významu 3.5 metru. Viz https://github.com/nholthaus/units. 12.4. 17:21
  • Tomáš Tintěra : Statická analýza například odhaluje nepoužívané proměnné. Nepoužívané metody a obecně mrtvý kód. Třeba když je v programu if, do kterého ovšem program nemůže nikdy vstoupit. Neboť od určité úrovně kvality a bezpečnosti není dovoleno v mít v programu jakýkoli mrtvý kód. 12.4. 17:26
  • Tomáš Tintěra : Statická analýza mi například nabízí, která proměnná může být const (jinde se tomu říká immutable). 12.4. 17:24
  • Tomáš Tintěra : Statická analýza mi odhalí, že program může za nějakých podmínek použít neinicializovanou proměnnou (Což konstatujme C++ umožňuje, aniž bych odbočoval k důvodům). 12.4. 17:29
  • Tomáš Tintěra : Statická analýza může zjistit, že program použije pro pole index mimo meze ještě před prvním spuštěním programu. 12.4. 17:29
  • Tomáš Tintěra : Řadu věcí zmínil harrison314 ve třetím komentáři z vrchu. Bezpečné API třeba u mne znamená mimo jiné: tohle bude ok fungovat ve tvém současném překladači, ale ne v jiných a nemá to oporu v normě. 12.4. 17:42
  • Tomáš Tintěra : Statická analýza může říci: Tyto metody a postupy nejsou dovolené používat pode bezpečností normy XYZ. (Například nemají plně deterministické chování). Což nevadí při objednávce Pizzy, takže překladač a framework je má, ale vadí když vyvíjíte řízení letadla. 12.4. 17:45
  • Tomáš Tintěra : Jeden neoblíbenějších nástrojů: http://cppcheck.sourceforge.net/ 12.4. 17:47
  • Tomáš Tintěra : Další věc, co testy přímo neřeší, ale jsou klíčové pro udržitelnou architekturu a jdou zjistit formou statické analýzy jsou závislosti. Třeba je dovoleno aby controlery používaly datovou vrstvu. Ale datová vrstva by neměla používat věci z GUI. To lze vysvětlovat, modlit se a kontrolovat ručně. A také kontrolovat automaticky například pomocí NDepend a CppDepend. 12.4. 17:51
  • Tomáš Tintěra : Těch kontrolovaných pravidel jsou tisíce. Každé má své zdůvodnění. Z toho se člověk může na praktických příkladech poučit, jak ten nástroj efektivně používat. 12.4. 18:06
  • ales.dana : @Kit: v tve aplikace se musi zadavat cisla s urcenim treba 1kg? to mi hlava nebere.... jak poznas, ze cislo 10 je kg nebo metry? 12.4. 22:58
  • Taco : @Tomáš Tintěra: Většina toho co jsi popisoval je IMHO spíše problém konkrétního jazyka (zkus porovnat cpp s rustem). Proto mě zajímaly konkrétní případy. Z toho co jsi vyjmenoval mě zaujali dvě: závsilosti datové vrstvy a gui, a volba úrovneň striktnosti. V každém případě díky za příspěvky. 13.4. 0:14
  • meetvashek : "Jak předeslali ostatní, protože diskuse už proběhla a je to v učebnicích a hype je jinde." - mě tu nejde o hype! Mě jde o sdílení praktických zkušeností, nebo aspoň za nahlédnutí za oponu. Díky za přínos do diskuze ale ptám se: jde opravdu jen o hype? Chápeš to jen jako hype? 13.4. 2:52
  • Kit : @ales.dana: Ve vstupním formuláři máš např. chlívek pro hmotnost. Hodnotu z něj (číslo) uložíš do proměnné typu kg. Pokud následně nějaká metoda má dva parametry, například hmotnost a délku, nemůžeš splést jejich pořadí - jinak kompilátor zahlásí chybu již při překladu. 13.4. 9:45
  • harrison314 : Dalsia vec co mozu robit analizery statickeho kodu: strazit kompatibilitu medzi platformami, menne a formatovacie konvencie, dokonca aj gramatiku... 13.4. 20:34
  • Tomáš Tintěra : @TACO. Zkus být konkrétnější. Pravda Rust jsem zatím viděl jen na jedné přednášce. A nevidím, že by mohl nedovolit více než jedenu z uvedených systémů. Ono zatím nebyl vymyšlen jazyk ve kterém by se nedalo prasit. Ať lidský nebo programovací. A berme v úvahu existující historický kód a obecně kód psaný s lidmi, kteří mají nedostatečnou profi praxi v daném jazyce. A rozsáhlé code bases, kde je chyby v komunikaci mezi lidmi nastávají. Když budu psát sám nový kód v C++ s použitím současných idiomů, tak se mi v několika měsíčním projektu uvedené chyby stát nemusí nebo ne moc často. Jenže jsou i větší code bases a a starší code bases. A také code bases, kde prostě ta chyba být nesmí. (Třeba ovládání dopravního letadla). 14.4. 9:47
  • Tomáš Tintěra : Třeba pole Rust má, a tak je možno sáhnout mimo. A budu rád, když mi to nářadí odhalí dříve bez debugování nebo pádu v produkci. https://doc.rust-lang.org/rust-by-example/primitives/array.html 14.4. 9:50
  • Taco : @Tomáš Tintěra: nevím, jak a v čem mám být konkrétnější. Psal si, že samostatný nástroj a ne typový systém. Což mne zaujalo. A jako realistovi mi bylo jasné, že mnohé tyto potřeby samostatného nástroje vyplývají z neschopnosti jazyka. Což je naprosto košer. Ale zajímalo mne, zda v tom není něco víc. ••• Jsou jazyky, které si hlídají formát. Jsou jazyky které nedovolí deadcode. Netuším, zda zrovna Rust umí hlídat meze polí, ale tak i kdyby ne, fajn. Nemáš tam něco dalšího? Není tvůj problém v tom, že to porovnáváš proti cpp, což je jazyk s dost omezenými typy? To pak jakejkoliv check vypadá jak zázrak :) 14.4. 11:40
  • Taco : @Tomáš Tintěra: zrovna mne poučovat o důležitosti včasné kontroly je jako učit britskou královnu angličtinu. 14.4. 11:43
  • Tomáš Tintěra : @Taco No píšeš, že Rust řeší ty věcí o kterých píši v tomto vlákně. Co konkrétně? Uvedl jsem pole jako věc, kterou Rust řeší podobně jako ostatní hlavní programovací jazyky. Píšeš že jsou nějaké nové nedovolující mrtvý kód. Ok. Tam je to v Rust provedeno lépe než co jsem znal dříve: https://doc.rust-lang.org/rust-by-example/attribute/unused.html. Const je v Rust řešen podobně. Co dále? 14.4. 18:09
  • Taco : @Tomáš Tintěra: No všechno ostatní, krom závsilosti datové vrstvy a gui, a volba úrovneň striktnosti. Mám pocit, že se to tu stáčí k obhajobě Rustu, což není téma které by mě zajímalo. No nic, i tak děkuji. 14.4. 21:15
  • Tomáš Tintěra : Ještě doplním k tomu samostatný tool vs součást kompilátoru. V současnosti vidím to, že IDE přímo používá statickou analýzu a její výsledky se mi zobrazují přímo v Editoru (ReShaper, Visual Studio 2019). Jen s mírným zpožděním. K důvodům rozdělení na dvě aplikace bude patřit právě výkon. 15.4. 15:51
  • harrison314 : @Tomáš Tintěra: nie len vykon, ale aj to, ze ked skaredym sposobom spadne tretostranny tool nezoberie zo sebou Visual Studio. 15.4. 16:09
  • Kit : @harrison314: Proč by měl pád toolu brát s sebou i VS? 15.4. 16:29
  • harrison314 : @Kit: segmentation fault (vyskusaj si robit nieco z HW alebo nativnimi kniznicami, ci cudzim kodom) 15.4. 19:15
  • Kit : @harrison314: Od čeho máme na procesorech Protected Mode? Když se ten tool spustí v odděleném paměťovém prostoru, tak přece to IDE shodit nemůže. Nebo snad ano? 15.4. 23:03

Pro zobrazení všech 6 odpovědí se prosím přihlaste:

Rychlé přihlášení přes sociální sítě:

Nebo se přihlaste jménem a heslem:

Zadejte prosím svou e-mailovou adresu.
Zadejte své heslo.