În urmă cu mulți ani am deschis un topic pe Stackoverflow (care a fost șters, dar webarchive funcționează ok) în care întrebam dacă eu, ca programator solo (cum eram pe atunci) chiar am nevoie de un VCS. Indiferent că-i vorba de Git, SVN sau orice altceva.
Între timp am adoptat SVN, iar după câteva luni am trecut la Git (la îndemnul mai mult sau mai puțin direct al lui @ct27stf). Și nu doar că folosesc, dar am devenit un fel de „evanghelist”, încercând să-i conving pe toți să folosească un VCS. Și orice proiect ar fi, oricât de mic, este pus în Git.
Dar unii programatori sunt destul de comozi în a renunța la flow-ul propriu (zip foo-2931239.zip bar.php pentru versionare). Cum ați reuși să convingeți un astfel de programator să înceapă a folosi un VCS?
A younger programmer asked an elder about his code and his coding style, and how the older programmer would do certain things. The older programmer said ‘Let’s take a look at your code’, so the younger took out his laptop, opened his editor, and showed him.
The older programmer looked at the code, thought about it for a bit, and then started editing it. He deleted the class internals, leaving only the structure, and then rearranged the structure, saying ‘Here’s how I would do it to make it more efficient and readable’. After he was done, he saved the file and gave it back to the younger programmer, who was ashen-faced.
‘That… My code is gone!’ said the younger programmer. ‘But you have it in version control somewhere, right?’ asked the elder. ‘N… no.’ was the reply. ‘Well then,’ said the older, ‘now you’ve learned two lessons.’
E abia Aprilie și deja avem un câștigător pentru premiul “Cea mai inutilă întrebare, ediția 2015” E cineva care are vreun argument contra, cât ar fi el de mic, numai valid să fie, care să contrabalanseze mormanul de argumente pro? Singurul argument la care mă pot gândi este “Abia am aflat de VCS”. Care e rezonabil, pentru un începător.
Sunt freelancer full-time de 4.5 ani (scriu cod pentru pâinea de zi cu zi de ~10 ani), deci foarte rar “împart” codul cu cineva. Și totuși, îmi pot imagina cum aș putea să renunț oricând la orice componentă din stack, numai la version control nu.
Ai rămâne surprins de ce scuze am auzit de la cei ce nu folosesc VCS:
nu (mai) pot lucra pe FTP (direct în producție adică);
nu pot sincroniza DB;
nu pot sincroniza fișierele urcate;
nu le cere clientul (!!!)
Și tot așa.
Cunosc vreo cinci programatori care lucrează singuri și nu văd nici un avantaj în a folosi VCS. (plus vreo 20-30 oameni ce mi-au trimis mail când căutam colaborator)
Ba chiar știu de o echipă de trei programatori care lucrează pe sistemul „trimis mail cu o zi înainte cu fișierele la care va lucra în ziua următoare”…
Am preluat proiecte fara sa fie sub source control si plin de fisiere si foldere (Copy of …), e o practica obisnuita. Personal nu pot lucra fara version control, tin toate datele importante sub aceasta forma in repo privat.
Primul contact cu version control l-am avut in facultate in cadrul unui laborator si practica am facut cu RCS (http://en.wikipedia.org/wiki/Revision_Control_System) sunt curios daca l-a folosit cineva?
Aia e varianta noob a zip foo-2931239.zip bar.php de care am zis mai sus
Ok, ok, sunt convins că toți avem astfel de povești (una mai horror decât alta), dar cum convingi pe cineva (de preferat într-un mod civilizat și cât mai nonviolent posibil) să înceapă a folosi un VCS?
nu ii pot numi programatori adevarati pe aia care nu lucreaza cu un sistem de versionare (cel putin la proiectele de lunga durata care necesita modificari dese), indiferent ca lucreaza solo sau in grup.
primii 2 ani am luarat si eu fara asa ceva (nu stiam de asta) apoi dupa ce am aflat de svn/git nu mai concep sa revin la vechia abordare.
totusi, nu orice proiect se merita pus pe un sistem de versionare, clientii ocazionali la care fac o modificare si apoi nu mai aud de ei nu are rost sa ma complic cu vcs, fac modificarea/implementarea, o pun pe productie si nu mai aud de clientul respectiv…
Deci, singurul motiv pentru care nu as folosi un sistem de versionare e cand proiectul/taskul alocat nu e constant, e o singura data si gata, asa moare, nu mai aud nici de client nici de proiect (si sunt multi freelanceri care primesc modificari de wp/drupal/magento sau cine stie ce alt cms, implementeaza modificarea si apoi nu mai aud de clientul respectiv).
Îi prezinți acele features care aduc cele mai mari beneficii, în cel mai scurt timp, croite pe probleme de care sigur s-a lovit:
Poate să lucreze în același timp pe aceleași fișiere cu alți colegi din echipă, fără să își facă griji că se vor călca pe bătături. Când are ceva de făcut face direct, fără să întrebe daca nu cumva lucrează deja cineva pe fișierele alea.
De fiecare dată când începe să modifice un fișier, nu mai trebuie să aibă grijă să țină minte să noteze undeva că l-a modificat, pentru că un VCS îi poate arăta oricând o listă de fișiere modificate de la ultimul commit, ca să știe cu ce să dea sus.
Poate să șteargă fișiere fără grijă că dacă apasă SHIFT+DEL pe ce nu trebuie pierde muncă.
Există nenumărate tool-uri de deployment care aplică modificările făcute local direct pe producție, așadar nu trebuie să îți bați tu capul să aplici modificările făcute local și sus.
Poate să țină în version control chiar și structura bazei de date. De la tool-uri simple de aplicat migration scripts salvate manual, până la tool-uri complexe care știu să facă diff între două baze de date și să aplice modificările pe oricare din ele (paranteză: eu folosesc MySQL Workbench pentru asta, pentru că pot face modificări de structură în diagrama vizuală, iar el știe să genereze și să aplice SQL cu modificările față de o bază de date la care se conectează. It’s awesome).
Poate să vadă când anume s-au făcut anumite modificări, și de către cine.
Îți oferă un layer de backup pentru care nu trebuie să faci nimic în plus, doar să muncești la proiect.
Solutia pe care o vad eu este sa educi clientii, sunt programatori reticenti la schimbare (de orice fel). Daca clientul cere de la ei in mod explicit asa ceva atunci se vor conforma.
Întrebarea pe care aș pune-o eu este „De ce trebuie să convingi pe cineva să folosească un tool care e bun pentru el?”. Oamenii nu sunt egali, în același timp programatorii nefiind egali din punct de vedere al competențelor. E foarte bine că există gagii care nu înțeleg rostul versionării, e mai puțină competiție serioasă pentru developerii cât de cât capabili.
Eu folosesc git pt proiectul actual, dar pot renunta oricand la el.
Fac deployment manual prin ftp, si git ma ajuta sa vad ce fisiere trebuie sa uploadez, fisierele modificate de la ultimul update.
Si evident in cazul in care as lucra intr-o echipa vad rostul unui VCS, e un efort intelectual sa il inveti dar in cazul unei echipe merita.
Dar in proiectul actual, pt mine nu-i atat de important VCSul, poate pentru ca nici macar nu am inteles cum se folosesc multe functii ce-i drept (cateodata uit si sa fac commit, sau mi-e lene).
Oricum, recomand VCS tuturor programatorilor si ca sa convingi un programator sa il foloseasca eu zic ca ar merge si argumentul: VCS nu are cum sa nu te ajute cu ceva, trebuie sa il experimentezi ca sa descoperi cu ce te ajuta, si odata inteles te poate ajuta mai mult.
Eu am invatat la ce-i bun CVS (ca SVN doar ce aparuse) cand lucram la un site cu inca 2 si s-a dat vina pe junior pt un bug nashpa si n-am putut dovedi si n-am primit nici un ban
Cred că e o față a aceleiași monede. Când nu folosești version control e o grămadă de bătaie de cap să ții o listă cu cine ce fișiere a modificat, și cum pornim de la premisa că ți-e cam lene (că altfel ai folosi VCS), e tentant să peticești direct pe producție.
Eu am fost reticient la inceput pentru ca exista o curba de invatare (din motivul asta nu stiu VI) si la inceput pare ca te incurca. Basca ca daca mai faci si greseli pierzi o groaza de timp sa le repari. Or cand tipa clientul, n-ai timp de prostii.
Anyway, avantajele care vin dupa sunt incomparabile cu micile neplaceri de la inceput.
Eu nu prea înțeleg despre ce curbă de învățare vorbiți voi aici Pentru un programator solo este suficient în primă fază să folosească GIT pentru commits/push pe măsură ce implementează funcționalități. Pentru asta efectiv nu ai nevoie decât de un tutorial de 10 min de pe net, nici măcar nu trebuie să știi să scrii comenzile în consolă (eu folosesc SourceTree, vă spun sincer că aproape că habar nu am de comenzile din consolă și nu știu să folosesc GIT în consolă decât dacă mă uit pe docs :D)
Pentru branching, diffs și alte chestii deja intrăm în funcționalități pe care un developer solo nu le va folosi în primă fază și dacă-și dă seama că are nevoie de ele le poate învăța pe parcurs.
Bogdan, aici este deja o altă discuție. Sunt paradigme ce nu sunt ușor de digerat, oricât de experimentat ai fi (indiferent de VCS).
Eu am avut probleme și cu SVN și cu Git pentru că aveam niște așteptări nefondate:
inițial mă așteptam ca orice modificare a unui fișier să ajungă în repo, iar tot VCS-ul să funcționeze fix ca un sistem de undo (sigur, mi-am dat seam apoi că ar fi inutil)
când am trecut pe git, eram foarte contrariat de conflicte (venind din lumea SVN dădeam commit o dată pe zi sau chiar mai rar, timp în care alții lucrau și ei)
apoi mi-am dat seama că unele lucruri n-aș vrea să rămână în istorie (până mi-am dat seama la ce sunt bune branch-urile)
și tot așa.
Acum, că am câțiva ani de când folosesc Git, toate chestiile de atunci mi se par extrem de naive, dar atunci reprezentau probleme serioase. Plus scuza cu „proiectul ăsta e urgent și n-am timp de prosteală; la următorul sigur încerc!”.
E cineva care are vreun argument contra, cât ar fi el de mic, numai valid să fie, care să contrabalanseze mormanul de argumente pro? Singurul argument la care mă pot gândi este “Abia am aflat de VCS”. Care e rezonabil, pentru un începător.