Sdílení zdrojových kódů mezi různými počítači

[pekand]

Iba jeden človek? Čo takto programovať priamo na usb klúči, alebo externy hdd?

[Reklama]

[dustin]

I u jednoho vývojáře je velice užitečné si ukládat historii vývoje do SCM. Např. vidím, čeho se právě vyvíjená funkcionalita týká, v jakých souborech/třídách atd. Vývoj je snazší, když se změny nemíchají do sebe, člověk se lépe soustředí na aktuální problém a ty předchozí už se mu nemotají pod ruce.

[Ondřej Novák]

Mimochodem jak v gitu udělám revert lokálních změn u jednoho souboru? To tedy možná to není dobře implementované v eclipse který to umí jen u svn. U gitu mi nabízí jen reset vseho. SourceTree to umí na úrovni hunků ale je to funkce jeho UI

[Ondřej Novák]

Pokud např. přejmenovávám public metodu, obykle to nebude změna jen v jednom souboru. Nevidím důvod, proč by se měla jedna fukční změna  (po které by měl zůstat projekt kompilovatelný), týkat jen jednoho souboru. Samozřejmě by commit neměl obsahovat více změn najednou, ale ne vždy to lze rozumně dodržet a není to dogma.

Nevidím důvod, proč bych měl přejmenovávat nějakou veřejnou metodu. To bych musel nejprve změnit rozhraní. Kromě toho jsem psal o modifikaci funkcionality, nikoli o refactoringu.

Ja nevím ale tvorba nové funkcionality je často pro mne permanentní refaktoring dokud se kód neusadí na všech místech. Poslední dobou tvořím kód který píšu několik dní aniž bych vyzkoušel, že aspoň část toho funguje, stačí, že to jde přeložit. Nestává se mi, že bych měl problém takový kód finálně odladit.

[gll]

Mimochodem jak v gitu udělám revert lokálních změn u jednoho souboru? To tedy možná to není dobře implementované v eclipse který to umí jen u svn. U gitu mi nabízí jen reset vseho. SourceTree to umí na úrovni hunků ale je to funkce jeho UI

Kód [Vybrat] Rozbalit


git checkout soubor


[Reklama]

[Kit]

Pokud např. přejmenovávám public metodu, obykle to nebude změna jen v jednom souboru. Nevidím důvod, proč by se měla jedna fukční změna  (po které by měl zůstat projekt kompilovatelný), týkat jen jednoho souboru. Samozřejmě by commit neměl obsahovat více změn najednou, ale ne vždy to lze rozumně dodržet a není to dogma.

Nevidím důvod, proč bych měl přejmenovávat nějakou veřejnou metodu. To bych musel nejprve změnit rozhraní. Kromě toho jsem psal o modifikaci funkcionality, nikoli o refactoringu.

Ja nevím ale tvorba nové funkcionality je často pro mne permanentní refaktoring dokud se kód neusadí na všech místech. Poslední dobou tvořím kód který píšu několik dní aniž bych vyzkoušel, že aspoň část toho funguje, stačí, že to jde přeložit. Nestává se mi, že bych měl problém takový kód finálně odladit.

Refaktoring nijak nesouvisí s "usazením na všech místech", protože nemění funkcionalitu.

Refaktoring musíme commitovat zvlášť, protože by se špatně dělal Code review.

[gll]

Ja nevím ale tvorba nové funkcionality je často pro mne permanentní refaktoring dokud se kód neusadí na všech místech. Poslední dobou tvořím kód který píšu několik dní aniž bych vyzkoušel, že aspoň část toho funguje, stačí, že to jde přeložit. Nestává se mi, že bych měl problém takový kód finálně odladit.

problém může nastat až po vás ten kód někdo zdědí. Bez testů nejde na první pohled poznat, co to má dělat.

[Ondřej Novák]

Ja nevím ale tvorba nové funkcionality je často pro mne permanentní refaktoring dokud se kód neusadí na všech místech. Poslední dobou tvořím kód který píšu několik dní aniž bych vyzkoušel, že aspoň část toho funguje, stačí, že to jde přeložit. Nestává se mi, že bych měl problém takový kód finálně odladit.

problém může nastat až po vás ten kód někdo zdědí. Bez testů nejde na první pohled poznat, co to má dělat.

No nevím ale testy píšu až potom, abych vyzkoušel všechny části kodu,. Aby člověk mohl psát test dopředu, musí mít přesný zadání. Takový luxus jsem neměl ani v Seznamu. Často klient nemá jasnou představu co vlastně chce. Vývoj produktu se pak realizuje jako opakovaná refaktorizace prototypu (a s tím souvisí snaha udržet testy konzistentní)

[Kit]

No nevím ale testy píšu až potom, abych vyzkoušel všechny části kodu,. Aby člověk mohl psát test dopředu, musí mít přesný zadání. Takový luxus jsem neměl ani v Seznamu. Často klient nemá jasnou představu co vlastně chce. Vývoj produktu se pak realizuje jako opakovaná refaktorizace prototypu (a s tím souvisí snaha udržet testy konzistentní)

To je jen výmluva. Když se používají správné postupy, tak ani velká změna v zadání nemusí představovat velkou změnu v kódu. Tedy když se dodržuje zvolené paradigma - ať OOP, FP či jiné.

[gll]

No nevím ale testy píšu až potom, abych vyzkoušel všechny části kodu,. Aby člověk mohl psát test dopředu, musí mít přesný zadání. Takový luxus jsem neměl ani v Seznamu. Často klient nemá jasnou představu co vlastně chce. Vývoj produktu se pak realizuje jako opakovaná refaktorizace prototypu (a s tím souvisí snaha udržet testy konzistentní)

