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

[dustin]

Jenže tím čištěním je např. přejmenování metody na konkrétní název místo nic neříkajícího "update", příp. vnitřní rozdělení metody update na tři updateA, updateB, updateC, která každá řeší to své a podle toho se jmenuje. Nic z toho ve vimu neuděláš. A vim používám od r. 2000, psal jsem v něm svého času docela rozsáhlé PHP (v té době žádné IDE pro PHP nebylo), takže ho trochu znám a nedám na něj dopustit.

[Reklama]

[Kit]

Jenže tím čištěním je např. přejmenování metody na konkrétní název místo nic neříkajícího "update", příp. vnitřní rozdělení metody update na tři updateA, updateB, updateC, která každá řeší to své a podle toho se jmenuje. Nic z toho ve vimu neuděláš. A vim používám od r. 2000, psal jsem v něm svého času docela rozsáhlé PHP (v té době žádné IDE pro PHP nebylo), takže ho trochu znám a nedám na něj dopustit.

To je právě chyba, protože ty tři update mají být a.update(), b.update(), c.update() podle toho, na který objekt ten update děláš. Na první pohled tak vidíš, co updatuješ a navíc přitom můžeš využít polymorfismu.

[Filip Jirsák]

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.

To je ale nepochopení refaktoringu. Refaktoring není zlepšování kódu. Refaktoring je příprava kódu na to, abych ho mohl zlepšit. Třeba to přejmenování metody samo o sobě samozřejmě kód nezlepší. Ale umožní mi to třeba vedle vytvořit novou metodu, která bude dělat něco podobného, jako ta původní - a přejmenováním je od sebe dokážu odlišit. Nebo to vytažení části implementace do předka (nebo jenom vytvoření abstraktního předka) mi umožní využít společný kód i v dalších třídách.

[Kit]

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.

To je ale nepochopení refaktoringu. Refaktoring není zlepšování kódu. Refaktoring je příprava kódu na to, abych ho mohl zlepšit. Třeba to přejmenování metody samo o sobě samozřejmě kód nezlepší. Ale umožní mi to třeba vedle vytvořit novou metodu, která bude dělat něco podobného, jako ta původní - a přejmenováním je od sebe dokážu odlišit. Nebo to vytažení části implementace do předka (nebo jenom vytvoření abstraktního předka) mi umožní využít společný kód i v dalších třídách.

Souhlasím, že refaktoring je přípravou na redesign.

Vytažení části implementace do předka dělám obráceně: Současná třída se stane předkem a k ní pak dělám potřebné množsví potomků, ve kterých překryji implementace některých metod. Předka nahrazuji potomkem jen tam, kde to skutečně potřebuji. Dopad na zbytek kódu aplikace je tak minimální.

[Filip Jirsák]

Vytažení části implementace do předka dělám obráceně: Současná třída se stane předkem a k ní pak dělám potřebné množsví potomků, ve kterých překryji implementace některých metod. Předka nahrazuji potomkem jen tam, kde to skutečně potřebuji. Dopad na zbytek kódu aplikace je tak minimální.

Každé je ale něco jiného. Ze současné třídy dělám předka tehdy, když ji potřebuji dál specializovat. Jiný případ je, když už speciální třídu mám, ale obsahuje v sobě i obecný kód - protože původně byla specializovaná třída jen jedna a nebyl důvod psát předka jen tak do foroty. Pak z té třídy potřebuju vytáhnout do předka jenom tu obecnou část a speciální ponechat.

[Reklama]

[Kit]

Vytažení části implementace do předka dělám obráceně: Současná třída se stane předkem a k ní pak dělám potřebné množsví potomků, ve kterých překryji implementace některých metod. Předka nahrazuji potomkem jen tam, kde to skutečně potřebuji. Dopad na zbytek kódu aplikace je tak minimální.

Každé je ale něco jiného. Ze současné třídy dělám předka tehdy, když ji potřebuji dál specializovat. Jiný případ je, když už speciální třídu mám, ale obsahuje v sobě i obecný kód - protože původně byla specializovaná třída jen jedna a nebyl důvod psát předka jen tak do foroty. Pak z té třídy potřebuju vytáhnout do předka jenom tu obecnou část a speciální ponechat.

Třídu prohlásím za předka. Z tohoto předka vyjmu speciální část a vložím do potomka. V předkovi je nahradím obecnějšími nebo abstraktními metodami, abych neporušil LSP.

