Nevezhető-e 2020-ban szoftverfejlesztőnek az, aki nem képes verziókezelő rendszert használni?

Címkék

Igen.
29% (315 szavazat)
Nem.
69% (746 szavazat)
Egyéb, leírom.
3% (28 szavazat)
Összes szavazat: 1089

Hozzászólások

Ha valaki valami nagyon magas szinten dolgozik, mittudomén kernelfejlesztő, vagy valami olyan nagy projekt részese mint a Gnome, KDE, stb, akkor nyilván elvárható tőle a (valamelyik...) verziókezelő rendszer ismerete. Ez evidens. Kisebb projektek esetén azonban nem hinném hogy ez akkora nagy követelmény volna. Egyemberes projektnél szinte teljesen felesleges, én is jól megvoltam nélküle a Furor fejlesztése esetében. Ha egynél több fő dolgozik rajta, akkor meg attól függ, épp hányan. Magánvéleményem az hogy úgy nagyjából talán fél tucat közreműködő esetén már biztos hasznos dolog volna.

Az azonban hogy aki nem ismeri, ne lenne szoftverfejlesztőnek nevezhető, túlzás, és nem is enyhe! Mondjuk inkább úgy, amíg nem ismeri meg, addig nem ajánlott őt befogadni igazán nagy projektekbe. Ettől azonban ő még igenis lehet egy felettébb remek fejlesztő a maga területén, csak nem a legmagasabb szintekre való. Ez rám is igaz: magam is elismerem, nem lennék olyan helyekre való! Nyilván persze képes lennék megtanulni akármelyik verziókezelő rendszert, de egyrészt nem érdekel, másrészt nincsenek is olyan vágyaim szoftverfejlesztésileg ami ezt indokolná. Eszembe se lenne például a KDE-t fejleszteni!

-1. Egyszemelyes, kis hobbi projektek eseten is nagyon hasznos tud lenni egy verziokezelo. Nagyjabol minden ilyen nehany szaz sornal bonyolultabb kodom bent van gitben, mert hosszu tavon sokkal egyszerubb, ha egyszer erszreveszed hogy elromlott valami ami 2 honapja meg mukodott, akkor egyszeruen meg lehet nezni mi valtozott, ha 1-nel tobb gepen akarod hasznalni/fejleszteni akkor is egyszerubb mint kezzel masolgatni a sokezer forrasfajlt, tudsz fejleszteni egy uj featuret egy masik checkoutban, branchen ugy hogy kozbe az cucc hasznalhato marad, ... Nyilvan meg lehet csinalni ezt kezzel is egy halom jol elnevezett tarballal is, csak hat az pont hogy nem az egyszerubb kategoria.
Aztan gitnel meg az egyeb elosztoitt verziokezeloknel tenyleg az van, hogy `$EDITOR .gitignore; git init .; git add .; git commit` es van egy repod, ha nem akarod valami szerverre feltolteni, masokkal megosztani, akkor ennyi.

I hate myself, because I'm not open-source.

Így van. Még nagyon komoly programozónak meg több száz soros kódnak sem kell lenni hozzá, már egy ~100 soros konfigfájlnál is sokszor hasznos tud lenni ha fent van gitben. Ezen a téren nekem is lenne még mit pótolnom, igaz én nem is hívom magam fejlesztőnek. Aki viszont annak hívja magát, már rég illik tudnia kezelni valami széles körben elterjedt verziókezelő rendszert. Nem bonyolult megtanulni, érdemes beletenni az időt, főleg annak, aki tényleg komolyan akar fejlesztéssel programozni, és nem akar ilyen komolytalan C64 BASIC programozós szinten megrekedni.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

Ha egynél több fő dolgozik rajta, akkor meg attól függ, épp hányan. Magánvéleményem az hogy úgy nagyjából talán fél tucat közreműködő esetén már biztos hasznos dolog volna.

Nem lehet túl nagy öröm 5 embernyi conflictot kézzel számon tartani és kiegyengetni. :)

Egyemberes projektnél szinte teljesen felesleges, én is jól megvoltam nélküle a Furor fejlesztése esetében.

Ha nem teljesen triviális vagy write-only a kód, akkor egy embernél is nagyon hasznos.

verzio kezelo nelkul egy tapottat sem. Marcsak a kovetkezo fob okok miatt sem:

      0. A verziokezelo rendszerbe tarolt kod mar alapbol egy biztonsagi masolat (termeszetesen ha a verziokezelo szerver nem egy es ugyanazon gepen es lemezen fut mint a fejlesztes es lehetoleg nem pistike hazi szervere, hanem egy megbizhato host ahol legalabb napi szinten van biztonasgi mentes). Ha 2020-ban azt hallom egy fejlesztotol, hogy elveszett 2 het munkam mert "kiment" a hard, veletlenul folulirtam X napi munkam, stb. akor nagyot fogok nevetni es minimalis sajnalatot sem fogok tanusitani.

  1. Van ugy, hogy egy adot problema megoldasanak 2 vagy tobb nekifutasbol/vazlatbol probalkozol. Verziokezelo es branch nelkul nem modositok vagy torlok fuggvenyt etetleg teljes osztalyt, mert nem mindig tudhatom, hogy az elozo verzio lesz-e vegul a jobb vagy a 6-ik iteracio, stb.
  2. Csapatban valo munka eseten remalom verziokezelo nelkul fejleszteni (fejlesztettem nelkule, igaz nem az elmult 10 evben, tehat tapasztalataim vannak a sotet oldalrol is). Elsore sokaknak a "merge" a legnagyobb ellenseg de hamar lehet belole a legjobb baratod.
  3. Neha egy uj feature fejleszteset felbe kell hagyni  es viszaterni egy elobbi allapotra (pl. bugfix a jelenlegi eles rendszeren futo kodban, surgosebb feature, egy vagy tobb dependencia frissitese amik tartalmaznak "breaking change(s)"-t, stb.)
  4. A commit hozzaszolasok nagyobb kihagyas utanni viszateres adot projekre vagy netan atvenni valaki mastol dokumentalatlan forrasat igencsak jol johet
  5. Code review, build, test, deploy rendszeretk integralasa
  6. valoszinu meg 94 pontot is folsorolhatnak de amig nincs verziokezeloben ez a 6 nem vagyok ra hajlando :D

Az a baj látod hogy már teljes mértékben megfertőzött benneteket (másokat is...) az a szemlélet hogy a Hálózat az ISTEN, meg a Közösségi Projektek, és minden ami Offline, az elavult és felesleges és stb, és NEM IS KOMOLY!

Látom itt az alanti kommentekből, még a mentést is lassan már csak online tudjátok elképzelni. Nem tudom mi a rákért... Én 2 napja vettem 2 darab egyenként 3 terabájtos külső lemezt, mindegyikre csináltam komplett system backupot, meg kimentettem rájuk minden fontos fájlomat de azon kívül is van backupom még több helyen offline. Mégis mi a tetves fenéért kéne még ehhez is hálózat meg internet, és rábízni a dolgaimat egy külső cégre, pláne pénzért?!

Teljesen elkurvult már ez a mai világ komolyan mondom.

 Mégis mi a tetves fenéért kéne még ehhez is hálózat meg internet, és rábízni a dolgaimat egy külső cégre, pláne pénzért?!

ne légy szűklátókörű. Csak hogy a manapság legsűrűbben emlegetett git-et használva:

 - nyugodtan lehet local repo-d amit nem pusholsz sehova, arra már így jó, hogy a verziók közötti változtatásokat / fejlődés történetet nyomonkövesd (avagy a semminél egy hajszállal máris több :) )

 - változásokat átvihetsz mappák között is (felvehetsz remote-ot ami a filerendszeren valahol máshol lakik)

 - ha már az általad szídott hálózatnál tartunk: senki sem akadályoz meg abban, hogy lanodon saját magadnak fenntarts egy példányt.