Zrovna při častých změnách zadání se vyplatí mít zadání specifikované testy. Vždy je jasné, které zadání v daný moment platí. Dost se mi líbí přístup RSpec, který přímo vede ke psaní testů jako dokumentace.

[kimec]

Učíme se ve škole základy Javy (v Netbeansech), a dostala jsem na prázdniny za úkol, vytvořit nějaký rozsáhlejší projekt. Mám ve škole notebook, doma desktop a řeším, jak co nejjednodušeji zařídit, abych mohla programovat ten úkol na obou počítačích a nemusela celý projekt vždy překopírovávat z jednoho stroje na druhý. Někdo ze spolužáků používá GIT, ale mě se to celé zdá docela složité-neexistuje nějaká jednoduší možnost?

Zacal by som asi s tym, ci chete (bez ohladu na to kolko pocitacov mate) ukladat kod vasho letneho projektu do nejakeho verzionovacieho systemu alebo nie.

Ak nie a neplanujete sa ucit verzionovaci system toto leto, tak na transport kodu vasho projektu medzi pocitacmi pouzite USB kluc alebo hocaku cloudovu uloziskovu sluzbu (Dropbox, Google drive).

Naopak, ak chcete pouzit verzionovaci system, tak zvolte git. Avsak stale by som vam odporucil pouzit na prenos a ukladanie projektu USB kluc. Cloudove sluzby ako github a bitbucket by som vam neodporucal, pretoze zaciatocnikovi veci viac skomplikuju ako ulahcia. Kluc mozete mat stale so sebou, funguje bez internetu a je vam jedno kolko pocitacov budete pouzivat, plus budete mat zdrojaky v gite stale konzistentne a nebudete musiet riesit schyzofreniu s remotnymi vetvami, push, fetch, forced push atd.
S indexom a resetmi sa v single user mode ako zaciatocnik natrapite az az aj bez githubu.

Apropo, to, ze vas spoluziak git pouziva, nevypoveda nic o tom, ci nejaky kod zdiela a ci cez internet alebo na disketach (ak ste sa dostali az sem, pravdepodobne este slovencine rozumiete).

[Kit]

Naopak, ak chcete pouzit verzionovaci system, tak zvolte git. Avsak stale by som vam odporucil pouzit na prenos a ukladanie projektu USB kluc. Cloudove sluzby ako github a bitbucket by som vam neodporucal, pretoze zaciatocnikovi veci viac skomplikuju ako ulahcia. Kluc mozete mat stale so sebou, funguje bez internetu a je vam jedno kolko pocitacov budete pouzivat, plus budete mat zdrojaky v gite stale konzistentne a nebudete musiet riesit schyzofreniu s remotnymi vetvami, push, fetch, forced push atd.

USB klíčenka se dá využít i jako vzdálený repozitář (bare). Šetří se tím její životnost a data jsou na více místech. Pracovat editorem přímo na USB klíčence nedoporučuji.

Bitbucket bych s klidem doporučil. má několik zajímavých vlastností navíc a založení projektu je v něm velmi jednoduché i s návodem, jak s ním pracovat v Gitu.

Podobně i Github je dobře použitelný. gist.github.org je na ukládání nápadů jako stvořený.

[Ondřej Novák]

No nevím ale testy píšu až potom, abych vyzkoušel všechny části kodu,. Aby člověk mohl psát test dopředu, musí mít přesný zadání. Takový luxus jsem neměl ani v Seznamu. Často klient nemá jasnou představu co vlastně chce. Vývoj produktu se pak realizuje jako opakovaná refaktorizace prototypu (a s tím souvisí snaha udržet testy konzistentní)

Zrovna při častých změnách zadání se vyplatí mít zadání specifikované testy. Vždy je jasné, které zadání v daný moment platí. Dost se mi líbí přístup RSpec, který přímo vede ke psaní testů jako dokumentace.

Tak sem nahoďte nějaké URL kde máte nějaké zdrojaky které tak vyvíjíte , ať tady nezapleveluju diskuzi, já si to prostuduju abych věděl jak se to dělá jinde

[dustin]

Taky by mě to zajímalo. Nějak si to neumím v reálné praxi představit. Ze zadání by možná vyplývaly nějaké integrační testy, ale rozhodně ne unit testy na nízké úrovni.

[Lopata]

Tak nějak... obzvlášť u nějakých proof of concept implementací, kde ještě není pořádně známo ani technické, natož pak business řešení, nemá cenu unit testy psát. To bych je pak mohl přepisovat při každém uprdnutí (ale když má na to firma dostatek lopat...). Leda nějaký opravdu vysokoúrovňový test na udržení integrace a ověření základní funkčnosti, abych nemusel spouštět celou aplikaci.

A celkově mimochodem unit testy považuji pro většinu případů použití za překonané a zbytečně nákladné, protože jednak jsou jich mraky a při výraznějších změnách v kódu jich můžu většinu zahodit a napsat znova. Ale často jsou i nespolehlivé, protože každý takový test testuje jedno místo (metodu, funkci...) v kódu, ale nikoliv celek. Pokud pak má úplně jiná chyba na jiném místě stejný důsledek navenek, zákazník to může vnímat jako tutéž již v minulosti nahlášenou chybu, což vede ke ztrátě jeho důvěry. Vysokoúrovňové až integrační testy testující zároveň i širší kontext toto vcelku dobře řeší. Ale unit testy úplně nezavrhuji, pro některé testy exaktně definované logiky/algoritmů (typu řazení, hledání v grafu apod.) se samozřejmě hodí.