Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: Refactor 26. 12. 2017, 23:58:49
-
Ahoj,
zvládáte refactoring? Umíte ho? Jak jste se ho naučili? Jaké techniky používáte a jak se v něm zlepšujete? Co vaši kolegové? Ovládají ho?
-
Ptas se na spatne adrese, tady vsichni bastli spagety ve vimu.
-
Ptas se na spatne adrese, tady vsichni bastli spagety ve vimu.
A vy uz na Uralu 1 mate asembler nebo to porad pisete rovnou ve strojaku?
-
Koukám že spam boti už zvládají manipulativní marketing docela dobře (oni tomu ale říkají "kladení sugestivních otázek"). Ten příspěvek je jak z příručky.
-
Ptas se na spatne adrese, tady vsichni bastli spagety ve vimu.
A vy uz na Uralu 1 mate asembler nebo to porad pisete rovnou ve strojaku?
A vy zase bijete cernochy.
-
Vyborny. Takze k tematu opet nic. Tohle forum je k zbliti. Kam chodi normalni lide, co je bavi vyvoj a chteji se posouvat? Proc v zahranici mohou lide diskutovat a pomahat si a tady musi byt kazdej nejvetsi chytrak, ostatni oslovovat lopaty, fiktivne brat daleko pres kilo a pak mi na pohovoru na 80% banalnich otazek nedokazat odpovedet a ostatnim zamestnavatelum produkovat kod jako prase bez spetky studu?
-
Ptas se na spatne adrese, tady vsichni bastli spagety ve vimu.
A vy uz na Uralu 1 mate asembler nebo to porad pisete rovnou ve strojaku?
A vy zase bijete cernochy.
U nás žádné černochy nemáme, takže je bít nemusíme.
-
Vyborny. Takze k tematu opet nic. Tohle forum je k zbliti. Kam chodi normalni lide, co je bavi vyvoj a chteji se posouvat? Proc v zahranici mohou lide diskutovat a pomahat si a tady musi byt kazdej nejvetsi chytrak, ostatni oslovovat lopaty, fiktivne brat daleko pres kilo a pak mi na pohovoru na 80% banalnich otazek nedokazat odpovedet a ostatnim zamestnavatelum produkovat kod jako prase bez spetky studu?
Protože pokládáš hloupé a zbytečné otázky. V takovém případě nic než trolling nečekej.
Jestli máš konkrétní problém, tak se zeptej konkrétně, hoď sem třeba ukázku kódu a zeptej se, jak by to jiní přepsali. Na to relevantní odpovědi dostaneš.
-
Jak mi pomuze konkretni ukazka kodu k zodpovezeni na zacatku uvedenych otazek? Kdyby mi otazky pripadly zbytecne, neptal bych se na ne (Proc bych plytval casem?). Pokud nekomu pripadnou hloupe, at radsi neodpovida (vlakno skonci zapomenute). Kazdopadne i tak diky za reakci!
-
Vyborny. Takze k tematu opet nic. Tohle forum je k zbliti. Kam chodi normalni lide, co je bavi vyvoj a chteji se posouvat? Proc v zahranici mohou lide diskutovat a pomahat si a tady musi byt kazdej nejvetsi chytrak, ostatni oslovovat lopaty, fiktivne brat daleko pres kilo a pak mi na pohovoru na 80% banalnich otazek nedokazat odpovedet a ostatnim zamestnavatelum produkovat kod jako prase bez spetky studu?
To je náhodou dobrá otázka. Také marně hledám fórum pro vývojáře. Znám akorát devel.cz, které je zamčené a nejde tam psát a ani číst a jinak skoro nic. Dnes už fóra moc nefrčí.
-
Také marně hledám fórum pro vývojáře. Znám akorát devel.cz, které je zamčené a nejde tam psát a ani číst a jinak skoro nic. Dnes už fóra moc nefrčí.
Co je na devel.cz zamčeného? Jde tam číst i psát, ovšem pouze pro registrované. Zaregistrovat se může kdokoli.
-
Tak když tedy úplně obecně:
Smyslem refaktoringu je, aby se program navenek choval stejně a uvnitř jsme ho nějak vylepšili. Proto je nutným předpokladem mít možnost zkontrolovat, že se program chová navenek pořád stejně. Jinak je lepší na to radši nesahat. Chce to tedy mít automatické nebo aspoň poloautomatické testy – uložit si výstup z předchozí verze a porovnat s upravenou.
A pak už děláš ten vlastní refaktoring – a ten děláš z konkrétních pohnutek, např. máš pocit, že je něco špatně pojmenované, uspořádané, že by nějaké vnitřní rozhraní mělo být obecnější, aby šlo použít lépe v budoucnu atd. tak tam tyhle změny zapracováváš a průběžně kontroluješ, že jsi nic nerozbil.
Když nemáš, co vylepšovat, tak nemusíš refaktorovat.
-
Ahoj,
zvládáte refactoring? Umíte ho? Jak jste se ho naučili? Jaké techniky používáte a jak se v něm zlepšujete? Co vaši kolegové? Ovládají ho?
- Martin Fowler, Kent Beck: Refaktoring: Zlepšení existujícího kódu
- Robert C. Martin: Čistý kód
-
Také marně hledám fórum pro vývojáře. Znám akorát devel.cz, které je zamčené a nejde tam psát a ani číst a jinak skoro nic. Dnes už fóra moc nefrčí.
Co je na devel.cz zamčeného? Jde tam číst i psát, ovšem pouze pro registrované. Zaregistrovat se může kdokoli.
Devel.cz je mrtvý. Kromě místní partičky si tam nikdo nic nepřečte = je škoda tam psát. Ono už český web sám o sobě je dost malý, takže zužovat to ještě na nějakou menší skupinu je vyloženě hloupé. Jednoho dne to tam zavřou a ty odpovědi nezůstanou ani v cachi Googlu nebo WebArchivu.
Kultura upadá.
-
Také marně hledám fórum pro vývojáře. Znám akorát devel.cz, které je zamčené a nejde tam psát a ani číst a jinak skoro nic. Dnes už fóra moc nefrčí.
Co je na devel.cz zamčeného? Jde tam číst i psát, ovšem pouze pro registrované. Zaregistrovat se může kdokoli.
Registrace je pro lopaty. Alespoň čtení pro všechny, jinak ať jdou do hajzlu.
Také marně hledám fórum pro vývojáře. Znám akorát devel.cz, které je zamčené a nejde tam psát a ani číst a jinak skoro nic. Dnes už fóra moc nefrčí.
Co je na devel.cz zamčeného? Jde tam číst i psát, ovšem pouze pro registrované. Zaregistrovat se může kdokoli.
Devel.cz je mrtvý. Kromě místní partičky si tam nikdo nic nepřečte = je škoda tam psát. Ono už český web sám o sobě je dost malý, takže zužovat to ještě na nějakou menší skupinu je vyloženě hloupé. Jednoho dne to tam zavřou a ty odpovědi nezůstanou ani v cachi Googlu nebo WebArchivu.
Kultura upadá.
+1
-
............ a ty odpovědi nezůstanou ani v cachi Googlu nebo WebArchivu.
Proč by neměly zůstat ve WebArchivu, když tam se archivuje celý web? A nejen tam, dokonce i provoz na potřebnou dobu soustavně skladují nejmenované služby nejmenovaných mocností.
Refaktoring je výbornej hlavně na vkládání nejrůznějšího malicious SW, ale to málokdo napíše takhle přímo, protože se všichni bojíme jak po nás jdou BIS a jim podobní. Už s nima máte taky nějaké zkušenosti?
-
Ahoj,
zvládáte refactoring? Umíte ho? Jak jste se ho naučili? Jaké techniky používáte a jak se v něm zlepšujete? Co vaši kolegové? Ovládají ho?
- Martin Fowler, Kent Beck: Refaktoring: Zlepšení existujícího kódu
- Robert C. Martin: Čistý kód
+1
-
Refaktoring v mém oboru není nic moc.
- Lidi se nechtějí učit nové věci a spoustě programátorů je 40+,
- Razí se heslo, co funguje na to se nesahá,
- Unit testy je pro lidi v mém oboru sprosté slovo,
- OOP, satane odstup!
Já osobně se snažím učit nové věci, ať už v mém oboru, tak si programuji po večerech v jiných programovacích jazycích a to se pak člověk naučí jinak myslet. Bohužel však na refaktoring nechce nikdo moc slyšet, takže když se dostanu ke starýmu kódu, tak se na něj kouknu, jestli by se nedalo něco vylepšit a pokud ano, udělám to v rámci „nového požadavku“, protože to stejně budou muset uživatelé otestovat. Primárně se kouknu co kód dělá (píšu si poznámky do kódu) a pak se kouknu, jestli by to nešlo napsat efektivněji.
-
Ja sa snazim kod oddelovat do tried, helper tried, robit metody apod. Vo vela firmach refactoring neexistuje. Nedavno som dostal projekt, kde su asi 4 ci 5 ifov vnorenych a v danom ife je nejaka logika. Detto switch-case. Nie aby to hodili do metody.
-
............ a ty odpovědi nezůstanou ani v cachi Googlu nebo WebArchivu.
Proč by neměly zůstat ve WebArchivu, když tam se archivuje celý web?
Protože provozovatel toho serveru podmiňuje čtení odpovědí registrací – a Google i WebArchiv tam chodí bez registrace, takže smůla. Veřejná je maximálně jedna odpověď, ale všechny ostatní a komentáře jsou ztracené.
Co se týče tajných služeb – pro ně je ten web asi nezajímavý, takže taky nic – kdyby byl, tak by si tam účet založily a indexovaly to přes něj – ale pochybuji, že by ti pak poskytly data.
Nezabrušuj do takových oblastí, o kterých nic nevíš.
-
- Unit testy je pro lidi v mém oboru sprosté slovo,
Zrovna s refaktoringem ti jednotkové testy moc nepomohou, protože je musíš taky přepsat a tím ztrácíš jistotu, že program funguje stejně jako dřív – pokud jsi udělal chybu v kódu, pravděpodobně ji uděláš i při přepisování testu, protože vycházíš třeba z nějakých mylných předpokladů, jak se má program chovat a tu chybu zadrátuješ do kódu i do testu.
Pokud chceš refaktorovat trochu víc, než přejmenovávat lokální proměnné uvnitř metod nebo měnit odsazení, tak potřebuješ integrační/systémové testy, které ověří funkčnost celku.
-
- Unit testy je pro lidi v mém oboru sprosté slovo,
Zrovna s refaktoringem ti jednotkové testy moc nepomohou, protože je musíš taky přepsat a tím ztrácíš jistotu, že program funguje stejně jako dřív – pokud jsi udělal chybu v kódu, pravděpodobně ji uděláš i při přepisování testu, protože vycházíš třeba z nějakých mylných předpokladů, jak se má program chovat a tu chybu zadrátuješ do kódu i do testu.
Pokud chceš refaktorovat trochu víc, než přejmenovávat lokální proměnné uvnitř metod nebo měnit odsazení, tak potřebuješ integrační/systémové testy, které ověří funkčnost celku.
Během refaktorování se testy nemění. Právě testy by měly zaručovat, že se během refaktorování nezmění funkcionalita.
Jednotkové testy by měly mít vždy přednost před integračními a systémovými. Jsou totiž mnohem levnější.
-
- Unit testy je pro lidi v mém oboru sprosté slovo,
Zrovna s refaktoringem ti jednotkové testy moc nepomohou, protože je musíš taky přepsat a tím ztrácíš jistotu, že program funguje stejně jako dřív – pokud jsi udělal chybu v kódu, pravděpodobně ji uděláš i při přepisování testu, protože vycházíš třeba z nějakých mylných předpokladů, jak se má program chovat a tu chybu zadrátuješ do kódu i do testu.
Pokud chceš refaktorovat trochu víc, než přejmenovávat lokální proměnné uvnitř metod nebo měnit odsazení, tak potřebuješ integrační/systémové testy, které ověří funkčnost celku.
Unit testy su naviac proceduralne, vhodne na testovanie bezstavovych procedur. (Na OOP nevhodne) Komplexnejsie spravanie sa s tym komplikovane testuje, ze sa na to clovek radsej vykasle.
Osobne ich pouzivam presne na take procedury, kde viem, ze pre vstup A ma byt vystup B, uz mi to par krat zachranilo zadek.
-
Unit testy su naviac proceduralne, vhodne na testovanie bezstavovych procedur. (Na OOP nevhodne) Komplexnejsie spravanie sa s tym komplikovane testuje, ze sa na to clovek radsej vykasle.
Osobne ich pouzivam presne na take procedury, kde viem, ze pre vstup A ma byt vystup B, uz mi to par krat zachranilo zadek.
Unit testy se samozřejmě s výhodou používají i na OOP, protože se jimi dá testovat i stavové chování objektů. Kdyby se daly testovat jen bezstavové metody, byly by takto omezené testy k ničemu.
-
Během refaktorování se testy nemění. Právě testy by měly zaručovat, že se během refaktorování nezmění funkcionalita.
Pokud ten refaktoring není vyloženě triviální (přeformátování, přejmenování, změna algoritmu uvnitř jedné metody…) tak to má dopad i na jednotkové testy, které musíš přepsat – změna jde přes víc jednotek. Např. změníš vnitřní uspořádání – některé třídy přepíšeš, některé smažeš, jiné přidáš, upravíš vnitřní rozhraní… – ale navenek se program chová stejně a plní původní požadavky (což ohlídají ty integrační/systémové testy).
Jednotkové testy by měly mít vždy přednost před integračními a systémovými. Jsou totiž mnohem levnější.
Pokud to počítáš na kusy, tak asi ano. Ale co se týče poměru užitku a stráveného času, tak si to nemyslím. V praxi je problém v tom, že na úrovni jednotkových testů většinou nemáš tak dobře zpracované požadavky a specifikace, jako na úrovni vnějšího rozhraní. Takže si tu specifikaci vymýšlí víceméně za chodu programátoři, kteří píší jak kód, tak jednotkové testy – a pokud to vymyslí špatně, udělají chybu v kódu i v testech, všechno jim to svítí hezky zeleně, ale není to nic platné, protože specifikaci/požadavky to nesplňuje a zákazník jim to omlátí o hlavu.
-
Unit testy su naviac proceduralne, vhodne na testovanie bezstavovych procedur. (Na OOP nevhodne) Komplexnejsie spravanie sa s tym komplikovane testuje, ze sa na to clovek radsej vykasle.
Osobne ich pouzivam presne na take procedury, kde viem, ze pre vstup A ma byt vystup B, uz mi to par krat zachranilo zadek.
Unit testy se samozřejmě s výhodou používají i na OOP, protože se jimi dá testovat i stavové chování objektů. Kdyby se daly testovat jen bezstavové metody, byly by takto omezené testy k ničemu.
V tomhle souhlasím. Jednotkové testy a OOP k sobě patří a součástí jednotkového testu běžně je uvedení objektu do nějakého požadovaného stavu a následně provolání jeho metod a kontrola vrácených hodnot a výsledného stavu.
Potíž je spíš v tom, přesně vědět, co má být ten požadovaný a cílový stav a jak se mají konkrétní metody chovat. Často to nikde popsané není a lidé to mají jen v hlavě – na rozdíl od požadavků vnějšího rozhraní, které spíš bývají někde napsané a schválené.
-
Vyborny. Takze k tematu opet nic. Tohle forum je k zbliti.
Na blbou otázku blbá odpověď ... .
-
Vyborny. Takze k tematu opet nic. Tohle forum je k zbliti. Kam chodi normalni lide, co je bavi vyvoj a chteji se posouvat? Proc v zahranici mohou lide diskutovat a pomahat si a tady musi byt kazdej nejvetsi chytrak, ostatni oslovovat lopaty, fiktivne brat daleko pres kilo a pak mi na pohovoru na 80% banalnich otazek nedokazat odpovedet a ostatnim zamestnavatelum produkovat kod jako prase bez spetky studu?
To je náhodou dobrá otázka. Také marně hledám fórum pro vývojáře. Znám akorát devel.cz, které je zamčené a nejde tam psát a ani číst a jinak skoro nic. Dnes už fóra moc nefrčí.
Taky nevím co je na tom zamčené... že se musíš přihlásit je plus, aspoň tam netrolí tolik lidí jako tady a pokud ano, tak aspoň na vlastní triko ... ne pod jakousi přezdívkou, kterou každou chvíli někdo mění... viz Javaman.
-
Vyborny. Takze k tematu opet nic. Tohle forum je k zbliti. Kam chodi normalni lide, co je bavi vyvoj a chteji se posouvat? Proc v zahranici mohou lide diskutovat a pomahat si a tady musi byt kazdej nejvetsi chytrak, ostatni oslovovat lopaty, fiktivne brat daleko pres kilo a pak mi na pohovoru na 80% banalnich otazek nedokazat odpovedet a ostatnim zamestnavatelum produkovat kod jako prase bez spetky studu?
To je náhodou dobrá otázka. Také marně hledám fórum pro vývojáře. Znám akorát devel.cz, které je zamčené a nejde tam psát a ani číst a jinak skoro nic. Dnes už fóra moc nefrčí.
Taky nevím co je na tom zamčené... že se musíš přihlásit je plus, aspoň tam netrolí tolik lidí jako tady a pokud ano, tak aspoň na vlastní triko ... ne pod jakousi přezdívkou, kterou každou chvíli někdo mění... viz Javaman.
Náhodou se tam trolí parádně, dokonce tam i dlouhou dobu vedl žebříček 100% troll a měl(a) nejvíc příspěvků. Jen na to řešení technických problémů to moc není. Jak jsem psal, česká komunita je dost malá (natož když to omezíš ještě registrací) a odpovědi ani nejsou indexované a archivované, takže je z toho zákonitě akorát žvanírna nějaké malé skupinky kamarádů (což nemusí být nutně špatně, ale jinak od toho moc nečekej). To je lepší StackOverflow nebo z českých Ábíčko.
-
Také mi vadí, že i na čtení diskuze na Devel.cz musíš být registrován. Dost to degraduje jeho smysl.
-
Unit testy su naviac proceduralne, vhodne na testovanie bezstavovych procedur. (Na OOP nevhodne) Komplexnejsie spravanie sa s tym komplikovane testuje, ze sa na to clovek radsej vykasle.
Osobne ich pouzivam presne na take procedury, kde viem, ze pre vstup A ma byt vystup B, uz mi to par krat zachranilo zadek.
Unit testy se samozřejmě s výhodou používají i na OOP, protože se jimi dá testovat i stavové chování objektů. Kdyby se daly testovat jen bezstavové metody, byly by takto omezené testy k ničemu.
V tomhle souhlasím. Jednotkové testy a OOP k sobě patří a součástí jednotkového testu běžně je uvedení objektu do nějakého požadovaného stavu a následně provolání jeho metod a kontrola vrácených hodnot a výsledného stavu.
Potíž je spíš v tom, přesně vědět, co má být ten požadovaný a cílový stav a jak se mají konkrétní metody chovat. Často to nikde popsané není a lidé to mají jen v hlavě – na rozdíl od požadavků vnějšího rozhraní, které spíš bývají někde napsané a schválené.
Mno ok, nechce sa mi siahodlhe debaty o tomto topicu vytvarat. Ale pokial skutocne clovek pise OOP a nie nejaku parodiu na to, tak vztahy medzi objektami neumoznuju dobre pokryt spravanie unit testami. Vezmite si uz len taky polymorfizmus, (Objekt A dedi od objektu B, nechytajte ma na terminologii, na triedy sa nehram :) ). Niekde v konfiguracii objektu C je malo dolezity objekt A. S objektom A sa spravi unit test. Unit test prejde. Ale zrazu nieco blbne na produkcii. To preto, lebo v konfiguracii je objekt B. Uviedol som najtrivialnejsi pripad. Ani rozne "mocky" nie su spasonosne riesenie, lebo nerataju so vsetkymi moznymi nastaveniami v produkcii. OOP vytvara velku sadu moznosti, lebo zapuzdruje vykonavany kod.
Unit testy su fajn, ale netreba sa na ne velmi spoliehat. Jim Coplien, uznavany autor, ktory skuma oop, momentalne robi agilne techniky povedal: "Unit testing is nothing more than intellectual masturbation." Nieco v tom zmysle, ze unit testy sa pisu kvoli unit testom a tomu, co si zmysli porogramator testovat. Netestuju to, ci je program spravny.
-
Vyborny. Takze k tematu opet nic. Tohle forum je k zbliti.
Na blbou otázku blbá odpověď ... .
Omyl sudruhu. Tady na rootu kvitne blbost. Neexistuje blba otazka, len hlupa odpoved. A hlupost je tu rozsirena :)
-
Unit testy su naviac proceduralne, vhodne na testovanie bezstavovych procedur. (Na OOP nevhodne) Komplexnejsie spravanie sa s tym komplikovane testuje, ze sa na to clovek radsej vykasle.
Osobne ich pouzivam presne na take procedury, kde viem, ze pre vstup A ma byt vystup B, uz mi to par krat zachranilo zadek.
Unit testy se samozřejmě s výhodou používají i na OOP, protože se jimi dá testovat i stavové chování objektů. Kdyby se daly testovat jen bezstavové metody, byly by takto omezené testy k ničemu.
V tomhle souhlasím. Jednotkové testy a OOP k sobě patří a součástí jednotkového testu běžně je uvedení objektu do nějakého požadovaného stavu a následně provolání jeho metod a kontrola vrácených hodnot a výsledného stavu.
Potíž je spíš v tom, přesně vědět, co má být ten požadovaný a cílový stav a jak se mají konkrétní metody chovat. Často to nikde popsané není a lidé to mají jen v hlavě – na rozdíl od požadavků vnějšího rozhraní, které spíš bývají někde napsané a schválené.
Ale pokial skutocne clovek pise OOP a nie nejaku parodiu na to, tak vztahy medzi objektami neumoznuju dobre pokryt spravanie unit testami. Vezmite si uz len taky polymorfizmus, (Objekt A dedi od objektu B, nechytajte ma na terminologii, na triedy sa nehram :) ). Niekde v konfiguracii objektu C je malo dolezity objekt A. S objektom A sa spravi unit test. Unit test prejde. Ale zrazu nieco blbne na produkcii. To preto, lebo v konfiguracii je objekt B. Uviedol som najtrivialnejsi pripad. Ani rozne "mocky" nie su spasonosne riesenie, lebo nerataju so vsetkymi moznymi nastaveniami v produkcii. OOP vytvara velku sadu moznosti, lebo zapuzdruje vykonavany kod.
To se klidně může stát, ovšem problém není v OOP, ale v tom, že nemáš nikde přesně specifikované, jak se má který objekt/třída chovat – takže jednotkové testy střílíš od boku. Představ si, že bys měl proceduru s padesáti parametry, některé vstupní, některé výstupní, některé oboje a zdokumentované to budeš mít jen minimálně – přestože tam není žádné OOP, jednotkový test taky nenapíšeš – resp. nějaký napíšeš, ale bude k ničemu, protože nevíš, jak se to (na téhle úrovni) má chovat. Oproti tomu integrační/systémové testy napíšeš a budou ti užitečné, protože třeba implementuješ protokol podle nějakého RFC nebo máš závaznou specifikaci, kterou ti podepsal zákazník – na tom se dá stavět.
(případně nemáš vůbec nic a programuješ to jen na základě domněnek a výkřiků, které se k tobě dostaly po telefonu, ale tam už bych pak nemluvil o vývoji softwaru resp. softwarovém inženýrství)
BTW: dělal jsem i v týmu, kde se drželo 100% pokrytí jednotkovými testy a návrh i na úrovni tříd byl písemně zdokumentovaný a bylo možné psát dobré jednotkové testy – byla to příjemná práce a mělo to úroveň. Ale běžná praxe ve většině firem to rozhodně není – nemají na to. A dokud (pokud) je nedokopeš k tomu, aby bylo dobře specifikované chování na úrovni tříd, tak nemá smysl si nalhávat, že tě jednotkové testy spasí. Je lepší začít tím, co máš dané a dobře popsané – což bývá vnější rozhraní → integrační/systémové testy. A taky až si bude zákazník na něco stěžovat, tak to bude právě rozpor se specifikací vnějšího rozhraní – ovšem jestli si mezi třídami uvnitř předáváš takové hodnoty nebo makové je mu úplně jedno.
-
Nepoužívám Javu, takže takové berličky nepotřebuju :-).
-
To se klidně může stát, ovšem problém není v OOP, ale v tom, že nemáš nikde přesně specifikované, jak se má který objekt/třída chovat – takže jednotkové testy střílíš od boku.
To casto ani nebyva specifikovane, pokial nenajimaju uplne lopaty ako programatorov. Inak musi byt ozrutny analyticky tim a bolo by lacnejsie, ak by to kodili analytici.
Představ si, že bys měl proceduru s padesáti parametry, některé vstupní, některé výstupní, některé oboje a zdokumentované to budeš mít jen minimálně – přestože tam není žádné OOP, jednotkový test taky nenapíšeš – resp. nějaký napíšeš, ale bude k ničemu, protože nevíš, jak se to (na téhle úrovni) má chovat.
Ak ma procedura 50 parametrov, tak tam uz nieco strasne smrdi.
-
Zrovna s refaktoringem ti jednotkové testy moc nepomohou, protože je musíš taky přepsat a tím ztrácíš jistotu, že program funguje stejně jako dřív – pokud jsi udělal chybu v kódu, pravděpodobně ji uděláš i při přepisování testu, protože vycházíš třeba z nějakých mylných předpokladů, jak se má program chovat a tu chybu zadrátuješ do kódu i do testu.
Pokud chceš refaktorovat trochu víc, než přejmenovávat lokální proměnné uvnitř metod nebo měnit odsazení, tak potřebuješ integrační/systémové testy, které ověří funkčnost celku.
Pokud refaktoruji víc, tak samozřejmě v součinnosti s uživatelem. Co se jednotkových testů týče, tak stále mám problém je nějak rozumně uchopit, aby byly ku pomoci. Snažím se je dělat, ale přijdou mi zatím takové... Zvláštní... A tvůrce daného ERP je momentálně docela „tlačí“ jako jedinou samospásnou věc (alespoň mi to tak přijde) a myslím si, že zas tak „samospásné“ nejsou, ale jak říkám, možná je neumím řádně uchopit a psát...
-
Také mi vadí, že i na čtení diskuze na Devel.cz musíš být registrován. Dost to degraduje jeho smysl.
A ptal jste se Illicha proc to tak je? Treba k tomu maji nejaky dobry duvod...
-
Také mi vadí, že i na čtení diskuze na Devel.cz musíš být registrován. Dost to degraduje jeho smysl.
A ptal jste se Illicha proc to tak je? Treba k tomu maji nejaky dobry duvod...
Ptala se ho spousta lidí. Dokonce byly přímo na Develu otázky/ankety, co vylepšit a vyhrával tam názor, že by aspoň pro čtení měl být otevřený přístup. A nic z toho. Už to fakt nemá smysl řešit.
-
Vezmite si uz len taky polymorfizmus, (Objekt A dedi od objektu B, nechytajte ma na terminologii, na triedy sa nehram :) ). Niekde v konfiguracii objektu C je malo dolezity objekt A. S objektom A sa spravi unit test. Unit test prejde. Ale zrazu nieco blbne na produkcii. To preto, lebo v konfiguracii je objekt B. Uviedol som najtrivialnejsi pripad. Ani rozne "mocky" nie su spasonosne riesenie, lebo nerataju so vsetkymi moznymi nastaveniami v produkcii. OOP vytvara velku sadu moznosti, lebo zapuzdruje vykonavany kod.
Porušil jsi LSP, tak se nediv.
-
Pokud refaktoruji víc, tak samozřejmě v součinnosti s uživatelem. Co se jednotkových testů týče, tak stále mám problém je nějak rozumně uchopit, aby byly ku pomoci. Snažím se je dělat, ale přijdou mi zatím takové... Zvláštní... A tvůrce daného ERP je momentálně docela „tlačí“ jako jedinou samospásnou věc (alespoň mi to tak přijde) a myslím si, že zas tak „samospásné“ nejsou, ale jak říkám, možná je neumím řádně uchopit a psát...
Do refaktorování uživatel vůbec nemá co mluvit, neboť funkcionalita se nemění.
-
Unit testy su naviac proceduralne, vhodne na testovanie bezstavovych procedur. (Na OOP nevhodne) Komplexnejsie spravanie sa s tym komplikovane testuje, ze sa na to clovek radsej vykasle.
Osobne ich pouzivam presne na take procedury, kde viem, ze pre vstup A ma byt vystup B, uz mi to par krat zachranilo zadek.
Unit testy se samozřejmě s výhodou používají i na OOP, protože se jimi dá testovat i stavové chování objektů. Kdyby se daly testovat jen bezstavové metody, byly by takto omezené testy k ničemu.
V tomhle souhlasím. Jednotkové testy a OOP k sobě patří a součástí jednotkového testu běžně je uvedení objektu do nějakého požadovaného stavu a následně provolání jeho metod a kontrola vrácených hodnot a výsledného stavu.
Potíž je spíš v tom, přesně vědět, co má být ten požadovaný a cílový stav a jak se mají konkrétní metody chovat. Často to nikde popsané není a lidé to mají jen v hlavě – na rozdíl od požadavků vnějšího rozhraní, které spíš bývají někde napsané a schválené.
Ale pokial skutocne clovek pise OOP a nie nejaku parodiu na to, tak vztahy medzi objektami neumoznuju dobre pokryt spravanie unit testami. Vezmite si uz len taky polymorfizmus, (Objekt A dedi od objektu B, nechytajte ma na terminologii, na triedy sa nehram :) ). Niekde v konfiguracii objektu C je malo dolezity objekt A. S objektom A sa spravi unit test. Unit test prejde. Ale zrazu nieco blbne na produkcii. To preto, lebo v konfiguracii je objekt B. Uviedol som najtrivialnejsi pripad. Ani rozne "mocky" nie su spasonosne riesenie, lebo nerataju so vsetkymi moznymi nastaveniami v produkcii. OOP vytvara velku sadu moznosti, lebo zapuzdruje vykonavany kod.
To se klidně může stát, ovšem problém není v OOP, ale v tom, že nemáš nikde přesně specifikované, jak se má který objekt/třída chovat – takže jednotkové testy střílíš od boku. Představ si, že bys měl proceduru s padesáti parametry, některé vstupní, některé výstupní, některé oboje a zdokumentované to budeš mít jen minimálně – přestože tam není žádné OOP, jednotkový test taky nenapíšeš – resp. nějaký napíšeš, ale bude k ničemu, protože nevíš, jak se to (na téhle úrovni) má chovat. Oproti tomu integrační/systémové testy napíšeš a budou ti užitečné, protože třeba implementuješ protokol podle nějakého RFC nebo máš závaznou specifikaci, kterou ti podepsal zákazník – na tom se dá stavět.
(případně nemáš vůbec nic a programuješ to jen na základě domněnek a výkřiků, které se k tobě dostaly po telefonu, ale tam už bych pak nemluvil o vývoji softwaru resp. softwarovém inženýrství)
BTW: dělal jsem i v týmu, kde se drželo 100% pokrytí jednotkovými testy a návrh i na úrovni tříd byl písemně zdokumentovaný a bylo možné psát dobré jednotkové testy – byla to příjemná práce a mělo to úroveň. Ale běžná praxe ve většině firem to rozhodně není – nemají na to. A dokud (pokud) je nedokopeš k tomu, aby bylo dobře specifikované chování na úrovni tříd, tak nemá smysl si nalhávat, že tě jednotkové testy spasí. Je lepší začít tím, co máš dané a dobře popsané – což bývá vnější rozhraní → integrační/systémové testy. A taky až si bude zákazník na něco stěžovat, tak to bude právě rozpor se specifikací vnějšího rozhraní – ovšem jestli si mezi třídami uvnitř předáváš takové hodnoty nebo makové je mu úplně jedno.
To je omyl, softwarové inženýrství je právě z těch výkřiků sestavit funkční systém, který funkčností přesahuje představy zákazníků.
-
... žvást, žvást, žvást, ...
Ivane Jasánku Nový, ty ses rozhodl, že dneska zrušíš tohle téma, že?
-
... žvást, žvást, žvást, ...
Ivane Jasánku Nový, ty ses rozhodl, že dneska zrušíš tohle téma, že?
Hele a není lepší na toho dementa nereagovat a nevyvolávat v něm nutkání psát ty hovadské posty?
-
Do refaktorování uživatel vůbec nemá co mluvit, neboť funkcionalita se nemění.
To sice nemá, ale bez testů to do produkce nepustím... Opravdu si nelajznu, že tam bude nějaká chyba, jsme jen lidé.
-
testy nerobi vacsina firiem. nemaju na to kapacity, seru na to, a jednak nevedia ako na to. taka je realita
-
Do refaktorování uživatel vůbec nemá co mluvit, neboť funkcionalita se nemění.
To sice nemá, ale bez testů to do produkce nepustím... Opravdu si nelajznu, že tam bude nějaká chyba, jsme jen lidé.
Bez testů nemá význam ani refaktorování.
-
To se klidně může stát, ovšem problém není v OOP, ale v tom, že nemáš nikde přesně specifikované, jak se má který objekt/třída chovat – takže jednotkové testy střílíš od boku.
To casto ani nebyva specifikovane, pokial nenajimaju uplne lopaty ako programatorov. Inak musi byt ozrutny analyticky tim a bolo by lacnejsie, ak by to kodili analytici.
Tohle dělá spíš architekt/senior – detailní technická analýza, sepíše ten návrh na úrovni tříd a rozhraní, nakreslí pár obrázků a někdo to podle toho naprogramuje. Neříkám, že se to tak musí dělat vždy, spíš si myslím, že ne, nebo jen u kritičtějších věcí. Ale pokud se to dělá, tak máš jasné podklady a můžeš podle nich napsat dobře jednotkové testy. Pokud tuhle analýzu neděláš (písemně) a máš to jen v hlavě, resp. vymyslí si to ten samý člověk, který pak píše kód, tak si jednotkové testy sice taky může napsat, ale ty pak slouží vyloženě jen jako pomůcka programátora, aby si jimi odladil kód – užitečné to je, ale není tam žádná přímá vazba na požadavky a kvalitu z pohledu zákazníka/zadání.
Představ si, že bys měl proceduru s padesáti parametry, některé vstupní, některé výstupní, některé oboje a zdokumentované to budeš mít jen minimálně – přestože tam není žádné OOP, jednotkový test taky nenapíšeš – resp. nějaký napíšeš, ale bude k ničemu, protože nevíš, jak se to (na téhle úrovni) má chovat.
Ak ma procedura 50 parametrov, tak tam uz nieco strasne smrdi.
To byla narážka na ten tvůj popis OOP ;-)
Klidně si tam představ proceduru jen s pěti parametry – důsledky jsou stejné – pokud nemáš dobře zdokumentované rozhraní a návrh, tak nejsi schopný napsat dobré testy. Bez pořádné specifikace napíšeš testy, které akorát vytvářejí falešný pocit bezpečí – všechno bude krásně zelené, budeš mít vysoké pokrytí testy, ale neříká to nic o tom, zda program jako celek funguje správně.
-
Dělení na jednotkové a funkcionální testy je umělé, používají ho hlavně manažeři. V praxi pro dobré pokrytí stačí testovat na vyšší úrovni.
Není pravda, že testy jsou práce navíc. Od určité velikosti programu nelze kontrolovat jeho správnost ručně. Psaní testů práci naopak urychlí.
-
Do refaktorování uživatel vůbec nemá co mluvit, neboť funkcionalita se nemění.
To sice nemá, ale bez testů to do produkce nepustím... Opravdu si nelajznu, že tam bude nějaká chyba, jsme jen lidé.
Pokud máš uvnitř nějaký algoritmus zabalený v nějaké třídě a tento algoritmus máš dobře zdokumentovaný a víš, pro jaké vstupy má vracet jaké výstupy, tak ten jednotkový test dává smysl a pomůže udržet kvalitu (kvalitu z pohledu zákazníka). Tedy za předpokladu, že máš napojení té třídy na zbytek systému správně a neuděláš chybu někde jinde, např. nepřehodíš znaménko nebo neposuneš řád nebo neprohodíš atributy někde výš.
Pokud ale ty třídy tak dobře zdokumentované nemáš a/nebo se obáváš, že uděláš chybu i někde jinde, tak potřebuješ integrační/systémové testy, které ověří funkci systému jako celku a budou k němu přistupovat co nejpodobnějším způsobem, jako to bude dělat uživatel v produkci. Tyhle testy ti dají mnohem větší jistotu, že to funguje správně, než ty jednotkové.
Ideálně použiješ kombinaci obou – pomocí komplexních testů ověříš základní scénáře a to, že jsou jednotlivé komponenty správně propojené. A pomocí jednotlivých ověříš všechny možné případy jednotlivých u jednotlivých tříd.
Výhodou jednotkových testů je to, že jsou rychlé, nemusíš překompilovat a nasadit celou aplikaci, můžeš si je pouštět pořád dokola a ladit algoritmus/třídu. Ale rozhodně nejsou samospásné – bez těch integračních/systémových testů se neobejdeš.
-
Dělení na jednotkové a funkcionální testy je umělé, používají ho hlavně manažeři.
Nemyslím si, že je to umělé dělení. Jednak testuješ na jiné úrovni a jednak (hlavně) ty testy mají jiný účel. Jednotkový test slouží hlavně programátorovi, aby mu usnadnil vývoj, ladění, aby umožnil lepší spolupráci mezi programátory (např. si můžeš odladit svoji třídu i když kolega odpovídající protikus ještě nemá hotový). Zatímco komplexní testy (integrační/systémové) ověřují shodu programu jako celku proti specifikaci schválené zadavatelem – a to je to, co zajímá zákazníka/uživatele (ne to, jaké parametry si předává Venca s Pepou mezi svými třídami kdesi uvnitř programu).
V praxi pro dobré pokrytí stačí testovat na vyšší úrovni.
Pokrytí je jen pomocný ukazatel – není to cíl – cílem je, aby program fungoval podle zadání (a aby zadání odpovídalo reálným potřebám).
Není pravda, že testy jsou práce navíc. Od určité velikosti programu nelze kontrolovat jeho správnost ručně. Psaní testů práci naopak urychlí.
+1