Online IDE pro Javu s možností debugování

Re:Online IDE pro Javu s možností debugování
« Odpověď #120 kdy: 05. 08. 2016, 21:53:16 »
Na takové aplikaci bude nutné udělat takovou spoustu jiných změn, že nějaké přejmenování metody bude jen prkotinou a nejspíš taková metoda přitom zcela zanikne.

Tak si tam predstav nejaky jiny refaktoring...

Cim sofistikovanejsi bude, tim hur na tom budes s nastroji, ktere doopravdy nerozumi kodu.


dustin

Re:Online IDE pro Javu s možností debugování
« Odpověď #121 kdy: 05. 08. 2016, 22:51:57 »
Třeba tak triviální věc jako přidat do celého projektu/všech tříd chybějící užitečnou anotaci @Override. S IDE práce na chviličku, jen ten commit bude obsahovat třeba pár tisíc souborů (což je taky na chviličku).

Nebo hlídání anotací @Nullable a @Nonnull a spol.

Vývojář (i junior, začátečník) musí mít projekt pod kontrolou. Musí být schopen s kódem "cvičit" bez ohledu na jeho rozsah. Základní úpravy (přejmenování, přesuny, vytažení kódu do metod, změny parametrů metod atd. atd.) se dělají neustále dokola, mnohokráte za hodinu. A není potřeba kontrolovat kompilovatelnost, ta je prostě zajištěna. A vše je to otázka několika sekund.

Samozřejmě úplná spolehlivost vyžaduje vyhýbat se mapováním stringů na názvy (PropertyModel ve Wicketu apod.). IDEA se to sice snaží hledat a nabízet, ale to už je cesta do pekla...

dustin

Re:Online IDE pro Javu s možností debugování
« Odpověď #122 kdy: 05. 08. 2016, 23:14:52 »
Ještě mě překvapuje, že profesionální vývojář, který očekává příjem mnoha desítek tisíc Kč, řeší paměťovou náročnost vývojového nástroje. V době, kdy lze profi pracovní stanice se 128GB ECC DDR3 RAM pořídit za 20k Kč bez DPH.

Lopata nejlopatější

Re:Online IDE pro Javu s možností debugování
« Odpověď #123 kdy: 05. 08. 2016, 23:27:25 »
Vývojář (i junior, začátečník) musí mít projekt pod kontrolou. Musí být schopen s kódem "cvičit" bez ohledu na jeho rozsah. Základní úpravy (přejmenování, přesuny, vytažení kódu do metod, změny parametrů metod atd. atd.) se dělají neustále dokola, mnohokráte za hodinu.
Tak v takovým týmu a prostředí bych chtěl teda dělat..

Jinak emacs je taky IDE, jak jste správně poznamenal, jeho nevýhoda je, že je univerzální a ne specializované, takže trpí tou univerzalitou, která je cenou za ztrátu efektivity. Jste jakoby svobodnější, můžete toho udělat více, ale reálně to neuděláte, protože se k tomu nedostanete, znamenalo by to vybudovat si vlastní specializované IDE pomocí vlastních skriptů na bázi emacsu, ale ty budou vždy jen ve fázi rozpracovanosti, nezbude vám sil je dokončit. Taky vás nasměrují určitým směrem, investujete do nich hodně práce, takže ten směr změnit bude pro vás složité, časem se stane neoptimální, ale na jeho změnu díky předešlým investicím, nikdy nepřistoupíte. Zakopaný pes je taky v datových strukturách, s emacsem de facto nepoužijete žádné, protože vymyslet ji je časově náročné, je to zatíženo velkým rizikem a každá datová struktura má svou režii v napsání skriptů k její obsluze, tak se stane, že pro vás datovou strukturou bude fakticky skript, který použijete jako šablonu pro copy&paste a tím se časem ten systém stane nemodifikovatelným, jeho modifikace by znamenala přepsat všechny skripty. Tedy vlastně jako autor zkostnatíte, nakonec se stanete vězněm svého IDE a to v daleko větší míře, než byste čekal.

Kdežto specializované IDE s klidným svědomím zahodíte a začnete pracovat na jiném IDE, které lépe vyhovuje aktuální práci, právě proto, že jste do něj investoval minimum námahy.

