Tak jak wspominałem w swoim rocznym podsumowaniu – wraz ze zmianą cyferek w kalendarzu znacznej zmianie uległa moja sytuacja zawodowa. Co za tym idzie – musiałem przeprosić się ze znienawidzonym TFSem. Właśnie minął mój pierwszy tydzień z tym narzędziem i postanowiłem zebrać swoje dotychczasowe wrażenia.
Kontekst
Nie jest to moje pierwsze TFSowe randewu. Wcześniej korzystałem z niego dwukrotnie – zawsze babrając się jako programista tylko w kontroli wersji, bez łorkajtemów, uzerstoris etc. Efektem była gruba, kolczasta, płonąca i ociekająca żerczym kwasem ściana nienawiści między nami. Przyrzekałem sobie że “nigdy więcej”, aż tu nagle… No ale, życie przynosi niespodzianki.
Z pewnym zaskoczeniem zauważam, że do tej pory prawie nie poruszałem tego tematu na blogu, znalazłem raptem jeden post z tagiem “tfs”. Wygląda na to, że czas to zmienić.
Od strony “meneżera”
Zakres moich obowiązków się zmienił. Teraz interesuje mnie nie tylko kontrola wersji, ale także zarządzanie zadaniami, obserwowanie postępu, monitorowanie pracy zespołu itd. Co prawda od lat jako freelancer musiałem ogarniać całościowo większość tworzonych przez siebie projektów, jednak nie była to “praca zespołowa” w pełnym znaczeniu tych słów. Teraz jest trochę inaczej i z tej perspektywy nigdy na TFS nie patrzyłem. Muszę niestety przyznać: spod nowego kąta wygląda całkiem imponująco.
Mam porównanie z wieloma systemami do zarządzania projektem (to temat na osobnego posta, do którego notatki zbieram od roku) i w większości z nich samo “zarządzanie pracą”, czyli wprowadzanie i edycja zadań, jest o wiele wygodniejsza. Ale za to możliwości raportowania w TFS zrobiły na mnie spore wrażenie. Wszystkie te statystyki ubrane w wykresy i diagramy wyglądają bardzo użytecznie – odpowiednio wykorzystane faktycznie mogą dać kontrolę nad projektem i w miarę szybkie zorientowanie się w aktualnym stanie prac. Z czymś tak zaawansowanym jeszcze się wcześniej nie spotkałem – to był najsłabszy punkt innych stosowanych przeze mnie rozwiązań.
No i to właściwie tyle z perspektywy team leadera: średnio wygodne definiowanie/przydzielanie/edycja zadań i bardzo imponujące raportowanie. I uwaga: to ostatnie działa niesamowicie wolno, ale nie wiem czy to kwestia konfiguracji środowiska czy samego TFSa.
Od strony programisty
Tutaj wchodzimy w obszar, który wcześniej tak mnie do TFSa zniechęcił. Minęło kilka lat… i nic się nie zmieniło. Pierwsze wrażenie: podpinam się z VS pod ProjectCollection i kwadrans spędzam gapiąc się na komunikat “Contacting server to get list of items to update“.
Chcę zobaczyć kiedy projekt został aktualizowany, więc spoglądam na kolumnę “last check-in” w roocie projektu: a tam jakaś data sprzed lat. Dopiero zagłębienie się w odpowiedni folder podało mi w tej kolumnie datę, której szukałem. Szczęka mi opadła i kilka włosów od razu posiwiało – przecież to jest tak głupie, że aż nie do wiary!
No ale dobra, mam w końcu projekt na dysku, lecimy dalej…
Wchodzę w jakiś katalog z poziomu Total Commandera (dość często edytuję pliki poza VS, bo tak bywa o wiele sprawniej – bądź też pliki nie są dołączone do .sln), otwieram coś w notepad2, modyfikuję, zapisuję… i zonk. Plik jest readonly. Odhaczam więc ten atrybut we właściwościach pliku, zapisuję bez problemu, chcę zmianę pchnąć do repozytorium… i zaskoczenie. Okienko “Pending changes” nie widzi tych zmian, bo nie edytowałem pliku z poziomu VS! Jak sobie z tym poradziłem? Skopiowałem nową zawartość do schowka, w panelu “Source control” odnalazłem ów plik, wymusiłem przywrócenie jego poprzedniego stanu przez kliknięcie “Get latest version” i zaznaczenie jakichś 2 dziwnych checkboxów wymuszających nadpisanie tego co mam na dysku zawartością z repo, otworzyłem plik w VS, wkleiłem zawartość ze schowka i wreszcie poszło do repo. Damn, mamy XXI wiek, w ten sposób to Ulrich von Jungingen mógł aktualizować status bitwy pod Grunwaldem!!
Wiele razy za to zdarzyło mi się zobaczyć w “Pending changes” pliki, w których nic się nie zmieniło. I VS wie że nic się nie zmieniło, bo jak klikam “compare with previous version” to mi pisze że “files are identical“. A mimo to pokazuje je w “pending changes“. Debil.
System kontroli wersji powinien bardzo pomagać podczas przeglądania historii projektu w kontekście pojedynczych commitów. I tutaj również TFS zawodzi. Pierwsze co rzuciło mi się w oczy to brak “bocznego paska” w narzędziu do porównywania plików, pokazującego zmiany w skali całego pliku a nie tylko treści widocznej na ekranie. Wychodzi na to, że muszę przewinąć cały plik aby znaleźć wszystkie zmiany w nim popełnione – nie da się jednym rzutem oka ocenić gdzie zmiany zostały wprowadzone. W każdym innym znanym mi diff-tool taki “podsumowujący” pasek istnieje i nie wyobrażam sobie code review bez niego. Mało tego: to TFSowe narzędzie nie wykrywa zmian na poziomie znaków, a na poziomie całych LINII! Bardzo głupio to wygląda po przyzwyczajeniu się do “luksusów” oferowanych przez alternatywne rozwiązania. Dodatkowo ciężko jest obejść się bez myszki podczas przeglądania commitów – nawigacja klawiaturą nie jest zbyt wygodna ani wystarczająca. Na przykład w menu kontekstowym wyświetlanym dla zmodyfikowanych plików nie ma “akceleratorów”, czyli literowych skrótów pozwalających na wykonanie konkretnej komendy. Heh, mało tego – w okienku podglądu zadań można zobaczyć co prawda listę podpiętych pod dany task checkinów (w zakładce “linked items“), ale… nie da się z tego poziomu sprawdzić ani kto jest autorem commita ani kiedy został on przysłany do systemu! Nie to że domyślnie nie wyświetla się taka informacja, ale z tego co wyczytałem: po prostu się NIE DA.
A gdy chciałem cofnąć zawartość pewnego pliku o 2 commity to musiałem wykonać po kolei: “get specific version” -> copy -> “get latest version” -> paste -> checkin. Mam szczerą nadzieję, że da się to zrobić jakoś mniej morońsko, feedback w komentarzach mile widziany.
Heh, i jeszcze jedno: niejednokrotnie zbaraniałem, gdy TFS napisał że nie weźmie mojego checking ponieważ nie spełnia on “checkin validation” – ale nie powiedział mi dlaczego tak jest. Jedyne co zobaczyłem to “One or more checked work items failed the transition testing due to invalid field values.” – i musiałem dopytywać w zespole o co chodzi, co może być nie tak.
Konkluzja
Wniosek jest bardzo prosty: dla osoby niekodującej, a tylko patrzącej na wykresy, TFS jest narzędziem naprawdę niezłym. Jednak wrzucanie w to bagno programistów tylko dlatego, żeby meneżer miał fajne statystyki, wydaje mi się nie do końca odpowiedzialne. Albo może nawet: niemoralne:). TFS narzuca na zespół tyle idiotycznych, bezsensownych ograniczeń, że aż wierzyć się nie chce! W końcu to już chyba trzecia wersja tego narzędzia, a ja nadal preferowałbym SVN (którego też od dawna nienawidzę)! Straszne jest też to, jak wiele osób świadomie akceptuje te ograniczenia, bo “w sumie to nic innego nie jest potrzebne“. Jednak każda z takich osób, z którymi miałem kontakt, nie pracowała nigdy z alternatywą.
Są naprawdę o wiele, o wieeele (!!!) lepsze narzędzia do zarządzania kodem. I, uwaga!, da się je w miarę bezboleśnie z TFSem zintegrować. Ja już jestem w “tfs-free comfort zone” – moja cierpliwość wyczerpała się po 3 dniach, w czasie których i tak prawie wcale z kodem nie pracowałem. Co poniektórzy pewnie już się domyślają o co chodzi, ale o tym wkrótce.
Ale póki co zawołanie do programistów zmuszanych do użerania się z TFSem: zaciskajcie, jak Czesiek, zęby, których nie macie i nie traćcie nadziei, zaraz za zakrętem czeka lepsze jutro;). Część problemów przedstawionych wyżej da się obejść – o tym także niedługo postaram się napisać.
