Verziókezelésről mindenkinek - Miért kell ez nekünk?

A most induló néhány részes bejegyzés-sorozatomban a verziókezelésről szeretnék mesélni. Beszélgetések során gyakran érzem úgy, hogy túlmisztifikálják a témát, ezzel is megnehezítve a kezdők indulását. Pedig az igazán hatékony fejlesztéshez elengedhetetlen lenne egy verziókezelő rendszer alapos ismerete, hiszen ez segít a fejlesztés dokumentálásában is, nagyobb kódbázis hosszabb távú kezelése pedig elképzelhetetlen nélküle.
Mielőtt belemennénk a verziókezelés mélyebb ismertetésébe, érdemes körüljárni, hogy miért is lehet szükség rá.

1. „azért használok verziókezelő rendszert, mert így könnyebb másokkal együttműködni”

Az igazán apró vagy magáncélú fejlesztések kivételével szinte mindig csapatban dolgozik az ember. Ha pedig egy kódbázison egyszerre több fejlesztő is ügyködik párhuzamosan, akkor eszközt kell biztosítani arra, hogy a módosítások a többi programozóhoz is eljussanak. Jó lenne látni, hogy az egyes változtatások milyen módon kapcsolódnak egymáshoz és valami kell ahhoz is, hogy ha egy fájl párhuzamosan, több programozó által módosult, akkor ezeket össze lehessen fésülni, vagy kiválasztani ezek közül a megfelelő állapotot.

2. „minden verzióról megvan az infó, meg tudom nézni régiből mi változott, hogy akkor ment, most meg nem”

Ez egy nagyon sarkalatos pontja a verziókezelésnek. Már pár nap után sem lehet biztosan megmondani, hogy egy adott programsor miért került bele a forrásba, ha nem írunk megjegyzéseket. A túl sok közbeékelt megjegyzés viszont „zajossá” teszi a kódot, kevesebb programsor fér el a kijelzőn, többet kell görgetni és ugrálni a forrásban. Ha pedig egy logikai egységben a fájlban több helyen is módosítunk, akkor a megjegyzések még kevésbé segítenek a fejlesztés dokumentálásában. A verziókezelés lehetőséget nyújt arra, hogy nyomon kövessük a változásokat és két kiválasztott állapot között pontosan láthassuk a különbségeket.

3. „vissza tudom keresni, mikor mit miért ki cseszett el”

A korszerű verziókezelő eszközök lehetőséget nyújtanak arra, hogy a forrásfájl egy adott soráról megállapítsuk, mikor került a kódba. Ez sokkal fontosabb, mint elsőre gondolnánk, hiszen így visszakereshető az érintett állapot és jobban megérthető az adott kódrészlet szerepe. Természetesen ez fordított értelemben is igaz, vagyis ha találunk egy hibás sort, akkor könnyebben értelmezhető, hogy mi lett volna a funkciója, illetve pontosan mikor és melyik fejlesztő helyezte a program kódjában, milyen megjegyzés kíséretében. Talán már itt is látható, hogy ahogy a fejlesztésnél fontos a szükséges mennyiségű, jól értelmezhető megjegyzés, ez a verziókezelésnél elmentett állapotokhoz írt üzenetekre is igaz.

4. „mindig van backup”

Ha valaki már írt több oldalnyi kódot napokon keresztül, amely aztán hirtelen elveszett, az tudja jól, hogy a rendszeres biztonsági mentés elengedhetetlen. A verziókezelés előnyeinél az egyik legfontosabb érv, hogy bizonyos mértékig átveszi ennek a szerepét. Nyilván ez csak akkor működhet hatékonyan, ha a verziókezelést is jól csináljuk, vagyis nem csak napi egy-egy alkalommal mentünk fejlesztési állapotot, hanem logikai egységenként. Férfiasan bevallva én probléma nélkül elvégzem ezt mentést akár három soronként, ha a helyzet úgy kívánja. Egy jó fejlesztőeszközzel megtámogatva a verziókezelés nem nyújt különösebb nehézséget, nem késztet plusz gondolkodásra és nem zökkent ki a fejlesztés üteméből. Az elosztott módon működő rendszerek nagyobb biztonságot adnak, hiszen az elmentett állapotok egy külső tárhelyen is tárolhatóak, mindemellett használhatóak maradnak internetkapcsolat nélkül is. Így az elosztott működés a redundancia által többszörös védelmet nyújthat az adatvesztés ellen.

5. „mert divat”

Ezen nincs mit tagadni, ez tény. Régen is voltak verziókezelő eszközök, de az elmúlt pár évben váltak igazán felkapottá. Valószínűleg az is hozzájárul ehhez, hogy régen ezek az eszközök nehézkesek és bonyolultak voltak, a használatuk felért holmi informatikai varázslással (aki nem hiszi, az pattintson össze egy CVS szervert több tárolóval), míg a mai programok jól dokumentáltak és számtalan megoldással segítik a használatukat. Felkapott lett a közösségi fejlesztés is, elég csak a SourceForge vagy GitHub oldalon indított projectek számát és aktivitását megfigyelni.

Az Integral Vision Workshop keretében valószínűleg többször is szóba kerül majd a verziókezelés használata.

Hozzászólások

A divattal csak akkor értek egyet, ha az elmúlt pár évet kitágítjuk legalább 10-20 évre (messzebb nem látok, szívem szerint 30-40 évet mondanék, bár 30-- éve programozok, csak 20 éve csapatban). Ami biztos: 14 éve pl. Cobolban (!) kódoltam (ami már akkor sem volt divatcikk), mégis volt korszerű verziókezelőnk, mert kellett. Globálisan toborzott fejlesztői csapat többezer együttműködő programfájllal, több fejlesztői, több tesztelői és több éles környezettel, Xmillion$ hardverháttérrel akkor sem lehetett meg nélküle, pedig a fejlesztők 95%-a egy légtérben, Budapesten volt.
I <3 version management!

A 3. „vissza tudom keresni, mikor mit miért ki cseszett el” szerintem rossz hozzáállás: hosszú távon gyümölcsözőbb, ha így nézem: ha valamit valamelyikünk elrontott, ki tudjuk keresni, ki lenne a leghivatottabb kijavítani a hibát, vagy ki tud segíteni nekem a javításban.

De én csak kibic vagyok, bocs, nem igazán számít, mivel értek egyet, vagy sem. :)

Nagyon jók a meglátásaid, köszönöm őket! :)