Ono se to nezdá, ale systém pro vytváření aplikací je v 98% de facto mnohem složitější systém, než výsledná aplikace a to bez ohledu na základ, který k němu použijete.
Tohle jsem moc nepobral. Mě teda nepříde efektivní vyvíjet kvůli každému projektu zvlášť specializované IDE. Komplexní IDE je sice složitější než většina aplikací (alespoň mých), ale zas těch aplikací v něm udělám desítky, možná stovky, takže ve výsledku se to komplexní IDE vyplatí.
Samozřejmě, že jeden jediný člověk za svůj život nevyvine komplexní IDE typu NEtBeans bez ohledu na to, jaký základ použije. To přece není o Emacsu nebo Vimu, to asi platí obecně.
Zakopaný pes je taky v datových strukturách... - ty seš taky struktura...

dustin

Re:Online IDE pro Javu s možností debugování
« Odpověď #124 kdy: 05. 08. 2016, 23:35:26 »
Vývojář (i junior, začátečník) musí mít projekt pod kontrolou. Musí být schopen s kódem "cvičit" bez ohledu na jeho rozsah. Základní úpravy (přejmenování, přesuny, vytažení kódu do metod, změny parametrů metod atd. atd.) se dělají neustále dokola, mnohokráte za hodinu.
Tak v takovým týmu a prostředí bych chtěl teda dělat..

A ty svůj kód dáš na první dobrou? Než něco commituju, musí to nějak vypadat, abych se za něj nemusel stydět a nezvonilo mi v uších, až to po mně někdo jiný nebo i já sám bude upravovat/rozšiřovat/aktualizovat/prostě vyvýjet dál. Ty změny se vůbec nemusí týkat nějakého API, i kód vnitřní implementace je klíčový. I taková zvěrstva tu zazněla, že na vnitřním kódu vlastně nezáleží.


gl

Re:Online IDE pro Javu s možností debugování
« Odpověď #125 kdy: 06. 08. 2016, 01:30:00 »
Vývojář (i junior, začátečník) musí mít projekt pod kontrolou. Musí být schopen s kódem "cvičit" bez ohledu na jeho rozsah. Základní úpravy (přejmenování, přesuny, vytažení kódu do metod, změny parametrů metod atd. atd.) se dělají neustále dokola, mnohokráte za hodinu.
Tak v takovým týmu a prostředí bych chtěl teda dělat..

A ty svůj kód dáš na první dobrou? Než něco commituju, musí to nějak vypadat, abych se za něj nemusel stydět a nezvonilo mi v uších, až to po mně někdo jiný nebo i já sám bude upravovat/rozšiřovat/aktualizovat/prostě vyvýjet dál. Ty změny se vůbec nemusí týkat nějakého API, i kód vnitřní implementace je klíčový. I taková zvěrstva tu zazněla, že na vnitřním kódu vlastně nezáleží.

Pokud se jedná o slušně fungující kód dodržující dohodnuté konvence a ty přesto požaduješ jeho předělání, tak tě musí mít kolegové rádi.

Tuxik

  • *****
  • 1 473
    • Zobrazit profil
    • E-mail
Re:Online IDE pro Javu s možností debugování
« Odpověď #126 kdy: 06. 08. 2016, 07:47:58 »
Ještě mě překvapuje, že profesionální vývojář, který očekává příjem mnoha desítek tisíc Kč, řeší paměťovou náročnost vývojového nástroje. V době, kdy lze profi pracovní stanice se 128GB ECC DDR3 RAM pořídit za 20k Kč bez DPH.
Jestli to byla narážka na můj příspěvek, tak za prvé, nejsem profesionální vývojář, za druhé, zeptej se, na čem lidi běžně pracují, za třetí, ukaž mi tu profi stanici za ty peníze. Ať počítám, jak počítám, jenom paměť bude bratru za 12k, takže jestli k tomu seženeš desku, která to pobere, rozumný CPU, disk a case se zdrojem za 8k, tak nevím, jestli bych to nazval zrovna profi, to se dostáváme někam k totálnímu low endu, na kterým bych opravdu nechtěl kompilovat větší projekt, se kterým kompletně cvičíš.

Co s týče tvého cvičení s projektem, asi je něco špatně, pokud každý vývojář potřebuje takové věci dělat několikrát za hodinu a docela by mě zajímalo, jak se dá takhle fungovat v týmu. To musí být asi na každého vývojáře dva až tři lidi, kteří řeší správu gitu, ne?

