Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: Marti 29. 06. 2017, 20:38:07
-
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?
-
Mercurial.
-
Pochopit git se urcite vyplati. Mercurial je o chlup mene slozity, pokud ti to pomuze. Ale take o dost mene rozsireny.
-
Git je skvělý. Čím dříve se ho naučíš, tím lépe. Bez jeho znalosti těžko budeš hledat zaměstnání mezi programátory. Jako úložiště je vhodný třeba bitbucket.org.
Zkus Dropbox. Moc se na to sice nehodí, ale na školní projekt to může stačit.
-
Git je základ https://netbeans.org/kb/docs/ide/git.html
-
Zjisti si, jestli třeba nenabízí i škola možnost zřízení vlastního reportáže.
FI MUNI má gitlab a v gitu synchronizuješ jedním příkazem. Rozhodně se vyplatí se jej naučit.
-
Někdo ze spolužáků používá GIT, ale mě se to celé zdá docela složité-neexistuje nějaká jednoduší možnost?
Tak to vzdej. Jestli nedas ani git a jeho pet zakladnich prikazu(init, add, commit, push, pull) tak nema cenu se neco dalsiho ucit. Na dalsi srandy jako je branching model ala gitflow prijdes az se dostanes do tymu.
Bez gitu si ani neprdnes - krome par obsolete veci ktere maji historii nekolik desetileti na svn dneska nenajdes moc projektu ktery by git nepouzivaly.
Jestli jsi na win/macu tak nemusi byt spatny pouzit ksicht s nazvem SourceTree.
-
Někdo ze spolužáků používá GIT, ale mě se to celé zdá docela složité-neexistuje nějaká jednoduší možnost?
Tak to vzdej. Jestli nedas ani git a jeho pet zakladnich prikazu(init, add, commit, push, pull) tak nema cenu se neco dalsiho ucit. Na dalsi srandy jako je branching model ala gitflow prijdes az se dostanes do tymu.
Bez gitu si ani neprdnes - krome par obsolete veci ktere maji historii nekolik desetileti na svn dneska nenajdes moc projektu ktery by git nepouzivaly.
Jestli jsi na win/macu tak nemusi byt spatny pouzit ksicht s nazvem SourceTree.
SVN a několik desetiletí? Je z roku 2000...
-
Nauc se git. Na zaklady ktery ti ted budou stacit si vystacis s nekolika prikazy. Kod muzes mit na githubu, pro studenty maji zdarma i privatni repozitare (nebo za me to tak bylo).
-
Aj keď to zaznelo už viac krát, odporúčam git.
Repozitár mám potom hostovaný na githube.
Alebo, ak ide o repozitár, ktorý nechcem aby opustil hranice mojej siete:
1) Dedikovaný git server v domácej sieti
2) Domáce NAS-ky (napr. Synology) majú git plugin. Na rozbehnutie repozitári ti stačí pár klikov.
-
Radši nedělej nic a vyučujícímu vzkaž, že když po vás chce "rozsáhlejší projekt", mel vás nejdřív naučit, jak se o něj starat.
-
Pokud se vám zdá Git složitý, můžete zkusit začít Mercurialem, který je o něco jednodušší, a Git se naučit až později. Na druhou stranu, dříve jsem Mercurial aspoň občas potkal, ale mám pocit, že teď už ho Git úplně převálcoval. Každopádně na Git i Mercurial můžete použít BitBucket (https://bitbucket.org/), máte tam zdarma i privátní repository a máte to uložené na centrálním serveru, ze kterého budete jen jednotlivé pracovní stanice synchronizovat. Nevím, jak vypadá Git nebo Mercurial klient v NetBeans, každopádně jak už tu padlo, můžete pro Git i Mercurial použít grafického klienta SourceTree (https://www.sourcetreeapp.com/), který má pro BitBucket speciální podporu.
Používat to pak můžete úplně primitivním způsobem – naklonujete repository, před začátkem práce pomocí pull zaktualizujete lokální repository, po dokončení práce commitnete a pushnete změny do vzdáleného repository. Nemusíte řešit žádné branche nebo tagy, ani pullrequesty, když budete na projektu dělat sám, nemusíte řešit žádné konflikty, rebase nebo patche. Prostě jen pull a commit+push
-
Radši nedělej nic a vyučujícímu vzkaž, že když po vás chce "rozsáhlejší projekt", mel vás nejdřív naučit, jak se o něj starat.
Ono to "rozsahlejsi" bude asi dost subjektivni...
-
Zaloz si projekt na githubu (zdarma) a ten nabízí i subversion
-
Zaloz si projekt na githubu (zdarma) a ten nabízí i subversion
Nechapu, jak si se svn pomuze. Je to (subjektivne) na pouziti slozitejsi nez git, o mercurialu nemluve.
-
Zaloz si projekt na githubu (zdarma) a ten nabízí i subversion
Nechapu, jak si se svn pomuze. Je to (subjektivne) na pouziti slozitejsi nez git, o mercurialu nemluve.
No, není... Na rozdíl od gitu se nemusí potýkat s dvojím "commitovanim" (commit a push) a kolikrát pro nováčka nepochopitelný různý stavy lokálního repozitaře) dokud nemusí intenzivně mergovat a vytvářet branche, tak to stačí. Navíc github má právě tu skvělou vlastnost že k jednomu repozitaři má dva protokoly (svn a git) takže přejít na git je hračka
Pro svn ideálně TortoiseSVN, pro git určitě SourceTree
-
dropbox, googledisk, onedrive, ....
-
dropbox, googledisk, onedrive, ....
Proč by to kdo používal na zdrojáky?
- Diff nevidí (pokud si ročně někam nezkopíruje starší verzi a ručně si nenakliká cesty třeba do WinMerge)
- Historii si musí psát bokem nebo pamatovat
- Když na obou místech změní soubor, musí to řešit ručně
- ...
To je jako šroubovat vruty kombinačkama. Používejme nástroje na to, k čemu jsou určeny.
-
Zaloz si projekt na githubu (zdarma) a ten nabízí i subversion
Nechapu, jak si se svn pomuze. Je to (subjektivne) na pouziti slozitejsi nez git, o mercurialu nemluve.
No, není... Na rozdíl od gitu se nemusí potýkat s dvojím "commitovanim" (commit a push) a kolikrát pro nováčka nepochopitelný různý stavy lokálního repozitaře) dokud nemusí intenzivně mergovat a vytvářet branche, tak to stačí. Navíc github má právě tu skvělou vlastnost že k jednomu repozitaři má dva protokoly (svn a git) takže přejít na git je hračka
Pro svn ideálně TortoiseSVN, pro git určitě SourceTree
Pridavam sa, subversion je o trochu jednoduchsi. Radim naucit sa ho ovladat z command line, je to jednoduchsie, nez sa zda. Clovek potom nie je namydleny, ked nema podporu roznych klikatok a IDE.
-
Skompresovat cely projektovy adresar a hodit to na usb. Moze to sluzit aj ako urcita forma zalohy dennej prace.
Pre serioznu pracu doporucujem precitat si nejaky "git za 5 minut" kurz a vytvorit konto na nejakom free serveri gitovych repozitarov (Github / Gitlab / Atlassian Bitbucket). Github a Atlassian maju pre windowsy GUI klientov na pracu s ich repozitarmi. Linky najdes tu https://git-scm.com/download/gui/windows pre linux potom na https://git-scm.com/download/gui/linux a mac tam maju tiez.Pre windows by som pouzil Atlassian SourceTree, pre linux git-cola alebo Git Kraken.
Vacsina IDE prostredi vie komfortne pracovat s gitom, ale prikazovy riadok ti po case poskytne vacsiu efektivitu. V podstate len 5 prikazov:
- git clone pre prvotne skopirovanie projektu zo servera
- git push pre poslanie zmien na server
- git pull pre stiahnutie zmien zo servera
- git status na zoznam novych alebo zmenenych suborov na disku
- git commit pre ulozenie zmien a pripravu na push na server
Ked na tom bude robit len jeden clovek a len na striedacku na dvoch strojoch tak nebudu nastavat ani konflikty ktory by bolo treba riesit mergovanim.
-
SVN je jednodušší asi tak prvních pět minut.
V okamžiku, kdy se svn něco uděláš špatně - což může bejt i tak jednoduchá věc, jako že si uděláš kopii podadresáře v projektu (čímž zkopíruješ i informace svn, čímž si to celý rozbiješ) - a začneš to opravovat, tak najednou zjistíš, že na první pohled "jednoduchej ksicht" SVN je více než draze vykoupenej.
Jako uživatel jak SVN (naštěstí bývalý), tak Gitu bych "zpřelámal hnáty" :-) každému, kdo si dovolí doporučovat SVN. Nebo ať to není tak agresivní, takového člověka bych přinutil do konce života používat SVN. To by byl ještě horší trest.
-
SVN jeslti se nepletu už od nějaký hodně dávný verze má jen jeden hlavní adresář .svn (stejěn jako .git)
SVN je jednodušší asi tak prvních pět minut.
V okamžiku, kdy se svn něco uděláš špatně - což může bejt i tak jednoduchá věc, jako že si uděláš kopii podadresáře v projektu (čímž zkopíruješ i informace svn, čímž si to celý rozbiješ) - a začneš to opravovat, tak najednou zjistíš, že na první pohled "jednoduchej ksicht" SVN je více než draze vykoupenej.
Jako uživatel jak SVN (naštěstí bývalý), tak Gitu bych "zpřelámal hnáty" :-) každému, kdo si dovolí doporučovat SVN. Nebo ať to není tak agresivní, takového člověka bych přinutil do konce života používat SVN. To by byl ještě horší trest.
-
Jo, to je možný, od svn jsem s radostí utekl už před pár lety - teď koukám, že todle opravdu fixly v 1.7 už před pár lety. Ale to není jedinej problém se svn, jen ilustrace toho, jaký pakárny musel člověk se SVN řešit.
To, že polovinu z nich pravděpodobně opravili je dosti možné, ale oproti gitu je SVN "broken by design" - spousta věcí tam opravit jednoduše nejde. Další co si vzpomínám byla např. nemožnost zrušit commit, prapodivný systém větví atd. atd. atd. Git má mírně složitější základní princip - ale díky tomu u něj všechno funguje ve výsledku "normálně". SVN je napohled jednoduchá - a díky tomu polovinu běžně používanejch věcí řeší různejma "obezličkama".
-
Zaloz si projekt na githubu (zdarma) a ten nabízí i subversion
Nechapu, jak si se svn pomuze. Je to (subjektivne) na pouziti slozitejsi nez git, o mercurialu nemluve.
Na pochopení je přímočařejší než distribuované VMS...
-
Zaloz si projekt na githubu (zdarma) a ten nabízí i subversion
Nechapu, jak si se svn pomuze. Je to (subjektivne) na pouziti slozitejsi nez git, o mercurialu nemluve.
Na pochopení je přímočařejší než distribuované VMS...
Mam repo na githubu a nekolik jeho klonu na nekolika stanicich, ktere maji jako remote ten github a nevedi o sobe. V cem je git slozitejsi (mimo toho, ze mam zvlast commit a push, coz je IMO vyhoda)?
-
Mozna to uz dneska nejak funguje, ale v dobe kdy jsem byl nucen ten kripl pouzivat tak "svn commit" v offline rezimu nebylo neco co by clovek chtel resit.
Kazdymu kdo poradi novackovi SVN bych za trest nechal jen SVN na veky veku. Tenhle nechtenej bastard mel davno chcipnout - je to neco jako Joomla: neni doby vubec na nic.
-
Seafile + git. V práci něco napíšu, na notebooku mám to samé, jelikož syncám i nastavení idečka, tak se mě doma otevře idečko ve stejném stavu co sem ho zavřel v práci. Po dokončení úprav pochopitelně přijde na scénu git. Lepší řešení sem nenašel. Git by sice postačil, ale to bych do něj musel dávat i nekompletní nedodělané věci, což běžně nedělám.
-
Pokud někomu přijde Git a Mercurial složitý, můžete začít s fossilem http://fossil-scm.org/ (http://fossil-scm.org/) :) Pak lze mít repositář na serveru (spustí se triviálně) nebo na usb flash, pokaždé to je jen jeden sqlite soubor, základní ovládání je podobné jako u gitu a možnosti jsou podobné. Není tak rozšířený, ale pro řadu použití mi přijde dost praktický. Přechod na git je pak otázkou naučit se dalších 5 příkazů. Pro složitejší případy použití se pak sice už liší víc, ale tak daleko tazatel není. Jedinou relativní nevýhodou je nulová podpora v IDE a použití z příkazové řádky.
https://www.slant.co/topics/370/versus/~git_vs_mercurial_vs_fossil (https://www.slant.co/topics/370/versus/~git_vs_mercurial_vs_fossil)
-
Nemecek: Pokud někomu přijde git složitý, ať nezačíná s programováním.... :-)
Ondrej: IMHO rozumější je se naučit si commitovat i rozdělanou práci. Takže bych toto nedoporučoval jako první volbu.
-
Nemecek: Pokud někomu přijde git složitý, ať nezačíná s programováním.... :-)
Ondrej: IMHO rozumější je se naučit si commitovat i rozdělanou práci. Takže bych toto nedoporučoval jako první volbu.
A důvod? Každopádně je to hlavně o tom, že se mě přenáší nastavení idečka, čili tam kde sem ho zavřel na jednom PC, otevřu ho na druhém, to je pro mě hlavní výhoda...
-
To asi záleží na stylu práce no, znám maníky kteří commitují každou řádku. Já nevím asi by se mělo commitovat po nějakých logických celních jenže často pracuji na několika věcech současně takže někdy ten logicky celek je na nekolik dní a zahrnuje několik velkých commitu.
Zejména na začátku vývoje používám sc nástroje na dílčí zálohování věci mimo mě PC (což offline samozřejmě nejde dělat) nebo přenášení dat mezi PC. Nechci řešit co je logicky celek, IDE mi poskytuje nekonečné undo a local history, tam chodím nejčastěji když hledám minule úpravy. Commit uprostřed práce mne zdržuje a nevidím důvod, proc by někdo měl nakonec vidět dílčí kroky vzniku finálního kodu
-
Všechny verzovací nástroje mají jednu zásadní nevýhodu: pokud zapomenu v práci commit, tak jsem doma namydlenej. Používám nextcloud, historii souborů umí a nemusím se ani bát toho, že mi odejde disk. Soubor se synchronizuje chvilku po uložení, Do verzovacího systému commituju až odladěný kód.
-
Všechny verzovací nástroje mají jednu zásadní nevýhodu: pokud zapomenu v práci commit, tak jsem doma namydlenej. Používám nextcloud, historii souborů umí a nemusím se ani bát toho, že mi odejde disk. Soubor se synchronizuje chvilku po uložení, Do verzovacího systému commituju až odladěný kód.
Stalo se mi už několikrát, že jsem v práci zapomněl udělat commit. Jednoduše jsem doma pokračoval a pak jsem udělal merge. Žádný problém v tom nevidím, verzovací systémy mají tohle vychytané.
Odladěný kód se obvykle merguje až do větve master, ale do větve feature commituji po udělání každého logického celku, i kdyby to byl jen jeden řádek. Komentář ke commitu tak může být klidně i delší, než samotná úprava zdrojáku. Je docela hloupé v jednom commitu komentovat několik nezávislých změn - je to pak nepřehledné a blbě se dělají reverty.
Dropbox, Google Disk a Mega.nz používám spíš na dokumenty, které není potřebné verzovat.
-
To asi záleží na stylu práce no, znám maníky kteří commitují každou řádku. Já nevím asi by se mělo commitovat po nějakých logických celních jenže často pracuji na několika věcech současně takže někdy ten logicky celek je na nekolik dní a zahrnuje několik velkých commitu.
Pokud je ten logický celek na delší dobu než cca hodinu, je příliš velký a je nutné ho rozdělit na menší. Modifikace by se měly dělat pokud možno v jednom souboru, commity jsou pak mnohem jednodušší a přehlednější.
Velkou bolestí programátorů bývá neschopnost rozdělit problém na několik menších, které se pak dělají postupně jeden po druhém tak, aby ty změny byly na sobě nezávislé.
-
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.
-
Kit žije asi v nějakém ideálním světě co my ostatní ne :-( Tak jak to popisuješ by to bylo super, ale realita je z různých důvodů mnohdy jiná.
-
Všechny verzovací nástroje mají jednu zásadní nevýhodu: pokud zapomenu v práci commit, tak jsem doma namydlenej. Používám nextcloud, historii souborů umí a nemusím se ani bát toho, že mi odejde disk. Soubor se synchronizuje chvilku po uložení, Do verzovacího systému commituju až odladěný kód.
Nad nextcloudem sem taky přemejšlel, ale seafile mě přijde dospělejší. Umí už next/own cloud rozumně verzovat?
-
Kit hlavně nedělá žádné větší projekty a kompilovatelnost v PHP neřeší.
-
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.
-
Tak já převážně dělám většinou v Pythonu, čili v tomhle obdoba PHP, ale i tak mě tenhle přístup přijde mimo realitu. Bohužel. Ale asi záleží pro koho a co děláš.
-
Kit hlavně nedělá žádné větší projekty a kompilovatelnost v PHP neřeší.
Kompilovatelnost v PHP řeším nejen po sobě, ale i po ostatních. Fatal errory na produkci si nemůžeme dovolit asi nikdo.
-
Tak já převážně dělám většinou v Pythonu, čili v tomhle obdoba PHP, ale i tak mě tenhle přístup přijde mimo realitu. Bohužel. Ale asi záleží pro koho a co děláš.
Bohužel je ten projekt tak velký, že si nemůžeme dovolit dělat hromadné změny plné vnitřních závislostí, po kterých by se to mohlo rozsypat. Nároky na atomizaci změn jsou u nás docela přísné.
-
Nauč se Git, to se ti bude hodit.
Začni třeba tady https://www.learnenough.com/git-tutorial
-
Problémem GITu je jeho "nízkoúrovňovost" a nutnost znát jeho střeva k pochopení spousty pokročilejších příkazů. Je tedy třeba se více zaměřit na to, "jak" něčeho dosáhnout. Naopak v Mercurialu a SVN většinou stačí vědět, "čeho" chci dosáhnout.
Z těchto rozdílů také vyplývá pojmenování příkazů a jejich parametrů, které jsou v GITu zaměřeny na "postup" a nikoliv na "výsledek". V SVN nebo Mercurialu například chci revert lokálních změn, udělám tedy "revert". Hotovo. V GITu poněkud nelogicky nepoužiji "revert" (ten navíc dělá něco jiného), ale "reset", protože přeci nebudu dělat jen prachsprostý revert lokálních změn, ale budu muset přemýšlet nad tím, že tam mám nějaký "index" (staging area) a pointery na commity atd. A aby se to nezdálo tak jednoduché, tak ještě musím řešit, zda náhodou nepoužít nějaký z přepínačů typu "--soft" a "--hard". Prostě nebylo možné mít jediný příkaz "revert" s několika vhodně pojmenovanými parametry.
Ano, GIT je flexibilnější v případech, že se chci opravdu pošťourat ve vnitřnostech, ale kolikrát za rok něco takového potřebuji, a musí to být na úkor komfortu běžného používání? Nejen pro začátečníka to může být dost frustrující.
-
Problémem GITu je jeho "nízkoúrovňovost" a nutnost znát jeho střeva k pochopení spousty pokročilejších příkazů. Je tedy třeba se více zaměřit na to, "jak" něčeho dosáhnout. Naopak v Mercurialu a SVN většinou stačí vědět, "čeho" chci dosáhnout.
Tato nízkoúrovňovost Gitu však umožňuje tvorbu různých nadstaveb a doplňků do IDE s mnohem větší variabilitou, než mají konkurenční VCS. I v samotném Gitu je možné si snadno vyrobit vlastní sadu maker dostupných nejen z příkazové řádky. Dají se dědit, překrývat i přetěžovat. Jistěže dá trochu práce se tyto finesy naučit, ale začátečník to moc nepotřebuje a pokročilý si na to ten čas najde, protože to ušetří hromadu ruční práce.
-
Iba jeden človek? Čo takto programovať priamo na usb klúči, alebo externy hdd?
-
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.
-
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
-
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.
-
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
git checkout soubor
-
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.
-
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.
-
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í)
-
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é.
-
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.
-
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).
-
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ý.
-
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
-
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.
-
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í.