Nem tudom mi a rákért...

majd egyszer megdöglik a géppel együtt az összes rádugott winyo és meglátod :)

[..] de azon kívül is van backupom még több helyen offline. Mégis mi a tetves fenéért kéne még ehhez is hálózat meg internet [..]

És a több helyen levő offline backupodat mivel szinkornizálod? rohangálsz a gépek között mobil winyo-kal? célszerűen hálózaton keresztül automatizáltan felhasználói beavatkozás nélkül elkészülnek a mentések / szinkronizációk. persze mindent lehet kézzel csinálni, ha valakinek az a mániája és ráér..

[..]rábízni a dolgaimat egy külső cégre, pláne pénzért[..]

Biztos velem van a baj, de inkább fizetnék az adott cégnek valamennyit, ha már esetleg az adataimat rábízom, cserébe remélem, hogy elsődlegesen nem az adataimból próbál meg profitot termelni :).

https://goo.gl/muWzKz (digitalocean)

Eddigi tapasztalatom alapján sokkal többször veszik el valami, ha helyben van megoldva. Kicsit olyan ez, mint a légi katasztrófa vs. autó baleset: évente lezuhan egy-két repülő, meghal 500 ember, hetekig hírekben szerepel; évente meghal 1 millió ember földi közlekedési balesetben, senki fel se emeli a fejét, csak ha valami különleges eset.

És ilyenkor jön az pluszban, hogy egy on premise levelezésre migrálás annyi belső erőforrást visz el egy ötven fős cégnél, amennyiből 5-10 éven át lehetne venni a felhőből sokkal bővebb szolgáltatást. De valahogy néha a vezetőség nem nézi a helyi munkaerő költségét, úgy veszik, hogy az üzemeltetők amúgy is a tökeiket vakarják, belefér még nekik ez is, nulla forintba kerül.

Az a baj látod hogy már teljes mértékben megfertőzött benneteket (másokat is...) az a szemlélet hogy a Hálózat az ISTEN, meg a Közösségi Projektek, és minden ami Offline, az elavult és felesleges és stb, és NEM IS KOMOLY!

Szerintem ott latsz bajt ahol nem kellene. Jogod van offline menteseket kesziteni es nem hasznalni online verziokezelot, egymagad  eldonteni, hogy mit es hogyan hasznalsz, amig a te es csakis a te feleloseged. Amint egy kozosseg reszekent kell mukodnod, alkalmazkodnod kell hozza es nem pedig a kozossegnek megvaltoznia, hogy alkalmazkodhasson hozzad.

Szemely szerint nem alkalmaznek fejlesztot aki azzal indokolja a verziokezelo hasznalatanak megtagadasat, hogy "az a baj, hogy már teljes mértékben megfertőzött benneteket az a szemlélet hogy a Hálózat az ISTEN" :) Ha szereted, ha nem a jelen vilag online es nem pedig offline (biztos van kivetel de az annyira csekely, hogy nem lehet altalanos iranyado).

Nem ma kezdtem es megeltem a betarcsazos internetes idoket is (sot, meg az internet nelkulit is mikor elsore futottam neki a BASIC programozasnak meg a 90-es evek derekan, egy 25 oldalas kezikonyvbol es a programjaimat kazettara mentettem es toltottem be) es nagy reszet a C programozasi tudasomban a man page-kbol tanultam, nem stackoverflow-rol, de nagyon imadtam volna ha a sok elvesztegetett ora helyett lett volna egy youtube-os how-to es stackoverflow ahol reszletes magyarazatot kaptam volna arra, hogy hol hibazok es miert latom vagy kozelitek roszul egy adott problemat.

Használok, pedig -sajnos- egész életemben egyedül fejlesztettem.

 

Pedig ez, -sajnos- a te egyeduli dontesed.

 

Legalabb nem kell alkalmazkodni, es nem bofaznak bele a homokvaradba:)

Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Ebből látszik, hogy kezdő szoftverfejlesztő vagy. Nem lehet remek munkát végezni megfelelő toolok nélkül. Mégis, hogy kommunikálsz a társaiddal? Emailben küldesz patch-eket? Hogy archiválsz? Zippelgeted a kódot?

Lehet asztalosnak nevezni azt, aki nem tud kezelni egy csiszológépet.

 

Amúgy számtalan indiai kollegám van, akinek a git gondot okoz. Az a kérdés, hogy ebbe a díszes csoportba szeretnél-e tartozni, vagy a profik közé.

Az azonban hogy aki nem ismeri, ne lenne szoftverfejlesztőnek nevezhető, túlzás, és nem is enyhe!

Nem errol szol a szavazas. Illetve a "nem kepes" VS "nem szukseges" mas teszta.

Ha nem kepes hasznalni, az gaz. Ha nem szukseges es nem hasznalja szvsz. azzal semmi gond nincs.

En ugy gondolom, hogy ketto embernel mar olyan elonyoket ad, hogy kotelezo hasznalni. Bar en szoktam a sajat cuccaimat is kovetni ... Siman lehet, hogy tobb emberes project lesz kesobb.

Szerkesztve: 2020. 09. 18., p - 15:09

Ha a megrendelo elvarasainak megfelel a szoftver erdekel valakit, hogy volt-e verziokezelo hasznalva?

Kisebb projecteknel vagy egyeduli fejlesztokent elofordulhat, hogy a verziokezelo adta elony elenyeszo (embere valogatja).

[szerk.]

Elolvastam az eredeti topic-ot is, ami ott van az szivas. En csak a kiragadott hozzaszolasra reagaltam. Ha egymaga dolgozik a szoftveren akkor lehet neki beallitani helyi mentest a szamitogepere, aztan az egeszet idonkent menteni. Igy kevesebb a macera, verziokezelo helyett a visszaallitast kell megtanulnia.

"Már nem csak tehetségekből, de a hülyékből is kifogytunk..."

Miért csak kiegészítő? Hol lehet nagyobb biztonságban egy mentés, mint egy földrajzilag távoli szerveren, mondjuk a githubon? De ha nem használom a githubot, akkor is a saját gépeimre pillanatok alatt pusholok egy commitot, miközben pontosan látom, hogy melyiken mi van. Az internet bármely pontjáról elérem a vackaimat. Fejlesztői szempontból a backup rendszerek fölöslegesek.  

Elég sok olyan backup megoldás van, amit direkt vagy véletlenül kiadott parancsokkal azért különösebb gond nélkül le lehet törölni.

Persze lehet, hogy azokat se neveznéd backupnak.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Hát, a saját dolgaimról három példányban készül backup, amiből 2 offsite és 1 offline, és ez az egész <1 sör árába kerül havonta. A semminél persze jobb backup megoldás egy GitHub repo, de ha valamit arra találtak ki, hogy párhuzamosan több ember használja read/write üzemmódban, azt valóban nem tartom szerencsésnek backupként használni.

szerk: mi van, ha megborul a GitHub repód, te meg ott állsz letolt gatyával, mert a shallow clone-ban csak az utolsó 500 commit van benne? Nyilván egy hobbiprojektnél nincs ilyen, de egy 15-20 gigás repó mellett könnyen előfordulhat.

Érdekelne a módszered.

A gépem ~egész tartalmát szinkronizálom egy G Suite-os Drive-ba. Ezt a levelezés miatt amúgy is fizetnem kell, viszont a 30 GB tárhely nem elég a backup miatt, így meg kellett vennem a +100 GB-s extra csomagot, 6900 per év / 12 = 575 forint per hó. ==> offsite/online mentés.

A G Suite account teljes tartalmát (levelezés, Drive, stb.) néhány óránként lehúzza az otthoni NAS, amit már más miatt úgyis meg kellett vennem, így ezt nem számoltam bele. ==> onsite/offline mentés.

