Na rynku jest ono dostępne od lat, i przez lata wykorzystywane przez kolejne pokolenia programistów, które ze względu na nie, mają założone klapki na oczy. Do tego wielkie marki z niego korzystają, co nakręca biznes na to by z niego też skorzystać. W końcu jak już tyle osób z niego korzysta, i jest ono dostępne dzięki jednej z wielkich firm, jest wciąż rozwijane i co chwile się o nim pisze to nie może być one złe prawda?

Przychodzi nowa osoba do pracy i ma pewność, że z niego będzie korzystała, wszystko jest takie proste, takie… klikalne. Przecież problemów z nim nie ma… w ogóle…

No dobra, trochę nakłamałem, jako całość nie jest ono dostępne na rynku od wielu lat, ale jego część lub podstawa na której zostało ono zbudowane istnieje co najmniej od 1994 roku. Mowa tutaj o najcudowniejszym systemie kontroli wersji (i nie tylko – dodaje to dla tych hejterów co to zaraz wypomną) o nazwie Team Foundation Server a które jakoś przypadkiem ostatnio nawet do XCode się wkradło…

Dlaczego uważam, że to narzędzie niszczy każdego początkującego programistę?

Dlatego, że „work flow” jaki wymusza to narzędzie powoduje, iż z chęcią zrobimy wszystko by nie klikać check-in czy get latest version. Czyli po prostu oduczymy się korzystać z jakiejkolwiek kontroli wersji. Narzędzie to uczy jak pisać kod z jak najrzadszym kontaktem z kontrolą wersji – najlepiej by jej w ogóle nie było, bo jak ona już następuje to zaczyna się zabawa w zgadywanie czemu coś poszło nie tak. Do tego sam proces checkin nie należy do prostych rzeczy.

Czy aby na pewno chcecie odciągać rękę od klawiatury na myszkę by wybrać projekt, solution, zaznaczyć opcję check in, zmienić widok okna na checkin comment, znaleźć ID tasku do którego chcecie commit przypisać, kliknąć checkin i dowiedzieć się, że jest konflikt i zanim zrobi się checkin trzeba z mergować plik projektu, ale powoduje on, że znikają pliki przypisane do niego i to co powinno trwać 30 sekund zajmuje 20-30 minut, całkowicie was wyciąga z transu programowania i myślicie o tym co dzisiaj na obiad, bo jak tak dalej pójdzie to będzie już pora? (lol jakie długie zdanie)

Mogę się założyć, że tego nie chcecie, ale to nie wszystko, okaże się, że wasz task jest w innym team collection, by dowiedzieć się o jego ID musicie zmienić collection a to… powoduje zamknięcie waszego solution…

Kolejny przykład dodawania nowego pliku, CTRL+INS, c, name, enter i pisz…. Czekamy bo VS musi się z komunikować z TFS, zrobić checkout na project, odblokować readonly, poinformować kontrolę wersji, że nowy plik jest tworzony i dopiero wtedy pokaże się wam edytor. Taki plik szybko chekinujemy, następnie go kasujemy i chcemy dodać taki sam o takiej samej nazwie… tak, bez checkin się nie powiedzie.

Otwieracie już istniejący plik i checie go edytować, wiecie co trzeba naprawić, wciskacie literkę v i… czekacie, VS musi plik wycheckoutować.

Albo dostaliście task skopiowania solution z jednego team collection na drugie… …. … po 3h okazuje się, że przypadkiem usunęliście połączenie istniejącego solution z TFS, a to co przenieśliście krzyczy, że coś jest nie tak i będzie działało w trybie offline.

Programiści więc zaczynają kompletnie olewać VS pracując offline i męcząc się z atrybutem Read Only, lub zaznaczają cały projekt i robią checkout by więcej problemów nie mieć, potem checkin i 3h w mergowaniu zmian…

Przychodzi taki programista do domu i nawet nie chce słyszeć o kontroli wersji, wyrzuca te doświadczenia z pamięci, nie, on nie będzie z tego korzystał i tyle.

Microsoft zaś jeszcze bardziej utrudnił nam życie, zmienił UI do TFS, który teraz jest tak czytelny, że ja przeważnie zanim znajdę opcję która mnie interesuje to zawsze odłączę się od TFS – zamykając solution.