Pokud ta tvá třída obsahuje obecný kód, zamyslel bych se spíš nad kompozicí než nad dědičností. Tím se ten tvůj kód stane mnohem obecnějším, protože nebude fixován na jednu třídu.

[Filip Jirsák]

Třídu prohlásím za předka. Z tohoto předka vyjmu speciální část a vložím do potomka.

V tomhle okamžiku jste rozbil veškerý kód, který na té speciální části závisel.

[javaman (však vy víte)]

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.

Proč kolegové? Prostě je tam nějaký code review a když lopata pořád nechápe, co je kvalita, tak má smůlu. Kolega si o tom může promluvit, ale pokud chce prasit a nevadí mu to, tak je asi ve špatném týmu. Fungování není žádný argument. Fungovat může i úplná sračka, kterou nikdo nebude chtít vylepšovat.

[Kit]

Třídu prohlásím za předka. Z tohoto předka vyjmu speciální část a vložím do potomka.

V tomhle okamžiku jste rozbil veškerý kód, který na té speciální části závisel.

Nerozbil jsem nic.

[javaman (však vy víte)]

Jenže tím čištěním je např. přejmenování metody na konkrétní název místo nic neříkajícího "update", příp. vnitřní rozdělení metody update na tři updateA, updateB, updateC, která každá řeší to své a podle toho se jmenuje. Nic z toho ve vimu neuděláš. A vim používám od r. 2000, psal jsem v něm svého času docela rozsáhlé PHP (v té době žádné IDE pro PHP nebylo), takže ho trochu znám a nedám na něj dopustit.

To je právě chyba, protože ty tři update mají být a.update(), b.update(), c.update() podle toho, na který objekt ten update děláš. Na první pohled tak vidíš, co updatuješ a navíc přitom můžeš využít polymorfismu.

WTF? Jaký objekt? Volám ty metody na rozhraní service. Nebudu snad zbytečně nějak jinak pojmenovávat service, protože mám rád jednoslovné proměnné, ne? Žádné coolSafeICanEverythingServiceWithoutProblemsTryMe

[Kit]

Jenže tím čištěním je např. přejmenování metody na konkrétní název místo nic neříkajícího "update", příp. vnitřní rozdělení metody update na tři updateA, updateB, updateC, která každá řeší to své a podle toho se jmenuje. Nic z toho ve vimu neuděláš. A vim používám od r. 2000, psal jsem v něm svého času docela rozsáhlé PHP (v té době žádné IDE pro PHP nebylo), takže ho trochu znám a nedám na něj dopustit.

To je právě chyba, protože ty tři update mají být a.update(), b.update(), c.update() podle toho, na který objekt ten update děláš. Na první pohled tak vidíš, co updatuješ a navíc přitom můžeš využít polymorfismu.

WTF? Jaký objekt? Volám ty metody na rozhraní service. Nebudu snad zbytečně nějak jinak pojmenovávat service, protože mám rád jednoslovné proměnné, ne? Žádné coolSafeICanEverythingServiceWithoutProblemsTryMe

V daném případě jsem použil objekty a, b, c podle předlohy. Samozřejmě jednoznakové proměnné se až na výjimky nedoporučují. Také dávám přednost jednoslovním.

[Tuxik]

Tady se tak nějak zapomíná na základní otázku života, vesmíru a vůbec. Je agilní vývoj dobrý? A odpověď kupodivu není 42, ale je prostě a jednoduše NE. Nechám vás chvilku přemýšlet a potom dovysvětlím zoufalcům, proč není. Na druhou stranu uznávám, že to zní pro zákazníka dobře a zákazník to chce. Proč, na to si opět zkuste odpovědět nejdřív sami. Je to jeden z důvodů, proč jsem nikdy nechtěl být programátor.

[javaman (však vy víte)]

Agilní vývoj je přirozený. Občas lopaty zkoušely něco jiného, ale podle toho to dopadlo. Vývoj SW je jedna z nejnáročnějších disciplín vůbec a jinak než agilně nejde. Tak nám vysvětli, proč nemáš hlavu na to, abys vyvíjel?

[gl]

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.

Prosím odkaz na open source projekt, který má pár tisíc tříd. Používáme důsledně TDD. Změny které popisujete mohu provést snadno bez IDE. Jednu dobu jsem pracoval ve firmě, kde se řešilo pojmenování a architekura víc než funkčnost. K udržovatelnosti projektů to nevedlo. Spíš naopak.

[javaman (však vy víte)]

https://github.com/spring-projects/spring-framework