ugrás a tartalomhoz

Stop Refactoring!

Joó Ádám · 2012. Júl. 10. (K), 16.06
A túl feszes kódot nehéz módosítani
 ■
1

Egyetértek

Hidvégi Gábor · 2012. Júl. 11. (Sze), 13.00
Egy ideje már a számítástechnikában minden aktuális divatirányzatot fenntartásokkal kezelek, annál inkább, minél agresszívebben reklámozzák. A tapasztalataim azt mutatják, amire az előadó is rámutat, hogy ezek a dolgok persze lehetnek hasznosak, de nem lehet mindenre ráhúzni őket, és néha inkább hátrányt jelentenek, mint előnyt.

Ettől függetlenül persze érdemes mindent kipróbálni, minél többet tanulni, mert sok jó dolgot is lát az ember.

A munkámban a kód refaktorálása után hasonló problémákba ütköztem én is, mint ami az előadásban elhangzik, később újra elő kellett venni a biztonsági mentést, és abból újra kellett mazsolázni bizonyos részeket.

Valamennyire analóg probléma, hogy – főleg egy nagyobb, változó projekt esetén – tervezni is csak korlátok között lehet, mert sokminden fejlesztés közben derül ki.
2

Máséval a csalánt? :-)

eddig bírtam szó nélkül · 2012. Júl. 11. (Sze), 13.30
Szóval lehet, hogy ezt teszem, de mióta olvasgatom (nagyon felszínesen, teszem hozzá!) a szakirodalmat, egyre inkább el tudom fogadni ezt a munkamódszert.
Persze csak azt, amit eddig láttam belőle: teszt írás, alkalmazás írás, tesztelés, javítás/refactoring, goto 1.
Ha a refaktorálás ennek megfelelően történik és jók a tesztek is, akkor érzésem szerint nem nagyon lehet szükség biztonsági mentésre. No és... lehet, hogy én használom rosszul a verziókezelőt, de amikor épp használom, akkor úgy, hogy minden kisebb módosítás után commit, aztán ha valamit el...tem, akkor csak a git-ből kell visszahúzni az eredeti állapotot.
3

Nincs a refaktorálással

Hidvégi Gábor · 2012. Júl. 11. (Sze), 13.44
Nincs a refaktorálással probléma, az előadás tanulsága a számomra inkább az, hogy ésszel kell használni.
4

Egy off kérdés csak a gitel

Karvaly84 · 2012. Júl. 11. (Sze), 14.14
Egy off kérdés csak a gitel kapcsolatban:

Most kezdtem el használni a gitet (pár napja), elég bátortalanul nyúlok hozzá mert idegen nekem a sok paraméter és parázok nehogy elcsesszem. Még szerencsére nem csesztem el nagyon semmit, de ami késik nem múlik és a visszaállítás nem tiszta nekem.

Ha módosítok valamit, commitolok a helyi repoba, aztán módosítok és elcsesztem... Ekkor gondolom a checkout fájlnév és vissza áll a fájl. De ami visszaáll az honnan áll vissza? A helyi repo utolsó commitja alapján, vagy a közponi repo utolsó pushja alapján?
5

tárolva

Poetro · 2012. Júl. 11. (Sze), 14.52
A helyi repóban az összes kommit benne van, ami eddig történt, azaz akár mikor visszaállhatsz akár melyik verzióra. A Git esetén nincsen központi repo.
6

Én fogalmazhattam hülyén.

Karvaly84 · 2012. Júl. 11. (Sze), 15.19
Én fogalmazhattam hülyén. Helyi repo alatt a .git-en belüli adatbázist értem, ami elvileg tárolja a commitokat, és push-nál felküldi a repoba. Ha most jól fogalmazok.

Nekem azért nem tiszta mert subversion-t használtam eddig, és ott a commit egyből a repoba megy, és onnan is állítom vissza ha egy régebbi verzió kell, viszont itt gitben nem találkoztam a revision kifejezéssel. Tehát ezért nem tudom, hogy megy ez erre fele. Nagyon neten se találtam olyan esetet amikor egy elcseszett fájlt kéne visszaállítani egy korábbi állapotra, mondjuk arra az állapotra mielőtt hozzányúltam volna.
7

A git teljesen másképp

Poetro · 2012. Júl. 11. (Sze), 15.26
A git teljesen másképp működik, mivel nincs központi repo, hanem mindenkinél van egy teljes értékű repo, ettől distributed. A push / pull egy másik ugyan úgy teljes értékű repo-val kommunikál, mint a tiéd, azaz a kettő nincs egymás alá / fölé rendelve, mindkettő önállóan képes működni. Azaz amikor te a saját repodban kommitolsz, akkor az bekerül a te saját repodba. Majd ezeket a kommitokat tudod bemergelni másik repokba a push segítségével, és a másik repo módosításait tudod bemergelni a saját repodba a pull segítségével. A pull ugyanis egy git fetch és git merge kombinációja.

Git Basics - Undoing Things
8

A legrosszabb, amit tehetsz

saxus · 2012. Júl. 11. (Sze), 18.52
Szerk: bocs, nem olvastam a lentebbi kommenteket, de most már nem törlöm ki.


A legrosszabb, amit tehetsz az a checkout + felülírás. Ugyan én SVN irányából tudom neked mondani, gitből eddig csak kihúznom kellett adatokat, de a lényeg az az:

- Ha helyi munkamásolaton dolgozol, akkor csak simán reverteled és visszaállsz az utolsó commitolt állapotra.
- Ha már commitoltad, akkor (SVN-ben) reverse merge van rá, amivel vissza lehet vonni a commitolt módosításokat. Gitben tudtommal megteheted azt is, hogy a helyi repód vonod vissza, aztán amit csináltál azt nem pusholod a master repóba, ha már pusholtad, nem tudom hogy szokás, de gondolom van rá valami.
- Ha csak kísérletezni akarsz, akkor csinálj külön branchot rá. Git-tel ez úgy is egyszerű.
9

Ha már commitoltad és ment a

bugadani · 2012. Júl. 14. (Szo), 20.42
Ha már commitoltad és ment a push, elég revertelni helyileg és pusholni újra.