Ale… MS daje UI… on wiesz, UI, tak z VS klikam, zobacz, fajnie nie, o tutaj oo conflict, override server version, i tutaj patrz, łączy mi się to tak, że jak ja kliknę tutaj w task, oo oo, poczekaj, gdzieś tu był, yes close solution, tak w innym collection jest, jest o widzisz nie? Zajebiste, i to mówi, że ja skończyłem… ooo coś się nie połączyło, ok sam go zamknę, ale tak i to mówi, że task jest skończony nie? Fajne.

No właśnie on ma UI, jaki on jest, taki jest ale on jest, nowy programista pewnie nawet nie wylistyuje nazwy katalogów i plików rekurencyjne bez dat w danym katalogu za pomocą cmd, bo większość rzeczy jest klikalna. Tyle razy słyszałem już tą wymówkę, że aż mi się słabo robi: przynajmniej tutaj mogę wyklikać – a idź.

TFS wymusza w nas czyste zło i wszystko to co złe w programowaniu, nie daje możliwości rozwinięcia się a ubija w nas to co IMO jest najważniejsze, opanowanie dobrze kontroli wersji, walić to czy to GIT czy SVN czy Mercurial ogólnie chodzi o sam fakt, że przez te wszystkie problemy, wolność działania, powoduje on, iż zrobimy wszystko by nie dotykać kontroli wersji.

Dlatego, idąc do nowej pracy, lub zaczynając naukę, proszę was, nie wierzcie, że wszystkie narzędzia są tak toporne jak TFS, zobaczcie inne dostępne za darmo, opanujcie polecenia z command line, zacznijcie z nich korzystać codziennie, róbcie częste checkiny i się niczym nie przejmujcie. Dajcie sobie 2-3 tygodnie zabawy. Potem sprawdźcie jeszcze raz TFS… naprawdę chcecie z niego korzystać?

Nie dajcie sobie wmówić, że TFS jest bardzo dobrym narzędziem, bo umożliwia przy okazji zarządzanie projektem. OK jeżeli firma chce mieć TFS do zarządzania projektem to niech go sobie ma, ale niech od kontroli wersji się odczepi, to nie oni muszą z tym pracować na co dzień. Zresztą po co wydawać w ogóle pieniądze na to? To wszystko jest za „darmo” w sieci przykład GitLab czy też Redmine – który nie tylko z GIT współpracuje. Tego jest dużo, daje to podobne możliwości co TFS. Zanim ktoś wspomni, że TFS ma build server itp. to niech zrobi mały search… niech popatrzy sobie na TeamCity i inne rozwiązania. TFS naprawdę żyje tylko dlatego, że przez pokolenia zniszczył on już wystarczająco dużo istnień, które nie widzą świata poza nim.

Na koniec, wszedłem tutaj w użytkowanie TFS a nie czy git czy tfs i dlaczego centralny system zarządzania jest słaby a inny jest lepszy etc. Pewnie podobne problemy jak z TFS można mieć na luzie z SVN, ale to TFS jest dostępny w VS, i to w TFS idą firmy bo mają to wraz z MSDN.

Nie podałem wszystkich problemów z TFS jakie są, wystarczy powiedzieć, że get latest version nie zawsze ściągnie wam najnowszą wersję, czy też katalogu pustego nie można usunąć, czy nadpisanie zmian bo TFS nie wykrył, że plik na serwerze uległ zmianie. Tego jest masa, ale powód dlaczego TFS niszczy programistów pozostaje wciąż ten sam – jeżeli nie spowoduje on, że programista przestanie korzystać z kontroli wersji, to nauczy tak programistę korzystania z kontroli wersji jakby jej wcale tam nie było.

PS.: Tak, przez ostanie 3 dni natrafiłem na wszystkie te problemy i inne i mam dość, i tak Git-Tfs wymięka na tym projekcie. I Nie, nie zmienię pracy z tego powodu, że jest tam TFS, ale tak próbuje zmienić nastawienie ludzi do TFS i przekonać do innych rozwiązań. Nie, nie udało mi się to jeszcze.

PODOBNE ARTYKUŁYWIĘCEJ OD AUTORA