Ivan Nový

Re:Online IDE pro Javu s možností debugování
« Odpověď #127 kdy: 06. 08. 2016, 08:44:41 »
Vývojář (i junior, začátečník) musí mít projekt pod kontrolou. Musí být schopen s kódem "cvičit" bez ohledu na jeho rozsah. Základní úpravy (přejmenování, přesuny, vytažení kódu do metod, změny parametrů metod atd. atd.) se dělají neustále dokola, mnohokráte za hodinu.
Tak v takovým týmu a prostředí bych chtěl teda dělat..

Jinak emacs je taky IDE, jak jste správně poznamenal, jeho nevýhoda je, že je univerzální a ne specializované, takže trpí tou univerzalitou, která je cenou za ztrátu efektivity. Jste jakoby svobodnější, můžete toho udělat více, ale reálně to neuděláte, protože se k tomu nedostanete, znamenalo by to vybudovat si vlastní specializované IDE pomocí vlastních skriptů na bázi emacsu, ale ty budou vždy jen ve fázi rozpracovanosti, nezbude vám sil je dokončit. Taky vás nasměrují určitým směrem, investujete do nich hodně práce, takže ten směr změnit bude pro vás složité, časem se stane neoptimální, ale na jeho změnu díky předešlým investicím, nikdy nepřistoupíte. Zakopaný pes je taky v datových strukturách, s emacsem de facto nepoužijete žádné, protože vymyslet ji je časově náročné, je to zatíženo velkým rizikem a každá datová struktura má svou režii v napsání skriptů k její obsluze, tak se stane, že pro vás datovou strukturou bude fakticky skript, který použijete jako šablonu pro copy&paste a tím se časem ten systém stane nemodifikovatelným, jeho modifikace by znamenala přepsat všechny skripty. Tedy vlastně jako autor zkostnatíte, nakonec se stanete vězněm svého IDE a to v daleko větší míře, než byste čekal.

Kdežto specializované IDE s klidným svědomím zahodíte a začnete pracovat na jiném IDE, které lépe vyhovuje aktuální práci, právě proto, že jste do něj investoval minimum námahy.

Ono se to nezdá, ale systém pro vytváření aplikací je v 98% de facto mnohem složitější systém, než výsledná aplikace a to bez ohledu na základ, který k němu použijete.
Tohle jsem moc nepobral. Mě teda nepříde efektivní vyvíjet kvůli každému projektu zvlášť specializované IDE. Komplexní IDE je sice složitější než většina aplikací (alespoň mých), ale zas těch aplikací v něm udělám desítky, možná stovky, takže ve výsledku se to komplexní IDE vyplatí.
Samozřejmě, že jeden jediný člověk za svůj život nevyvine komplexní IDE typu NEtBeans bez ohledu na to, jaký základ použije. To přece není o Emacsu nebo Vimu, to asi platí obecně.
Zakopaný pes je taky v datových strukturách... - ty seš taky struktura...

Specializované IDE - zná jazyk, během editování buduje AST, umí sestavit aplikaci, klidně v jednom IDE má x jazyků. Univerzální IDE - editor + nástroje na úpravu textu, typicky regex, vlastní skripty por úpravy, vlastní skripty pro sestavení aplikace. Obvykle zatížené bašismem a copy&paste.

A ta datová struktura, kolem které se točí práce v IDE je je to AST a další potřebné pro sestavení úlohy. Vtip je v tom, že IDE můžete vyměnit, každé IDE si načte projekt a samo si vytvoří potřebné datové interní struktury.

Když používáte vim, nebo emacs, taky takto můžete postupovat, ale zcela určitě nepostupujete, vše vyřešíte skripty, lépe řečeno šablonami skriptů, které upravujete na konkrétní podmínky použití, takže když je třeba něco podstatného změnit, musíte upravit všechny skripty, nemáte prostředky k tomu, aby se vygenerovaly automaticky, bez detailní znalosti projektu se neobejdete.

dustin

Re:Online IDE pro Javu s možností debugování
« Odpověď #128 kdy: 06. 08. 2016, 08:59:38 »
Pokud se jedná o slušně fungující kód dodržující dohodnuté konvence a ty přesto požaduješ jeho předělání, tak tě musí mít kolegové rádi.