A NAS hetente feltölti az utolsó teljes snapshotot Amazon Glacier-be. Ez párszáz forint, pontosan nem tudom hirtelen, mert több dolgot is beterhel egyszerre az AWS, de majd megnézem. ==> offsite/offline backup.

Múltkor bringázás után a Fellininél a Dunaparton ezres volt a Stari Feketeribizli (heavily recommended), előtte meg 1000+ volt valahol a Hoegaarden. Illetve CAPEX oldalon nem nagyon volt költség, mert a NAS amúgy is megvolt már, nyilván, ha emiatt veszel, azt hozzá kell adni.

Viszont egy nem hobbiprojektnél meg van megfelelő permission control és off-site backup

Nincs itt semmi ellentmondás. :) Én azt mondtam, hogy a Git repo nem backup. A Git repo offsite backupja már backup. :)

egy nas, aminek az árát sehogy se számolod

A NAS már évek óta állt a spájzomban, mire egyáltalán elkészült az a szoftver, ami a G Suite-ot tudja backupolni. Nyilván nem számítom bele. Ha nincs NAS-od, akkor egy filléres VPS is megteszi, nyilván akkor egy sör helyett kettő lesz a vége.

Milyen prémium márkát fogyasztasz? :) 

Nem figyeltél. :) "Múltkor bringázás után a Fellininél a Dunaparton ezres volt a Stari Feketeribizli (heavily recommended), előtte meg 1000+ volt valahol a Hoegaarden."

A git push kiválóan jól használható mentésre.

Ja, amugy erre lattam peldat. Prezentaciokat "verziokezeltek" git-el, ugye azok binaris allomanyok...

Aztan kicsit gyorsan megtelt a kvota.

"Már nem csak tehetségekből, de a hülyékből is kifogytunk..."

Igy kevesebb a macera, verziokezelo helyett a visszaallitast kell megtanulnia.

Nem kell neki beállítani semmit. Jobb klikk a fájlon, vagy a mappán, Restore previous version és maga tudná visszaállítani a napi többször lefutó snapshot-ból. Bár, ehhez kicsit többet kellene érteni a Windowshoz a '90-es évek Win95-jénél. Ezt belátom ;)

trey @ gépház

Nem kell neki beállítani semmit. Jobb klikk a fájlon, vagy a mappán, Restore previous version és maga tudná visszaállítani a napi többször lefutó snapshot-ból. Bár, ehhez kicsit többet kellene érteni a Windowshoz a '90-es évek Win95-jénél. Ezt belátom ;)

Az eredeti tema alapjan megkapja amit szeretne a mentesbol, a szoftver gondolom mukodik a megrendelo elvarasainak megfeleloen (vagy nem tudja a megrendelo, hogy kaphatna jobbat is). A rendszergazdak dolgoznak, rendelhetnek ujabb lemezeket hogy 1 evre visszamenoleg is legyen mentese a fickonak. Mi itt a gond? ;)

"Már nem csak tehetségekből, de a hülyékből is kifogytunk..."

Mi itt a gond? ;)

Az, hogy a mentés nem erre van. A probléma pedig - nem tudja mikor baszta el. Tehát a szerencsétlenkedés így kezdődik:

- "Azt hiszem, hogy július elején még jó volt az a fájl! Állítsd vissza a július 15-ei esti állapotot."

- "OK."

- "Ja, eszembe jutott, hogy Jóska Pista 16-án reggel még belemódosított egy nagyon fontosat. 16-a délelőtti nincs?"

- "Visszaállítva."

- "Megnéztem, nem jó. Lehet, hogy nem július, hanem június?"

- <Kérded, vagy mondod? Bazmeg?!> "Visszaállítva".

- "Hmm. Ez sem jó."

Szerinted így néz ki egy profi?

trey @ gépház

Termeszetesen vicc volt a "Mi itt a gond?". Szamodra is szivas, szamara is, gondolom orulne ha nem kellene a visszaallitasert ugraltatni valakit. Kerdes, ha valaki megmutatja neki mire jo a verziokezelo akkor fogja-e hasznalni, lehet ez evente csak 1x fordul elo amikor bele kell javitani. Attol meg irhat jo szoftvert ha letojja a verziokezeloket.

"Már nem csak tehetségekből, de a hülyékből is kifogytunk..."

Ez mar az eredeti topikban is meg lett kerdezve, csak eppen megy a tereles, mert sokkal jobb sztoryzni meg vihogni mintsem segiteni. De mivel a kerdesedre valasz sem erkezett, gyanitom, hogy senki nem mutatta meg. Ahh meg miert is kene? olvassa el tanulja meg! persze csak a baj ezzel hogy a korosodo kollegakat maskeppen kell kezelni, maskeppen kell hozzajuk allni mint a "fiatalaokhoz". Csak ugye az empatihianyos emberek ezt nem tudjak erzekelni es kezelni.

Mi az, hogy megmutatja-e valaki? El nem tudom képzelni, hogy olyan balfasz legyek, hogy látom, hogy rajtam kívül mindenki használ valamit, ami a munkájukat nagy mértékben segíti és nincs bennem annyi, hogy megkérjem őket, küldjenek legalább egy linket az interneten, hol tudok belekezdeni, aztán ha elakadok, akkor majd kérek hozzá segítséget.

Ott van előttük az internet teljes szélességben - doksik, tutorialok, videók - akármi, de nem is akarnak fejlődni. Egyébként pedig minden éven felmérik, hogy kinek milyen tanfolyamra van szüksége. El tudod te képzelni, hogy az elmúlt 15-20 évben nem tudta felírni az éves felmérésbe, hogy "verziókezelő rendszerek alapszint"?

Ez hozzáállásbeli probléma.

Egyébként tudod mi akadályozza meg, hogy készítsen saját mentést a fájljairól _MIELŐTT_ elbassza őket és abból vissza tudja magának állítani? Pont az, ami megakadályozza egy verziókezelő rendszer kezelésének megtanulásában: lustaság/nemtörődömség

Semmi más.

trey @ gépház

"mindenki használ valamit" --> bocs, nem cégről beszélünk, ahol az azonos minőség, a csereszabatosság ... szóval bevezetett céges standardek vannak, amit be kell tartani és ezért a főnök is felel?
Kérdésem változatlan: biztos hogy csak az ezt elkövető egyént kell ennél a cégnél lecserélni?

Ha egymaga dolgozik a szoftveren akkor lehet neki beallitani helyi mentest a szamitogepere, aztan az egeszet idonkent menteni. Igy kevesebb a macera

Hát, azért ez nem biztos. Mi van, ha nem egy egész fájlt kell visszaküldeni az időben, csak mondjuk egy rosszul sikerült függvény refaktorálást?

"Ha a megrendelo elvarasainak megfelel a szoftver erdekel valakit, hogy volt-e verziokezelo hasznalva?"

Hacsak nem valami dobozos szoftver, akkor a megrendelőnek is érdeke, hogy nyomon lehessen követni a verziókat. Különösen ott, ahol lehet, hogy két verzió között a fél fejlesztő brigád kicserélődik.

Az egyik "top 10" programozasi nyelv 60+ eves megalkotoja nem igazan hasznal verziokezelot. Nehezere is esik git-tel dolgoznia. Azt gondolom, neki ez megbocsajthato. De a tobbsegnek nem! : ) Tessek megtanulni az alapokat, nem nehez, es nagyon hasznos.