12 KOMENTARZE

  1. Na DevDay zaskoczyl mnie las rak po pytaniu kto uzywa TFS-a w pracy. Nie wiedzialem ze jest to az tak popularne narzedzie.

    Ciekawi mnie skad taka adopcja, skoro tyle zlego sie slyszy praktycznie na kazdym programistyczym kroku. Potrafi ktos odpowiedziec na to pytanie ? Menadzerowie ? Brak wiedzy o alternatywach ? Bajki o super intergracji z VS-em ? Czy moze niechec do command line-a ?

  2. Powodów jest wiele:

    Primo: w popapranym systemie licencjonowania by MSFT TFS jest w wielu przypadkach dodawany za darmo (jako VSTS). I jak tu nie używać czegoś, co dostaje się za darmo? ;P

    Secundo: TFS, ze wszystkimi swoimi wadami to jednak one-stop-shop, tj. zawiera kontrolę werję, workflow do zarządzania procesem developerskim, wsparcie testów, build server, itp. I to wszystko jakośtam pointegrowane. Czyli nie trzeba szukać narzędzi różnych vendorów i próbować ich ze sobą zgrywać. Odpalasz TFS i teoretycznie wszystko funguje od razu.

    Tertio: Wsparcie. Duże firmy, chociażby do celów audytowych potrzebują oficjalnego supportu dla narzędzi używanych w działalności operacyjnej. Taki np. Git dla Windows nie ma żadnego oficjalnego wsparcia. Tzn. owszem, jest duże i aktywne community, które każdy problem rozkmini w mgnieniu oka, ale to community nie bierze na siebie żadnych gwarancji finansowych i nie jest prawnie zobligowane do żadnego SLA, itp. Owszem, są firmy, które świadczą takie usługi (wsparcie) np. dla SVN (CollabNet), ale Microsoft jest bliżej, ma ustaloną renomę, itd., itp.

    I tak dalej. Długo by można – o tym, że jednak dla wielu ludzi najbardziej liczy się integracja z IDE, że wielu programistów ma problemy ze zrozumieniem rozproszonych VCSów (tak! muszę kiedyś coś więcej na ten temat napisać), że część firm po prostu kiedyś korzystała z VSS i boi się odejść od sprawdzonego rozwiązania, które jakoś tam działa …

  3. Ja w poprzedniej pracy mialem TFS i zaskoczyl mnie…pozytywnie. Bo wczesniej tylko slyszalem, jak wszyscy na niego narzekali. Co wiecej dobra integracja z VS pozwala na niezbyt bolesne mergowanie. Ponadto podoba mi sie mozliwosc latwego podejrzenia zmian przed kliknieciem check-in.

    Oczywiscie teraz, kiedy GIT jest zintegrowany z VS zapewne wiekszosc bedzie wybierala ten kierunek. Niestety w VS2010 i wczesniejszych tego nie bylo…i zapewne stad taka popularnosc TFSa.

  4. Taaaak… Niech może kolega spróbuje TFS 2012. Wsparcie dla lokalnej wersji roboczej jest w standardzie. Pod tym względem pracuje się jak np. w SVN.

  5. Co ty opowiadasz! Pracowałem z TFS, SVN i Gitem. Żaden kolejnych nie miał tak dobrej integracji z Visual Studio jak SVN. Ciągle zdarzają się w Gicie marge z d…. które jakimś cudem każą mi manualnie wybierać zmiany, których nikt inny nie ruszał, propozycje załączenia połowy plików z projektu, choć nie było w nich zmian albo ciche marge, które psują pliki projektu przy pullu. Nie wspominając już o tym, że musimy korzystać z MS projecta i Sharepointa żeby kontrolować postęp prac, który wcześniej był tak oczywisty w TFS-ie.

  7. Najlepsze zapamiętane teksty podczas pracy z TFS: “Możesz oddać web.config?”, “Zablokowałeś całą solucję i nikt nie może pracować”, “Dobra, odpala się, idę na kawę”, “Pobierałem z domu wersję… pół dnia”.

  8. **@Doker**

    Z GITem jedyny problem jaki mialem to poznanie jego zasad dzialania. Od kiedy wiem jak dziala to nie mam z nim problemu. Problem zas moze byc z GIT-TFS i tutaj mialem jazdy jak nigdy, glowie po stronie TFS choc i GIT czasami dawal mi popalic.

    Jezeli masz jakis konkretny przyklad kiedy masz ten merge z d lub problem z checkinem to daj znac, podaj kokretny przyklad i zobaczymy co da sie na to poradzic, a da sie napewno, sa chyba tylko dwie komendy ktorych cofnac sie nie da. Do tego, toola do merge mozesz z customizowac jak chcesz w GIT, Procent nawet o tym [ostatnio pisal](http://www.maciejaniserowicz.com/2013/09/12/git-mergetool/).

    Zas w TFS merge nie sa lepsze, o czym juz wspominalem chociazby w postcie [VS 2012 i TFS 2012](http://blog.gutek.pl/2012/12/06/vs-2012-i-tfs-2012-czy-chcesz-zostawic-swoje-zmiany-czyli-jak-popsuc-sobie-dzien) do tego inne problemy i nawet UI mu nie pomaga.

    Jezeli naprawde korzystasz z TFS tylko dlatego, ze jest on z integrowany z VS i mozesz za pomoca paru klikow cos zrobic, to zrob tak jak napisalem, przez pewien czas przestan korzystac z tego i zobacz jak to jest z command line. Moze dev pracujacy z VS sa wciaz wygodni, ale przez to tez nie sa wstanie wyciagnac wszystkiego z srodowiska programistycznego. Przynajmniej takie jest moje zdanie, dla mnie integracja z VS oznacza jedno: wolniejsze dzialanie VS, im wolniej on dziala, tym mniej chce mi sie go odpalac i tym wiecej pracy przenosze na inne proste edytory tekstu.

    PS.: dalej uwazam ze VS jest najwolniejszym ale najlepszym srodowiskiem dev jakie powstalo i prosze nie mylic tutaj TFS z VS :)

  9. **@nick**

    tak nie korzystalem i nie zamierzam :) nauczylem sie z TFS miec tylko tyle kontaktu z nim co kot naplakal. I nie interesuje mnie co MS po X latach prosb i blagan dev wprowadzi do tego narzedzia.

    TFS jest slabe i bedzie slabe w zarzadzaniu wersja do poki nie zmieni podejscia calkowicie do tego – czytaj nie napisze nowego serwea kontroli wersji.

    To czy teraz mozesz pracowac lokalnie czy tylko na serwerze, ok, pewne rzeczy by to ulatwilo, ale i tak plik vssscc jest tworzony, tak czy siak TFS merge bedzie mial problemy z mergowaniem. Zas checkin robi caly czas to samo, wrzuca plik na serwer, masz plus ze nie czekasz na edycje i wycheckoutowanie pliku, ale to tak jakbys wzial przeciez “checkout solution”, sa to tylko workaroundy na wiekszy problem.

    Kroki jakie wykonuje teraz MS w strone community mowia i pokazuja, ze MS tez uwaza iz TFS source control wcale az tak wysmienitym pomyslem nie jest.

    Zas taka mala anegdota (rozmowa z przed 3/4 lat): na pytanie do VS team, z jakiego source control korzystaja i czy to jest TFS, VS team zaczal sie smiac i powiedzial, nie korzystamy z solidnego rozwiazania do kontroli wersji.

  11. Nie miałem przyjemności z TFS-em (brak TFS-a jest powodem dla którego można składać CV do moich pracodawców), powiem szczerze że nie próbowałem go użyć głównie dlatego że narzeka na niego Maciek. Bawię się ostatnio Visualem 2013 i powiem że łatwość z jaką integruje on się z Gitem zaskoczyła mnie pozytywnie (nawet nic nie instalowałem). Niestety w one-man-project ciężko zweryfikować jak sprawuje się Merge (brak Gita/Mercuriala jest powodem dla którego nie należy składać CV do moich pracodawców).

  12. “tak nie korzystalem i nie zamierzam (…) I nie interesuje mnie co MS (… )wprowadzi do tego narzedzia (…)” W tym momencie cała dyskusja się kończy. TFS jest zły bo jest be a na dodatek od Microsoftu.

    Sam używam TFS wersji 2008. Nie twierdzę, że jest to idealne narzędzie. Ale wersja 2012 jest naprawdę świetna. A większość problemów wynika nie z kontroli wersji tylko z samej struktury projektów VS (np po co jest przechowywana liczbowo ilość projektów w solucji -> oczywiście, że się rozjedzie przy pierwszej próbie dodania projektu przez 2 osoby w tym samym czasie). TFS no naprawdę bogate narzędzie, a przy tym świetnie zintegrowane z VS i oferujące niezły support. Kwestia odpowiedniej konfiguracji, a przede wszystkim zapanowania nad własnymi procesami.

Comments are closed.