Máš zkušenosti s větším živým projektem (pár tisíc tříd), který se roky iterativně posouvá dopředu dle aktuálních byznys požadavků? Pak zjistíš, že správná funkčnost kódu je jenom minimálním požadavkem. Minimálně stejně důležitým je možnost ten kód dál vyvíjet, používat, rozšiřovat. V tom je jeho hodnota. Jinak jej při každé změně budu muset zahodit a napsat to znovu. S tím souvisí základní věci - správná pojmenování všeho (a ne, opravdu na první dobrou nelze tohle dát, protože ten finální kód se od první verze zcela liší), krátké jednoduché metody (při vývoji vzniklé špagety je potřeba rozpadnout do metod - opět práce pro IDE), atd. atd.   Překvapuje mě, že tohle ještě vůbec někdo v dnešní době může neznat.

Samozřejmě pokud je cílem dodat zkompilovanou binárku klientovi, vykešovat a nazdar, pak je to jedno.

Kit

Re:Online IDE pro Javu s možností debugování
« Odpověď #129 kdy: 06. 08. 2016, 09:03:27 »
Co s týče tvého cvičení s projektem, asi je něco špatně, pokud každý vývojář potřebuje takové věci dělat několikrát za hodinu a docela by mě zajímalo, jak se dá takhle fungovat v týmu. To musí být asi na každého vývojáře dva až tři lidi, kteří řeší správu gitu, ne?

Pokud na takovém projektu pracuje víc než jeden vývojář, tak skutečně musí být velmi zajímavou prací řešení kolizí na Gitu. Sledovat stovky změn souborů v každém commitu, to musí být také slušný zážitek. Tomu jistě bude odpovídat i kvalita komentů.

Re:Online IDE pro Javu s možností debugování
« Odpověď #130 kdy: 06. 08. 2016, 09:03:42 »
Většinou je snadné zjistit co vrací funkce getEntity. Je to otázka pár vteřin.
Snadné zjistit? Tím regexpem? Nebo budete třeba stovky výskytů procházet očima? Jaká je v tom výhoda?

Měnit stovky výskytů volání metody jedné třídy v ostatních třídách? To smrdí špatným návrhem aplikace.
No vždyť ano, právě proto se dělá refaktoring, aby se změnil nevhodný návrh aplikace. A právě proto je potřeba mít nástroje, se kterými se refaktoring udělá snadno, rychle a spolehlivě - protože jinak ten nevhodný návrh nikdo neopraví, protože to přece ještě nestojí za tu námahu, a nevhodný návrh se v aplikaci zakonzervuje.

Na takové aplikaci bude nutné udělat takovou spoustu jiných změn, že nějaké přejmenování metody bude jen prkotinou a nejspíš taková metoda přitom zcela zanikne.
Což ale není důvod, aby tou prkotinou někdo strávil několik dní. Právě naopak, je dobře, když tu prkotinu udělá programátor rychle a správně, a pak může svůj čas věnovat významovým změnám kódu, které žádný automat neudělá.

Re:Online IDE pro Javu s možností debugování
« Odpověď #131 kdy: 06. 08. 2016, 09:06:24 »
Co s týče tvého cvičení s projektem, asi je něco špatně, pokud každý vývojář potřebuje takové věci dělat několikrát za hodinu
Výhoda toho, že to netrvá hodiny, ale pár vteřin, není v tom, že byste to prováděl několikrát za hodinu. Výhoda je, že to uděláte za pár vteřin a ty bývající hodiny můžete dělat něco produktivního. A hlavní výhoda je, že se do toho díky té rychlosti a spolehlivosti vůbec pustíte, takže se nezvětšuje technologický dluh.

Re:Online IDE pro Javu s možností debugování
« Odpověď #132 kdy: 06. 08. 2016, 09:11:28 »
Pokud na takovém projektu pracuje víc než jeden vývojář, tak skutečně musí být velmi zajímavou prací řešení kolizí na Gitu. Sledovat stovky změn souborů v každém commitu, to musí být také slušný zážitek. Tomu jistě bude odpovídat i kvalita komentů.
Není důvod, aby takhle vznikalo velké množství kolizí. A Git je právě výborný nástroj na to, že většinu potenciálních kolizí vyřeší sám, a pokud se někde vývojáři opravdu sejdou na stejném kódu, umožňuje to snadno vyřešit.