Ez engem is érdekelne. Bár így általánosságban sem hinném, hogy egy 70+ éves programozó ma már írna akár csak saját magának is akármilyen kódot, de ha még így is van, hogy ír, de nem verziókezelőzik, akkor sem hiszem, hogy az ő esetét kéne mérvadónak venni. Ez ilyen tipikus, bezzeg öreganyám is lehetett volna villamos típusú, másra mutogató, sehova nem vezető érvelés. Itt nem arról van szó, hogy a top nyelv megalkotója egyetért-e a verziókezeléssel, hanem hogy manapság melyik fejlesztőnek célszerű ebből kivonnia magát. Nekem ez a csak azért sem verziókezelőzök hozzáállás ilyen konok ellenállásnak tűnik, mint hajbazernél a csak azért is XP, meg az bezzeg még assemblyben volt, és különben sem veszek új gépet hisztéria, ami igazából senkin nem segít, csak simán önkábítás és elkeseredett önigazolás kategória. Sose értettem, hogy egyes emberek milyen messze el tudnak menni önigazolás terén, ha valamit nincs kedvük csinálni, meg lusták megtanulni. Mert még ez utóbbival sem lenne semmi, valaki nem akar extra erőfeszítést, meg belefárad, hogy mindig újat kell tanulni, rendszeres továbbképzést igényel a pálya, de akkor meg vallja ezt így be magának, és ne racionalizáljon, hogy különben is a Kisguczy Illés se, mert ő nem lesz fősodratú bla-bla.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

Bocs, félreolvastam 60+ éves top nyelv megalkotójának. Közben meg top nyelv 60+ éves megalkotója. Nem mintha sokat számítana ezen a szinten, mindkettő nagyon idősnek számít a fejlesztésben.

Mert azt kell érteni, ahogy aki nem használ verziókezelő rendszert, az nem azért van, mert nem képes rá, hanem vagy kóros lustaság, vagy tudatos ellenállás, azaz hozzáállásbeli hiba. Megtanulni mindenki meg tudja a verziókezelőzést, aki programozni meg tudott tanulni. Itt ezen a szinten is minden a hozzáálláson és módszertanon múlik, nem azon, hogy kinek mik a képességei.

A másik, hogy a top nyelv x éves kitalálója valószínűleg elméleti informatikus szakember, és nem fejleszt a gyakorlatban. Ezért én semmiképp nem venném mérvadónak.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

Pont ebben a korban nagyon nem mindegy. Egy 60+ ember még elég gyakran aktív (más kérdés, hogy milyen hatékonysággal, lásd azt a személyt, aki kapcsán elindult az előző topic és ez a szavazás), viszont 1 70+ jó eséllyel már tényleg vagy nagyon kivételes eset, vagy csak hobbiként fejleszt.

Szoftverfejlesztőnek ugyan nevezhető, de elég nehéz dolga lenne másokat arról meggyőznie, hogy _jó_ szoftverfejlesztő. A kérdést meg inkább úgy tettem volna fel, hogy nem használ verziókezelőt, mert ha képtelen használni, akkor ott a tudatlanságnál nagyobb bajok vannak.

Tényleg az egyént kell keresztre feszíteni?
Gondolom a kérdéses cégnek van ISO9001 minőségbiztosítási illetve ISO27001 információbiztonsági tanúsítványa. Ezek mit írnak elő?
  - Ha semmit, akkor miért nem?
  - Ha előírnak, akkor ki a felelős a betartatásért és miért nem végzi a munkáját?
 

Rossz a kérdés ;) nincs köztük logikai összefüggés, de vitatkozni jól lehet róla...

Linus annak nevezhető volt régebben? Amikor azt találta mondani, hogy a .tar.gz patch-ek egymásnak küldése sokkal kifinomultabb, mint a CVS?

Van néhány alak, akinek ez kimaradt az életéből (igen, akár 2020-ban is). Ettől még lehet hogy olyan kódot tud írni, hogy a friss fejlesztők hadát lenyomja egyedül. Tehát igen, lehet ilyen fejlesztő.

Disclaimer: nagy megelégedéssel használok egyébként verziókövetőt, mind hobbi, mind munka projektekben.

Linus a Git-et 15 évvel ezelőtt írta. Előtte pedig Bitkeepert használt évekig. A Bitkeeper gondok miatt megvizsgált több _verziókezelő rendszert_ (nem fájlkezelőt), de egyik sem volt számára alkalmas. Akkor írta meg a Git-et. Nem volt a kérdés. Vagyis Linus minimum 15 éve verziókezelőben kezeli a forrásfáját. A kérdés pedig nem az volt, hogy minek volt nevezhető valaki 15-20 éve, hanem az, hogy minek nevezhető ma. 2020-ban. 

trey @ gépház

Zeneszeket tanitottam meg, hogy a _final, _final_master, _premaster_backup4, stb. elnevezesek helyett hasznaljanak inkabb gitet.

Script kiddie lehet valaki VCS ismerete nelkul. Szoftverfejleszto nem.

Szerkesztve: 2020. 09. 18., p - 16:33

Nem képes, vagy nem akar? (fenti hsz-ből a nem képes volt egyértelmű, de nem olvastam végig az egész thread-et... amiből kiderült volna, hogy esetleg előírták volna-e neki hogy használjon ?)

Mert nagyon nem mind1 a képlet.

Lehet csak annyi kellett volna hogy "Te béla, itt van ez a GIT, nézd így műxik, 1-2-3 nap és együtt megnézzük hogy is kell majd a továbbiakban kódolnod, stb" és akkor utána már használná (akármennyire is "védett korban van, nyugdíj előtt, trey-nek worksfortrey* , stb.)

1 Ha nem képes -> meg lehet rá tanítani -> ha nem lehet rá megtanítani, akkor is szoftverfejlesztő marad amíg el nem távozik az élők sorából. És itt bejöhet a "védett kor / nyugdíj előtt")
2 Ha képes, de nem akarja -> akkor is szoftverfejlesztő marad.... bár akkor a cégnek el kell gondolkozni hogy megéri-e "védett kor" ide vagy oda megválni tőle
3 Ha képes rá és ismeri is de lesz.rja akkor a 2. pont érvényesülhet... kirúgni a francba.

Senkitól nem fogod tudni elvenni a szakmát amit anno megtanult. Szoftverfejlesztő volt ~30-40 évig ? Programozó? Igen. Akkor az is marad.
Trey autószerelő volt, trey pl. nevezhető autoszerelőnek 2020-ban? Ez alapján + a fenti thread alapján erősen kétlem. De mégis csak a szakmája az az. Tehát nevezhető annak :)

Just my 2 cent

Egyrészt: igazából nem tudok olyan esetet mondani, amikor nem kell egy repository, amiben ott vannak a projekthez tartozó források, erre még a fejlesztői gépen elindított Gitlab is sokkal jobb, mint pusztán fájlrendszerben hagyni meghalni, másrészt a verziókezelő alapszintű használata egy fejlesztői alapkészség kellene legyen, akkor is van értelme egy workflow-nak, ha tökegyedül dolgozom egy tök egyszerű projekten, mert akkor nincs kupleráj.

-

És pont Gyuszk? Aki képes teljesen légből kapott faszságokat állítani verziókezelők kapcsán, hangerővel pótolva a fehér foltjait?

Túlléptem, csak tudod, az embernek, ha van emlékezete, akkor eszébe jutnak bizonyos dolgok, főleg, amikor valaki nagy hangon hülyeséget beszél, aztán meg később ad egy sommás egysorost a témában, hogy mekkora balfaszok a többiek.

de úgy emlékszem elismertem, és nincs is a tévedéssel semmi baj

Hát nem igazán. És alapvetően a tévedéssel nincs baj, akkor van baj, ha a tudatlanság mellé nagy hangerő társul, főleg olyan témában, aminek bruttó egy perc utánanézni.

Azt hittem, ez már nem téma. 14-15 évvel ezelőtt nagy vita volt abban a webstúdióban ahol dolgoztam. Végül az volt a döntő pillanat, hogy a megosztott meghajtón amin dolgoztunk véletlenül sikerült egy mappát átmozgatnom és ettől hanyatt dobta magát a többi kolléga rendszere... onnantól kezdve váltottunk SVN-re.

