devel.cz

Komentáře

• Honza Břešťan : Jeste nam tu chybi typesystem. Pouzivate staticke typovani, nebo debugger? — 30.12.2014
• David Adamczyk : LOL, skoda ze tu nejsou lajky. Tohle se povedlo :D — 30.12.2014
• Kit : Ladislav Hruska je autorem nějakého konceptu pro IT? Byl by nějaký odkaz pro srovnání? — 30.12.2014
• Petr Voneš : Ta konstrukce je mozna jinak: pouzivate staticke typovani a debugger nebo ne ? — 30.12.2014
• Honza Břešťan : Lada Hruska je spoluautor navrhu PHP a JavaScriptu. https://www.youtube.com/watch?v=5ia3Veh5gRM — 30.12.2014
• Kit : Asi chybný odkaz. Je tam něco o vaření. — 30.12.2014
• Honza Břešťan : http://i.imgur.com/YLdZhZv.jpg — 30.12.2014
• Kit : To jsem pochopil. Jen mi není jasné, jakou roli sehrál Lada Hruska v návrhu PHP a Javascriptu. — 30.12.2014
• awmnqgfu : Hruška, Kit a Babica. Silná trojka schopná všeho :D — 30.12.2014
• Kit : Babica? Ten dělal návrh čeho? C#? — 30.12.2014
• Honza Břešťan : Javy. "A kdyz nemate lambdy, tak tam dejte anonymni tridu..." — 30.12.2014
• Žížala : @Jan Břešťan: Olé, +777 xD Dík za důvod k zasmání po 14 denním návratu do práce ... — 2.1.2015
• Kit : @Žížala: Také jsem se tím velmi dobře pobavil. Dá se to aplikovat i na C#: Chtějí programátoři gettery a settery? Tak jim je tam dáme. Budou si myslet, že tím zapouzdří objekt. — 2.1.2015
• kohven : Myslím si, že jde spíše o potřebu říct: "Když to budete dělat tak dobře jako já, tak vám to vyřeší spoustu problémů, které pak nebudete muset řešit jinými nástroji/postupy." Nebo možná dokonce: "To, že potřebujete tyto nástroje/postupy, znamená, že něco děláte špatně." Někdy má pravdu, ale často ne. Pravděpodobně si totiž neuvědomuje, že jeho workflow postihuje jen malou část problematiky vývoje SW. Už to, že otázka není omezena např. jen na PHP, ale na všechny jazyky, je dost odvážné. Psát v C bez debuggeru by byla řehole. V ASM už by to bylo čiré zoufalství. Nicméně lidem, kteří tvrdí, že jsou tak dobří vývojáři, že už jim nemůže debugger pomoct, se vždycky rád zasměji, ať už píšou v čemkoliv. — 5.1.2015
• siq : to co pise kohven * 9999999999. — 5.1.2015
• Kit : @kohven: "Psát v C bez debuggeru by byla řehole. V ASM už by to bylo čiré zoufalství." Něco na tom bude, i když i tady se dají použít testy. Nezapomeň, že testy mohou být (a také bývají) napsány v jiném jazyce než aplikace. — 5.1.2015
• kohven : @Kit: Hlavně by se nemělo zapomínat na to, že testy a debugger slouží k něčemu jinému a každé z toho se používá v jiných situacích. Ano, jednotkový test lze použít jako breakpoint na chybě, ale pod pojmem práce s debuggerem si představuji trochu víc. Taky ta idea s TDD místo debuggování vychází z toho, že se začíná psát na zelené louce a můžu ovlivnit každou řádku kódu. Ale při přebírání cizího kódu je debugger nejlepší přítel. Výsledek testu je statická záležitost. Prostě tady to spadlo. Při debuggování to vidím dynamicky. Např. že se mi po jednom cyklu změnila proměnná a neměla by. I v desetiřádkové metodě se toho může dít docela dost. Vývoj bez debuggeru přirovnávám k jízdě na kole bez držení. Jde to, ale proč se nechytnout? :) — 5.1.2015
• siq : A hlavne veci ako race condition nemas sancu poriadne odhalit pomocou unit testov. Teda asi mas, ale debugger bude ovela efektivnejsi. To sa samozrejme v PHP nestava, ale ja napriklad v Jave pisem vela veci multivlaknovo a bez debuggeru by som si uz davnu prehnal gulku lebkou, lebo by to proste neslo. — 6.1.2015
• Kit : @siq: Jak se hledají race condition pomocí debuggeru? To si krokuješ dvě vlákna souběžně? — 6.1.2015
• Mario : @Kit Presne tak. Ve Visual Studio muzes krokovat soubezne vice vlaken, nebo si nektere z nich zmrazit, nebo se muzes v kazdem kroku prepnout na kterekoliv aktivni vlakno a tam pokracovat, atd. Taky muzes treba za behu aplikace k ni pripojit debugger, pozastavit program a podivat se co aktualne, ktery thread dela, prida se to v pripade, ze se ti treba zasekne main thread (zamrznuti aplikace) a zjistujes co tam provadi. Debuggery jsou v dnesni dobe na velmi pokrocile urovni, neumim si predstavit kazdodenni praci bez neho. Treba dneska, potreboval jsem udelat malou zmenu v starsim systemu, v prvnim kroku jsem hodil na potrebne misto breakpoint, spustil aplikaci, proklikal az na pozadovanou obrazovku, tam zmackl tlacitko, ktere spoustelo funkci potrebnou k uprave, breakpoint zastavil beh, odkoroval jsem si to, podival co to presne dela s aktualnimi daty, zmenil jsem hodnotu, pustil dal, spatne, vratil jsem o par kroku zpet, zase zmenil hodnotu, pustil dal, spravne. Zastavil jsem aplikaci, build, nasazeni na produkci, chyba opravena behem par minut. — 6.1.2015
• Kit : @Mario: To vypadá dost komplikovaně. Jak jsi věděl, kam máš dát ten breakpoint? — 6.1.2015
• Mario : @Kit V designeru se podivam, jaka funkce se spousti na evente Click u tlacitka, tam dam breakpoint a pak uz jenom staci na to tlacitko v aplikaci kliknout. Pokud by ta aplikace byla napsana s dodrzenim MVVM, tak se podivam jaky command to tlacitko ma nastavene. — 6.1.2015
• Taco : @Kit: "To vypadá dost komplikovaně" - ty si děsnej provokatér! — 6.1.2015
• Kit : @Taco: Nápodobně :-) — 6.1.2015
• v6ak : Ladění race condition je sama o sobě komplikovaná záležitost :P Někdy pomůže specializovaný nástroj typu Helgrind. — 6.1.2015
• mr.fatblunt : Myslim ze ne vzdy je debugger vhodne pouzit. Ja jej pouzivam jako last-resort, prave treba pri hledani race-condition nebo nezvyklych situaci. Muj nazor je ze kdyz je potreba debugger uz je design "na hrane". Samozrejme kdyz je system hodne slozity a problem obskurni, je debugger zlata vec. Rozhodne bych se ale treba @Mario pri "delani zmeny ve starsim systemu" debuggeru vyhybal, dokud to jde, protoze ta pohodlnost vede k tomu ze clovek zapomene na zakladni zpusoby zvyseni prehlednosti kodu, a pak jednoduse prasi, protoze vi ze si to kdykoliv muze odkrokovat... — 10.1.2015
• kohven : @mr.fatblunt: S touhle logikou by měla všechna auta přivařenou kapotou a opravovala by se laparoskopicky. Protože jinak by se nikdo nesnažil, kdyby věděl, že může zvednout kapotu a podívat se, co pod ní vlastně je. Každý, kdo si chce říkat programátor, si musí osvojit dovednost nebýt prase i když používá debugger. — 12.1.2015
• mr.fatblunt : @kohven: Spis by se s touhle logikou auta porad prodavala s kompletni dokumentaci, aby se normalni clovek v tom rozsahlem systemu neztratil. "Pod kapotu" se neni treba divat, kdyz je kod samodokumentujici, prehledny, jasny. Programy se pisou proto, aby jim rozumeli primarne lide, ne stroje. Taky si nemyslim ze kazdy kdo pouziva debugger je hned prase, jen me trochu zarazil ten postup Maria, kdy misto aby sel na jistotu a pridal funkcionalitu do kodu, spousti nejdrive puvodni kod a zkoumanim jeho stavu hada, kam pridat tu novou vec. To si myslim ze neni prilis pragmaticky pristup... — 13.1.2015
• kohven : Není to akademický přístup, není to nejbezpečnější přístup a našel bych ještě spoustu toho, co to není, ale zrovna pragmatické mi to docela přijde. Vždy (nikdy) není čas všechno dokonale pochopit a čas jsou peníze a o peníze jde až v první řadě. Někdo tu hezky popisoval, že orientace v cizím kódu je jako orientace v cizím městě. Když chci jít na poštu, můžu si vyhradit měsíc dovolené a projít si celé město, celé ho poznat a pak jít na poštu nejkratší cestou. A nebo můžu někoho (debugger) požádat, aby mě na tu poštu dovedl a pak už tam můžu chodit sám (aniž bych znal cestu třeba k doktorovi). Že tím bude kód nejspíše degenerovat, to je asi pravda. Ale často to nevadí, protože se nedělají velké změny a je pořád výhodnější více testovat než to celé pochopit. A když jsou potřeba udělat velké změny, tak se stejně většinou musí znova přepsat větší část, ať už je základ jakkoliv dobře nakódovaný. Takže ačkoliv se sám podvědomě snažím spíše poznávat město, tak praxe mě naučila, že jsem se měl nechat akorát dovést na poštu. A taky se mi to nelíbí. — 14.1.2015