Nevím, proč by měl někdo sledovat stovky změn souborů v commitu. Že jde o refaktoring se dozvím z komentáře, a kontrolovat očima po IDE, že to provedlo správně, to opravdu nemusím.

dustin

Re:Online IDE pro Javu s možností debugování
« Odpověď #133 kdy: 06. 08. 2016, 09:26:39 »
Jestli to byla narážka na můj příspěvek, tak za prvé, nejsem profesionální vývojář,

Pak asi neřešíš rozsáhlé projekty, o kterých je tu řeč a nepotřebuješ to.

Citace
zeptej se, na čem lidi běžně pracují

To je věc každého, co si pořídí. Nebo jejich vedení. Hardware lze dnes pořídit téměř zadarmo, v porovnání s platem vývojářů.

Citace
ukaž mi tu profi stanici za ty peníze.

Velice snadno, tady jsem ji včera popisoval http://forum.root.cz/index.php?topic=13639.msg174011#msg174011. Jen se DIMMy nakombinují 7x16GB + 2 x 8GB a cena se do 20k bez DPH vejde.

Citace
Co s týče tvého cvičení s projektem, asi je něco špatně, pokud každý vývojář potřebuje takové věci dělat několikrát za hodinu

Nepsal jsem, že několikrát za hodinu mění metody objektů použitých skrz celý projekt, ale že pořád dokola používá funkce na přejmenování/přesuny/rozpad do metod atd. Vývoj je přece iterativní, hrubá kostra, a pak se to dolaďuje, zjednodušuje, upravuje tak, aby šlo využít na více místech. To vše klidně v rámci pár tříd, které ve finálu vyřeší požadavek, na kterým zrovna dělám. A částí, na kterých dělají ostatní, se to nijak netýká.

Citace
a docela by mě zajímalo, jak se dá takhle fungovat v týmu. To musí být asi na každého vývojáře dva až tři lidi, kteří řeší správu gitu, ne?

Co konkrétně myslíš pod "lidi, kteří řeší správu gitu"? Git si samozřejmě řeší každý vývojář sám, dělá si commity, pravidelně stahuje commity z centrálního repo a když to své má hotové (od jednoho do třeba i sto commitů, ale to už by určitě dělal do větve), pushne to ostatním na centrální repo. Ano, může dojít ke konfliktu, ale od toho tam sedí spolu, aby si to pořešili. V praxi k tomu dochází zcela minimálně a je to standardní součástí týmového vývoje.

Překvapuje mě, jak se tady lidi brání čištění/aktualizaci kódu. Už jen tím, že se brání nástrojům, které jim to dovolí. Přitom to je to, na čem celý den dělají, s čím žijí. A dělat celý den na bordelu, to je přece smutný život.

Je pravda, že tenhle zcela zásadní aspekt práce vývojáře se na vejškách takřka neřeší. Zřejmě proto, že učitelé sami na žádných větších projektech nikdy nedělali a nemuseli se tím nikdy zabývat. Ale já to považuju za úplně zásadní, zcela stejně důležité jako správnou funkčnost. Přijde mi, že by tohle mělo být součástí profesní hrdosti vývojáře - když se na můj finální (tj. commitovaný) kód podívám, musím z něj mít radost a jo, být na něj trochu hrdý. Sračka typu "je to jedno, hlavně že to funguje a splnil jsem tak zadání" musí dlouhodobě lézt na mozek.

Navíc jsem ten, kdo ten vývojový tým ve své firmě platí, takže mám sakra velký zájem, aby výsledný kód měl dlouhodobou hodnotu, a nejenom jednorázový bastl, který pak vyhodím a zaplatím někomu jinému za napsání znovu.

Kit

Re:Online IDE pro Javu s možností debugování
« Odpověď #134 kdy: 06. 08. 2016, 09:40:35 »
Překvapuje mě, jak se tady lidi brání čištění/aktualizaci kódu. Už jen tím, že se brání nástrojům, které jim to dovolí. Přitom to je to, na čem celý den dělají, s čím žijí. A dělat celý den na bordelu, to je přece smutný život.

Tady se přece nikdo nebrání čistění/aktualizaci kódu. Jen se pozastavujeme nad tím, že všechny zde uvedené ukázky dělají ze špinavého kódu úplně stejně špinavý kód. A takové "čistění" opravdu dělat nemusím.