A kérdés nem csak az, hogy vissza lehet-e állni egy korábbi verzióra, vagy hogy több fejlesztő együtt dolgozzon. Az is fontos, hogy a verziókövető rendszer használata kényszerít a módszeres munkára. A delikvensnek el kell gondolkoznia azon, hogy mikor van megfelelő állapotban a kód ahhoz, hogy nyomjon a kolléga egy commit-ot.

A következő lépés ebben a fejlődésben az, hogy ne csak hetente vagy havonta commitoljon a növendék szoftverfejlesztő, hanem hogy úgy tagolja a munkáját, hogy naponta álljon elő egy működőképes kóddarab. De ez még nagyon sok cégnél és fejlesztőnél probléma.

A kérdésre válaszolva, nem, abban az értelemben, hogy az ember felelősségteljes szoftverfejlesztést végezzen, a verziókövető rendszer használata elengedhetetlen. Azt, aki a saját kedvtelésére irogat valamit notepadben, nem nevezném szoftverfejlesztőnek.

+1

A mai világban a verizókezelővel időt lehet megtakarítani. Az idő, pénz. Aki nem tud verziókezelőt használni, az hatékonyabb lehetne hosszú távon, ha tudna. Mint ahogy PHP esetén a PHPStorm vagy más IDE nagyon sok időt tud megtakarítani, mintha notepad-ben vagy hasonló editorral fejlesztene, majd kézzel commit-olna. Nagyon sok OOP fejlesztést, javítást IDE használattal gyors: egyből az adott helyre ugrik, felajánlja a class methódusait, stb, stb, amit notepad esetén nekem kell beírni, és nem csak kiválasztani. Lehet, csak idő.

Akiről a téma szól, aki nem használ verziókezelőt, egy változásokat nem szerető ember, és egyre nehezebb ez miatt az élete. Rossz szakmát választott, mert folyamatosan tanulnia kellett volna. Csoda, hogy még nem cserélték le, vagy kényszerítették rá: egy feladat, 1 commit. Szépen IDE-ben látná a változásokat és visszaállna a legutóbbi jó változatra, stb.

Sakk-matt,
KaTT :)

"A következő lépés ebben a fejlődésben az, hogy ne csak hetente vagy havonta commitoljon a növendék szoftverfejlesztő, hanem hogy úgy tagolja a munkáját, hogy naponta álljon elő egy működőképes kóddarab. "

Napi 1 commit?

Lehet egyedül vagyok vele, de ahány fájlon dolgozom és a módosítás nem tör semmit az nekem commit. Mivel elég jól szeparált a kód nagyon ritka, hogy 1-nél több módosítás 1 commitban megy be. Szerintem ez módszertan kérdése. (Ha pl egy osztályt szétbasznék ami borít mindent, akkor első körben leszármaztatom és azt módosítom. Kiragadott példa, azt gondolom ez kb mindig megoldható,  lehet esetenként több munkával.)

Félreértés ne essék, ideális esetben legalább pár óránként commitol a delikvens, de sok helyen még a napihoz is nehéz eljutni. Szépen szeretnek sunnyogni a fejlesztők amíg a sprint lejár és akkor derul ki, hogy mi a helyzet.

Ha pl egy osztályt szétbasznék ami borít mindent, akkor első körben leszármaztatom és azt módosítom. Kiragadott példa, azt gondolom ez kb mindig megoldható,  lehet esetenként több munkával.

Lehet, hogy csak túl röviden fogalmaztál, de ez LSP sértésnek hangzik. Én ezért szeretek interfacekkel dolgozni, mert csinálhatok egy új implementációt a régitől függetlenül.

Ha TDD-zel akkor egy commit minimum 2 fájlt érint. Ha refaktorálsz, érinthet többet is. Úgy nem commitolunk kódot, hogy az nem fordul, vagy nem futnak le rá minimum a unit tesztek (pl. git bisect miatt nem mindegy). Nem attól lesz kicsi a commit, hogy kevés fájlt érint, hanem hogy le tudod írni egy egyszerű mondatban, hogy mi változott.

Nos "ahány ház..." ugyebár. Dolgozni sokféle képen lehet. Kezdetben (~25 éve) zsonglőrködtem az archívumokkal és a könyvtárakkal, illetve "#if 0" verziókövetőt használtam. Aztán elmentem dolgozni, megismertem a verziókezelőket, és azóta egy szöget sem teszek arrébb nélkülük. Amikor először láttam ilyet (sourcesafe) amolyan hűha élmény volt. Kb. mintha minden este sötétben vacsizatam volna, és egyszer csak valaki megmutatja a villanykacsolót. Lenyűgöző volt látni, hogy egy általam megélt nehézséget ennyire elegánsan lehet kezelni.

El tudok képzelni olyan "csodabogarat" aki mindent más szemszögből lát, valamilyen részterületen nagyon penge (zseni?) és saját megoldása van mindenre, ebben érzi jól magát. Egy ilyen ember működésébe beleszólni hiba lenne, illetve nem is nagyon lehet. Ettől még azt mondani rá, hogy nem fejlesztő, azért erős lenne.

Ugyanakkor az átlag fejlesztőnek, és a csapatok 99% -ának nagyon fontos eszköz. Egy csomó olyan ki nem munkamenetbeli sajátosságot és fogást megtanít és mindennapossá tesz, ami egyébként nem lenne magától értetődő. Gyakorlatilag egy csomó tevékenységet "szabványosít", egyfajta közös nevezőt képez a közösségben, "nyelvezetet" teremt és egyszerűen megvitathatóvá teszt bizonyos problémákat.

Hogy egy hasonlattal éljek: papír alapon is meg lehet kommunikálni és munkát szervezni, csak minek?

Én, amikor találkoztam verziókövető rendszerrel (CVS) először, és megértettem, mi az és mire jó, azóta a hobbi projektjeimhez is használom. Kivéve mondjuk azokhoz, amik egy rövid fájlból állnak, amiket amúgy se változtatok azután, hogy megírtam azt a tipikusan nagyon egyszerű funkciót.

Szerintem aki nem képes verziókezelő rendszert használni, az lehet hobbi programozó, de nem lehet szoftverfejlesztő.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Szerintem ez így nem megválaszolható kérdés, először el kellene dönteni mi a szoftverfejlesztő. Sokaknak van igazsága, ha csak a codereket nézzük. Viszont ha nem akkor meddig lehet ezt tágítani (és most csak a technikai pozikra gondolok). Szerintem van olyan szint ahol nem ez az elvárás. Tekintve, hogy a fejlesztésnek vannak olyan fázisai, ahol még egy kódsor sincsen, sőt ha tovább tágítom akkor még rendszerterv se, akár még az algoritmus sem létezik amit használni fognak. 

Azt látom, hogy először ebben a definícióban kellene megegyezni, hogy mit értünk alatta. 

Igen, de nem profi/naprakész/hatékony.

Had írjak le egy sztorit:

Munkát kerestem, lehetett talán 98. Előző cégeknél CVS, PVCS volt használatban. És vim-et használtam, ctags-zel.

Volt egy cég, munkát kínáltak. Elfogadtam.

Kezdtem hétfőn. Számítógépet addigra még nem sikerült összerakniuk, szóval a hétfő elment kb. a sarokban egy széken ücsörgéssel.

Kedd. Számítógép továbbra sincs. Valaki beszélt egy kicsit a rendszerről, amit fejlesztett a cég, de a nap nagy része továbbra is semmittevéssel telt.

Szerda. Számítógép továbbra sincs. A főnököm, a vezető programozó, leültetett maga mögé (egy nagy teremben voltak összetolva az asztalok egy nagy téglalapot formázva, középen űr, befelé nézve ül a fejlesztő csapat, kb. a téglalap minden élén 3-4 ember. Szóval elkezdi nekem mutogatni, hogy milyen a rendszer felülete, stb. Mutatja nekem: látod, itt van ez a combo box, ebben van most 3 elem, megmutatom, hogyan kell beleírni még egyet:
Megnyitotta a Norton Commandert, tallózta a könyvtárakat, talált egy fájlt, megnyitotta (a NC beépített szövegszerkesztőjével. Nem volt se syntax highlight, se semmi programozás támogatás), megkereste a listát, ahol a combobox 3 lehetséges értéke volt, felvett egy negyediket, mentett, fordított, hátradőlt és mutatja.
Továbbra is csak 3 elem látszik.
Hmmm. Elkezdi vakarni a fejét, megnyitja újra a forrást, ott van a négy érték. Elkezdi látszólag random nyitogatni a forrásfájlokat és belenézni itt-ott mindenféle helyekre, valójában nem tudom, mit keresett, mert nem mondta.
De azt mutatta, hogy itt a ciklus, ami belemásolja az értékeket a combobox-ba egyesével, és csak nézi, keresi a hibát mindenfelé.
Egy darabig csak csendben hagytam, aztán megkérdeztem, hogy nem lehet-e, hogy azért nem jelenik meg a 4. érték, mert a for ciklus 0-tól VALAMICIMKE értékig megy, és talán a VALAMICIMKE esetleg 3?
Na ennek megörült, elkezdte bőszen keresni a VALAMICIMKÉt. Nem találta.
Szóval elbődült, hogy tudja-e valaki, melyik fájlban van a VALAMICIMKE.
Valaki tudta. Megnyitotta a fájlt, tényleg ott volt, hogy #define VALAMICIMKE=3
Jött a következő bődülés: Ki szerkesztette utoljára ezt a fájlt, illetve ki állította be a VALAMICIMKE értékét pont ennyire?
Tanakodtak, aztán megegyeztek abban, hogy Jóskapista volt az, de sajnos ő most nincs itt, szóval nem lehet tudni, miért pont ennyi az az érték.
OK, főnök úr átírta a 3-at 4-re, mentett, fordított, elindította a rendszert, és nagy büszkén mutatta, hogy a GUI-n bizony már 4 elemű a combobox.
Én meg csak arra gondoltam: Nem. Nem. Nem. Ezt nem. Nem.

Csütörtök reggel betelefonáltam, hogy nem érzem magam jól.

Pénteken betelefonáltam, hogy akkor felmondanék. Miért? Próbaidő alatt nem kell indokolni. OK.

Hétfőn bementem a papírjaimért.

Egy ideje nincsenek már rémálmaim :-D

Szóval szerintem már 1998-ban sem volt ez elfogadható, de azóta ráadásul eltelt 22 év.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Fél éven belül is láttam ilyet. PHP fejlesztő vállalkozóféle konkrétan a DEV szerveren dolgozott, amikor arról volt szó, hogy akkor itt a Git repository és ide kellene feltenni a forrást, akkor csak nézett, hogy minek, különben is ott volt 3-5 keretrendszer, beleírva mindegyikbe valami, mert a gyári dobozos cucc nem volt jó valamiért, aztán mindig panaszkodott, hogy a Git miatt nem megy ez-az, mert továbbra is a DEV szerveren dolgozott a /var/www volt az egész Git repo mindenestül, minden is ott volt. Na, ő dolgozott így, aztán mindig nyűgje volt, hogy ez-az nem megy, mindig megvádolta a környező szolgáltatásokat, aztán mindig kiderült, hogy ő baszta el.

Ha már a web / php bejött, sajnos láttam olyat, ahol a "komoly" webfejlesztő cég úgy adta át a weboldalt.

Hogy kiírta egy CD-re és itt van. Átadtuk a weboldalt és forráskódot.

Szerencsére nem csak nekem kattant el az agyam, hanem a megfelelő "osztálynak" is, hogy wtf :)

Nem vagyok fejlesztő de én is használom a fontosabb cuccaimnál. Gondolom egy fejlesztőnek még fontosabb.

honlapom http://dyra.eu/

Frankon kivul hasznal barki is !git verziokezelot?
Ha igen, miert?

Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Frankon kivul hasznal barki is !git verziokezelot? Ha igen, miert?

:D

Véleményem szerint a Git nem egy ultimate megoldás minden problémára, ha erőltetjük, akkor több hátránya lesz, mint előnye és lehet körbetákolni, aztán körbetákolni a körbetákolást.

Igen, én.

Nem vagyok (komoly) programozó, csak a saját dolgaimat tartom/fejlesztem svn-ben. A FreeBSD alaptelepítése tartalmaz svn-t, nekem teljesen jó.

Visszakérdezve: nekem milyen előnyt nyújtana a git az svn-hez képest? Személy szerint engem pont idegesített, amikor az egyik VPS-en változtattam valamit, git commit, és a másik VPS-en nem jelent meg (git push kellett még volna, ha nem tévedek). Sőt, a természetes számokkal jelölt verziókat nekem jobb követni, mint a "random" verziószámokat.

Most nem.

Használtam ClearCase-t.  Azért, mert azt kellett.  A dinamikus view-jában tetszett, hogy

  • környezeti változók beállításával (pl. másik terminálban) lehetett másik verziót nézni.  Igen, gitben van a git-worktree, de mivel az nem környezeti változóhoz kötődik, hanem másik alkönyvtárhoz, ezért nagyobb figyelmet igényel, könnyebb ottfelejteni (állapotával együtt), téveszteni, pl. véletlenül másik verziót módosítani, stb.
  • Ha clearmake-et választottunk build rendszerként, akkor származtatott objektumokat, pl. elkészített binárisokat is meg tudott osztani, és mások buildjében felhasználni.

Nem tetszett, hogy

  • csak fájlonként külön lehet commit-olni, nincs atomi changeset.  Emiatt körültekintés hiányában még inkonzisztens buildek is születhetnek.  Leírófájlokkal, tag-ek mentén kell összefésülni a verziókat.
  • Mindezt piszokdrágán.

Nem-re nyomtam és nem vagyok dev, de üzemeltetek az egyik nagy kedvencem egy erősen business critical cucc minden egyes rohadt kliense v1 jelzéssel jön, kizárólag a filenévből lehet következtetni arra, hogy mikori, automatizáltan teríteni nem lehet emiatt (meg egyéb gondjai is vannak), de rohadtul elkényelmesedtek, mert a világon kb 200 helyre kell hasonló szoftver és az átállás sajnos nem olyan egyszerű (kb lehetetlen inkább), és ők sem verziókezelőznek, se kliens se szerver oldalon.

ha olyan kódot írok, aminek sorainak száma >1, akkor követem csak (~mindig)

még az egyszemélyes hobbiprojekteknél sem szeretek szívni a saját conflictjaimal

$ mkdir projektnev; cd projektnev; touch .gitignore; echo "# Projektnev" >README.md; cp ~/.licenses/mit/LICENSE .; git init; git add -A; git commit -m "Initial commit 🚀"

4 és fél éve csak vim-et használok. elsősorban azért, mert még nem jöttem rá, hogy kell kilépni belőle.

Nem is értem a kérdést, semmi negatívuma sincs még akár 1 személyes projekteknél is a verzió követőnek, igaz hogy vannak esetek mikor egy fölös mankónak tűnik elsőre, de mindig jól jön.

Lett némi másodlagos szégyenérzetem, amikor megláttam, hogy az emberek harmada szerint "igen".

Nem találok ésszerű érvet a "Nem"-re. Azzal lehet anekdotikusan érvelni, meg eseti jelleggel példákat hozni, hogy milyen helyezetekben van el verziókezelő nélkül ez ember. De attól még aki szoftverfejlesztő, az tudja már használni. Nevezhető-e péknek, aki nem tud péklapátot használni? Csak azért mert bizonyos esetekben el van az ember péklapát nélkül, attól még tudnia kell használni.

------------------------
Everyone is a winner*

Szerintem egy dolgot kihagysz a számításból. Az, hogy egy coder nem tudja használni az ciki. Egy másfél órás videóból meg lehet tanulni, mondjuk gyakorol is az ember, akkor egy délután alatt megvan. Viszont szerintem a szoftverfejlesztő az nem egyenlő a coderrel. Mivel a fejlesztési folyamat nem csak implementációból áll. Valószínű, hogy az n+1. CRM rendszer megírásánál kb minden lépéshez kell, de ha valami olyat csinálnak ami eddig még nem volt, ahol még az algoritmusok se léteznek, akkor a kezdeti lépéseknél sokkal több a papír ceruza, meg a matek, mint bármi olyan amit lehetne verziókövetni.

Egyébként a kezdőknek tudom ajánlani az MIT egyik kurzusát, amit úgy hívnak, hogy Missing Semester, ott szépen megmutatják az alapokat, shell scripting, vim, git...stb, szokásos MIT minőségben. (mivel hup-ot kis kezdők is olvassák akik lehet nem teljesen vannak tisztában azzal miről is vitázunk nekik itt a playlist, nem gondolnám, hogy neked szükséged lenne rá)

https://www.youtube.com/playlist?list=PLyzOVJj3bHQuloKGG59rS43e29ro7I57J 

Amellett, hogy ezt gondolom és valahol egyet is értek, nem gondoom, hogy ennyire sommás véleményt kell megfogalmazni. Ilyen erővel lehetne Turing dolgait is alapnak gondolni, az is egy érdekes vita lenne. Én inkább úgy fogalmaznék, hogy aki nem áldoz be egy délutánt ezért, az nem zárja ki magát a szoftverfejlesztők közül, de az tény, hogy rendesen beárrazza magát. 

Ez teljesen igaz, csak amikor még tényleg papír, ceruza van, akkor nem scannelném csak azért, hogy verziókövessem, de még ha ezt mondjuk iPad-en és tollal csinálom, akkor is, van olyan rész, ahol ez nem éri meg. Amikor teljesen új algoritmust fejlesztesz és a matematikájával foglalkozol, akkor szerintem nem kell verziókövetés, gyakorlatilag gyártasz több száz oldal szart, mire összehozol valamit ami működhet, többféle megközelítést használsz, és igen, lehet valami nagyon jó ötletnek tűnik, de elbukik mondjuk a bizonyításnál, akkor azt elkezded visszakövetni, miért bukik meg...stb, és utánna megy a "kukába".  Azt nem kell követni. Amikor ez kikristályosodott és elkezdődik a rendszerterv, meg hasonlók akkor ott már símán lehet, mondom csak annyi a kérdés, hogy meddig terjeszted ki a szofrverfejlesztő fogalmát. Szerintem ez is beletartozik, de simán nagyon jó vitákat lehetne folytatni, arról hogy mit hogyan nevezünk. 

Ez egy nagyon hülye kérdés, és pont együttműködésre fogékony, gondolkodó emberekhez méltatlan. Mindenek előtt technikailag nevezhető bármi bárminek. Ami pedig az igazságtartalmát illeti:

Szoftverfejlesztő az, aki szoftvert fejleszt. Ha valaki például ír egy irgalmatlan zseniális botot a Wikipédiára, és így csak általános és nem explicit tudása van a verziókezelésről, az szoftverfejlesztő.

Nem kell náculni. Sokkal inkább összeadni a tudást, segíteni egymást.

Ahogy fentebb is páran utaltak rá, szerintem a verziókezelés sokkal általánosabb eszköz, mint a szoftver fejlesztés. Nagyjából mindenkitől elvárnám legalább azt, hogy hallomásból ismerje, akinek bármi köze van a számítógépekhez és bármilyen dokumentumot készít velük.
A verziókezelés szerintem az alapműveltség része kellene legyen, mint az írás-olvasás. Nem feltétlen egy specifikus rendszert kell megtanulni, pl. git, hanem azt kell felismerni, hogy erre vannak eszközök és az embernek nem kell feltalálnia magának a melegvizet.

Javaslat következő szavazásra: 2020-ban nevezhető embernek aki nem használ verziókezelőt? :)

Egyébként mikor random emberek informatikai problémája szóba kerül sokszor a verziókezelő volna a megoldás. De hogy magyaráznék el egy git diagnose change parancsot egy laikusnak?   https://git-man-page-generator.lokaltog.net/#965a5b4241e02c7b198e6357d7…

Csak egy vélemény: Akinek kalapácsa van mindent szögnek néz.

Aki még nem fejlesztett olyan rendszerben, ahol nem forráskód központú a kódolás - a fentiek szerint - valszleg el sem tudja képzelni, hogy forráskód és verziókezelő nélkül is lehet komoly programozási feladatot megoldani.

Pl: Egy JDE NER vagy egy SAP ABAP programot sem feltétlenül Git-ben vagy egyéb "verziókezelőben" kezelünk. Ettől még a googlin rákeresve az "ABAP developer" vagy "JDE developer" kulcsszavakra elég sok jól fizető állás ugrik fel. Nem gondolom, h. ezekben az adott esetben elég jól fizető állásokban dolgozó kollégákat ne lehetne  fejlesztőnek nevezni...

 

Egy JDE NER vagy egy SAP ABAP programot sem feltétlenül Git-ben vagy egyéb "verziókezelőben" kezelünk

Úgy érzem, végre tanulhatok valami újat. :)

"JDE NER" developer kifejezésre a Google 171 db találatot adott, biztosan nem ez a kivétel, ami erősíti a szabályt? :) Amúgy hogy szokás akkor követni a változásait egy ABAP programnak? Hogy tud rajta több ember dolgozni egyszerre?

Igen - valszleg kivételek, de az indító kérdés az volt, hogy "tekinthető-e fejlesztőnek".
Viszont az is igaz, hogy ezek a rendszerek egyfajta "beépített verziókezelő" szerűséggel rendelkeznek.

Google + "JDE NER developer " keresésre  --> "Nagyjából 462 000 találat (0,83 másodperc) " -ot kapok, de a JDE fejlesztő valóban ritka, mint a fehér holló.

Ezekben az eszközökben pl.: általában objektumokkal dolgozol, amiket ki- és becsekkelsz (szép magyar szó :) ) az adott fejlesztési környezetbe és transzportokkal mozgatod környezetek között. ABAPban is hasonló, de ha jól emlékszem ott a fájlok "történetét" (gyak. fájlverziót) jobban látni.
De ABAP verziókontrollra meg íme még egy gyors válasz: https://answers.sap.com/questions/8069151/question-on-version-control-in-sap.html

Viszont említhető még pl. a mára jobbára letűnt, de egykoron méltán hírhedt "Lotus Notes Application" fejlesztőrendszer is - na abban is voltak csodák.
( A tér és idő hiányában, ill. mert már jobbára a múlt jótékony homályába vész erre nem is térnék ki ... :)) )
Google + "Lotus Notes developer" --> "Nagyjából 3 150 000 találat (0,56 másodperc) "

U.i.: ... szvsz. lehet, h. a kérdés feltevőjének definiálni kellene, h. mit ért "verziókezelő" ill. "szoftverfejlesztő" alatt ...

Google + "JDE NER developer " keresésre  --> "Nagyjából 462 000 találat (0,83 másodperc) " -ot kapok, de a JDE fejlesztő valóban ritka, mint a fehér holló.

Nálam a JDE NER még pluszban idézőjelbe volt téve, valószínűleg emiatt a különbség. :) (Egyik rövidítés feloldását sem tudtam, így sok találat nem tűnt relevánsnak.)

U.i.: ... szvsz. lehet, h. a kérdés feltevőjének definiálni kellene, h. mit ért "verziókezelő" ill. "szoftverfejlesztő" alatt ...

Ebben lehet valami. :)

Alapvetően arra tippelnék, hogy ha valamiképpen megoldott a verziókövetés, akkor valóban nem érdekes, hogy azt külön szoftver biztosítja-e, vagy valami natívan tudja.

Nem a programozási feladat megoldásában segít a vcs, hanem a munkavégzésben. Nem a megoldható programozási feladatokat határolja be a hiánya, hanem a sw fejlesztő munkakörhöz tartozó egyik skill 2020-ban hogy tudod mire való egy vcs és használod is a munkádban. Nem tudom a SAP-nál ez hogy van megtámogatva. A JDE régebben szerintem a clearcase-el integrálható volt, a lehetőség megvolt. Nem tudom, volt-e olyan aki meg is tette. Pár éve van viszont olyan, hogy repository history. Meglepne ha a SAP-nál nincs ilyen célú rendszerelem, de JD Edwardson határozottan nem igaz, hogy ne lenne meg az eszköz különféle objektumok - és nem csak NER/C business function - módosítás követéséhez. De, ha nem lenne, akkor sem tartanék mérvadónak az egész iparági jógyakorlatra egy-egy ERP rendszernél jellemző munkamódszert. Ahhoz nagyon réspiac.

Aki még nem fejlesztett olyan rendszerben, ahol nem forráskód központú a kódolás - a fentiek szerint - valszleg el sem tudja képzelni, hogy forráskód és verziókezelő nélkül is lehet komoly programozási feladatot megoldani.

Dolgoztam olyan rendszerrel, ahol Rational Rose-ban UML-t rajzolgattunk, egy sor kódot nem írtunk sehová, és a RR modellből készítette a make több lépésen át a végleges cuccot.

Természetesen használtunk verziókövető rendszert, és természetesen a Rational Rose model fájl-t tettük bele.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Szerkesztve: 2020. 09. 19., szo - 18:03

Már többen leírták előttem, de azért mégis...

Évekig ment az egygépes, megosztott mappás, gzip-pel backup-olt fejlesztés. Aztán 8 évvel ezelőtt lett FtpVC, amiben csak checkout és checkin volt, de remekül ment. Amióta viszont git-egylet tag vagyok (magán projekt github, céges projektek git privát szerveren), nem tudom elképzelni, hogy ne legyek szolgalelkü, behódoló a git-nek:

- egy fájl esetén is írok kommentet

- sok fájlváltozás esetén is annyi commitot csinálok, ahány topic miatt változott ez a 10 fájl.

- néha 30 percenként commit-olok

- akkor is szépen teszem, ha az egy egyszemélyes projekt.

Szóval beleszerettem a szépségébe, főleg a git fogott meg: file diff-ek egyértelműek, file history nagyon jó, branch-et aktívan használom.

Amivel működök: github desktop, fork.dev kliens. Parancssorban csak git init --bare

Nem tudom más is csinálja-e, de én üzemeltetőként is használok git-et. Olyan gépeken ahol gyakori a változás, van hogy ez egész /etc-t bevágom egy repoba. A dns szervereken a mindig használok git-et. Egy szerveren change mangement-re is kiváló  eszköz. Én azt mondom lassan üzemeltetőként is elvárható a verziókezelés.

Egy, Egyből Kettő, Kettő meg Egy. Ez minden mérték alapja, minden élet csirája, számok, nevek építőköve.

Nem tudom más is csinálja-e, de én üzemeltetőként is használok git-et. Olyan gépeken ahol gyakori a változás, van hogy ez egész /etc-t bevágom egy repoba.

Hogyne. :)

Még a hobbiprojektek VM-jein is, a francnak sincs kedve fejből visszaemlékezni, hogy fél évvel ezelőtt mit (és főleg miért) állítottam át. Sőt, mivel több gépről van szó, amik ugyanabból az image-ből lettek, még branch-ek is vannak ha valami projekt/gépspecifikus dolog van: masterben ott az image default /etc, így mondjuk egy upgrade-nél elég a gépspecifikus branchet rebase-elni masterre.

(Ja, tudom, hogy ez nem a legoptimálisabb megoldás, meg létezik Ansible, Terraform, stb., de egyrészt nincs olyan sok gép, másrészt meg organikusan alakult így és nem foglalkozok vele annyit, hogy nagyobb átalakításokra lenne idő.)

Azt nem ismertem. Átnéztem a doksiját, de úgy tűnik az egy git, amiben lecserélték a git utasítást etckeeper-re :)

Első olvasásra nem jöttem rá mitől más mint a git.

Egy, Egyből Kettő, Kettő meg Egy. Ez minden mérték alapja, minden élet csirája, számok, nevek építőköve.

Tényleg nem kiforgatni akarom a mondatot, de mit jelent az, hogy valaki "használni tud egy verziókezelő rendszert"?

Ismer n+1 alap funkciót? Vagy ismeri A-tól Z-ig az összes funkciót? Nem is ismeri magát a funkció lényegét, csak a GUI-n ott van 3 gomb...?

Amúgy találkoztam már olyan idősebb fejlesztővel, akinek baromi jó meglátásai és megoldásai voltak, de mikor írtam neki, hogy küldjön be request-et a repository-ba, azt mondta az neki már túl macerás, inkább csináljam meg én. Ettől függetlenül szerintem az észrevételei és megoldásai alapján ő amúgy egy kiváló fejlesztő.

Akkor általánosítsunk. Nem tud vagy nem akar tanulni. Kortól független a kérdés. Lehet hogy évekkel ezelőtt zseniális fejlesztő volt, és valószínűleg ebéd vagy kávé mellett innám a sztorijait, de az informatika K gyorsan változik. Ha nem követed, lemaradsz, és ha lemaradsz, akkor már csak voltál jó. Nem kell mindent is megtanulni, az lehetetlen lenne. De a saját kis munkakörnyezete aktuális jó gyakorlataival és eszközeivel legyen már mindenki tisztában, aki nem csak a kora miatt senior. 

Kedvenc idevágó mondásom, ami akkor született, amikor némi zúgolódás után elfogadták a döntést hogy legyen a sztenderd a 11-es Java:

"Végülis nyolcasban is úgy fejlesztünk mint hatosban, azt meg tizenegyesben is lehet, így oké..."

Szerencsére azóta sokat javult a helyzet, de azért lássuk be, az ilyen gondolkodás kárt okoz. Nem véletlen fejlődnek a szoftverfejlesztés eszközei, legyen szó akár a nyelvről. Egyre kevesebb befektetett munkával egyre bolondbiztosabb szoftvert tudj készíteni egyre olcsóbb munkaerő bevonásával. Igen, szarul hangzik, hogy ha kóder vagy akkor előbb kiváltanak egy ázsiai kóderrel, majd őt egy automata vagy low code eszköz bevonásával, mert már az üzlet össze tudja kattintani a neki kellő támogató folyamatot. Ugyanakkor ez termel a leghamarabb üzleti értéket, mire elmagyarázná mit akart, már működik. Persze azért kevés üzlet tudja jól megfogalmazni az informatikai igényeit, pláne megtanulni algoritmikusan gondolkodni = hosszú még az út. A fejlesztő meg mindig is kelteni fog, hisz valaki gyártja ezeket az eszközöket, és valaki optimalizálja amikor már beáll a működés (lásd 5 fős cégben a pénzügy elvan egy Excel segítségével, próbáld ugyanezt egy 1000 fős esetén).

De ez nem változtat azon, hogy tanulni és alkalmazkodni kell. Aki már nem akar, az nem jó pályát választott. De egyre kevesebb az olyan szakma ahol egy életen át elég az a tudás amivel fiatalon belekezdtél.