MalyDaemon

Oczywiście że tak !!!

Obecnie panuje przeświadczenie że systemy kontroli wersji są przydają się tylko w projektach w których uczestniczy wielu programistów. Nic bardziej mylnego. Jednak zacznijmy od początku

Czym jest system kontroli wersji

Narzędzia kontroli wersji, czy też systemy kontroli wersji pozwalają - przede wszystkim - na śledzenie zmian w plikach projektu wraz z upływem czasu. Możemy w każdej chwili sięgnąć do wersji z określonego punktu w czasie i zobaczyć jakie zmiany zaszły od tamtego czasu (a w większości narzędzi możemy zobaczyć kto je wprowadził).

Drugą właściwością jest możliwość pracy wielu programistów nad tymi samymi plikami. W standardowym modelu plików bardzo prawdopodobny jest następujący scenariusz:

1. Programista A otwiera plik x.c
2. Programista B otwiera plik x.c
3. Programista A dodaje nowe linie do pliku i zapisuje go
4. Programista B dodaje nową linię do pliku, zapisuje go co skutkuje usunięciem zmian wprowadzonych przez programistę A

Dlaczego tak się stanie ? Ponieważ obaj programiści otworzyli ten sam plik i każdy z nich wprowadził zmiany - jednak nie byli w stanie ich zsynchronizować. Tu z pomocą przychodzi system kontroli wersji. Każdy z programistów pracuje z własną wersją plików, które dowolnie modyfikuje i w miarę potrzeb wysyła do wspólnego repozytorium. Podczas wysyłania danych do repozytorium, następuje łączenie wszelkich zmian wprowadzonych przez programistę z innymi, które pojawiły się od momentu pobrania pliku.

Oczywiście czasem zdarza się że komputer nie jest w stanie automatycznie połączyć plików i wtedy następuje konflikt który trzeba usunąć ręcznie.

Dodatkową funkcją, często pomijaną, jest tzw. release management (nie znam dobrego polskiego odpowiednika - ogólnie można powiedzieć ze jest to zarządzanie “wypuszczonymi, kompletnymi” wersjami oprogramowania). Dzięki tej funkcji, kiedy projekt osiągnie określone stadium (np.: zostaną zaimplementowane wszystkie funkcje przeznaczone do wersji 2.3) możemy repozytorium oznaczyć odpowiednim znacznikiem (ang. tag) np.: REL_2_3. Wszystkie pliki znajdujące otrzymają taki znacznik, dzięki czemu zawsze będziemy w stanie pobrać pliki w takim stanie w jakim znajdowały się w czasie nadawania znacznika (gdybysmy tego nie zrobili, trzeba bylo każdy plik pobierać oddzielnie - sprawdzając która wersja była wtedy w użyciu).

Jeżeli następnie udostępnimy Klientom oprogramowanie bazujące na plikach oznaczonych odpowiednim znacznikiem, będziemy w stanie zidentyfikować jaką wersję plików posiadają nasi Klienci i w przypadku potrzeby naniesienia poprawek - wygenerowanie odpowiednich patchy.

Kolejną zaletą systemów kontroli wersji jest swego rodzaju backup. Jeżeli wszystkie pliki potrzebne do funkcjonowania oprogramowania są umieszczone w repozytorium to nawet w przypadku ich usunięcia czy modyfikacji jesteśmy w stanie powrócić do poprzedniej wersji. Oczywiście nie zabezpiecza nas to przez uszkodzeniem czy też utratą samego repozytorium.

To są główne funkcje, realizowane przez większość oprogramowania do kontroli wersji - zdarzają się narzędzia bardzo rozbudowane i bardzo potężne (np.: bitkeeper używany obecnie do rozwoju jądra Linuksa).

Czy system kontroli wersji jest dla każdego ?

Pisząc pierwszy projekt w zespole spotkałem się z opisanymi powyżej problemami. Utrata zmian, utrata plików, brak możliwości cofnięcia się do punktu w przeszłości - szukanie źródła błędów na oślep… Większość tych problemów znikneła od momentu wdrożenia kontroli wersji.

Odpowiadając zatem na postawione pytanie: Moim zdaniem warto. Jeżeli nawet jesteś jedynym programistą w projekcie moim zdaniem powinieneś używać systemu kontroli wersji. Natomiast jeżeli jest Was kilku to już na pewno powinniście ( o ile jeszcze tego nie robicie) zacząć z niego korzystać.

Osobiście używam systemu Subversion. Można także użyć klasycznego CVS ale posiada on kilka ograniczeń i jest stopniowo wypierany przez pierwszy z wymienionych programów. Oczywiście może się okazać iż dla Ciebie inne narzędzia będą lepsze bądź bardziej przydatne.

Często spotykam się z opiniami iż nie warto przyjmować osób na praktyki. Zazwyczaj takie jest zdanie menadżerów. Dlaczego tak się dzieje ?
Zazwyczaj praktykant jest przyjmowany do pracy w momencie zapotrzebowania na dodatkowy personel. Na przykład w momencie kiedy w firmie pojawia się nowy projekt. Niestety nikt nie bierze pod uwagę iż praktykantem trzeba się opiekować i poświęcić mu dużo czasu.

Zanim nowa osoba zapozna się ze środowiskiem, kulturą organizacji i przyswoi podstawową wiedzę upłynie ok. 1 miesiąca czyli zazwyczaj termin na jaki są wyznaczone praktyki. W pierwszym miesiącu szok spowodowany zmianą środowiska może całkowicie uniemożliwić przyswajanie wiedzy.
W drugim miesiącu można mówić o nauce. Wtedy praktykant wie na czym stoi, kogo może poprosić o pomoc i jakie są jego kompetencje. Jeżeli pracodawcy zależy na praktykancie, ten okres jest nawet ważniejszy niż pierwszy miesiąc.

Dopiero w trzecim miesiącu pracodawca może wykorzystać potencjał praktykanta. Poznał on już środowisko, nie czuje się w nim zagrożony i ma wiedzę potrzebną do wykonywania powierzonych mu zadań. Teraz można przystąpić do oceny czy jest on wartościowym nabytkiem.

Przy okazji poruszę kwestię praktyk płatnych. Osobiście uważam to za zły nawyk “młodych gniewnych”. Jeżeli grupa osób poświęca czas i nerwy na uczenie praktykanta, to powinno to być wystarczającym wynagrodzeniem dla tej osoby. Jako ciekawostkę mogę powiedzieć iż zdarzyło mi się spotkać z osobami, które pomimo zupełnego braku doświadczenia chciały otrzymywać stawkę już doświadczonego pracownika.

Rada zatem dla osób szukających dobrych praktyk: wybierajcie te praktyki, gdzie ich okres jest jak najdłuższy.

Z problemem wyceniania projektów IT spotkałem się wielokrotnie. Pomimo możliwości skorzystania z różnych modeli (np.: bardzo stary COCOMO) nigdy nie da się do końca przewidzieć realnych kosztów projektu. Dlaczego ?

Powodów jest kilka. Pierwszym z nich jest konflikt interesów. Zleceniodawca chce zapłacić jak najmniej za jak największą funkcjonalność, zaś zleceniobiorca najczęściej chciałby odwrócić tą sytuację. Klienci bardzo często nie wiedzą czego tak naprawdę oczekują. Jakie funkcje oprogramowanie (czy też rozwiązanie) ma realizować ? Jakie problemy rozwiązywać ? Zazwyczaj tego nie wiedzą a oczekują konkretnej wyceny - i tu właśnie pojawia się problem.

Jeżeli mamy za dużo niewiadomych w projekcie, możemy spróbować uzależnić koszt od czasu jaki zajmie nam projekt. Przykładowo Klient będzie nam płacił określoną kwotę za każdy tydzień pracy przy projekcie. Takie rozwiązanie oferuje nam godziwe wynagrodzenie a Klientowi możliwość wprowadzania zmian w trakcie trwania projektu (dodatkowym kosztem).

Zazwyczaj jednak Klienci nie godzą się na takie rozwiązanie, bojąc się iż zleceniobiorca będzie ich “naciągać na czas”, dlatego też będą dążyli do tzw. projektu ze stałym kosztem.

Projekt ze stałym kosztem zakłada iż określona funkcjonalność zostanie wykonana w określonym czasie i za określone wynagrodzenie. Jednak tu z kolei pojawia się problem dla wykonawcy - co jeżeli Klient kategorycznie zarząda wprowadzenia bardzo czasochłonnej modyfikacji ?

Pośrednim rozwiązaniem jest rozliczanie się za “kamienie milowe” (ang. Milestone). Kamień milowy jest określonym miejscem w projekcie np.: wdrożenie systemu zamówień przez internet lub stworzenie wstępnej wersji interface’u. W takim przypadku w umowie należy zawrzeć dokładny harmonogram projektu, z zaznaczeniem kluczowych momentów, oraz opisać dokładnie co wchodzi w zakres danego kamienia i jakie będzie wynagrodzenie po jego osiągnięciu.

Z moich doświadczeń wynika iż w przypadku sektora MSP koszt rozwiązania stanowi praktycznie jedyne kryterium wyboru. Klient nie zwraca zupełnie uwagi na inne parametry jak chociażby portfolio, doświadczenie itd.

Natomiast dużym korporacjom zazwyczaj najpierw zależy na funkcjonalności, dopiero poźniej na kosztach. Czasem nawet zdarza się iż Klient jest świadom tego że jest wiele niewiadomych i akceptuje rozwiązanie kamieni milowych lub uzależnione od czasu.

Twórcy oprogramowania cały czas będą oczekiwać uczciwego wynagrodzenia za swoją pracę zaś Klienci będą dążyć do minimalizacji kosztów (zazwyczaj za wszelką cenę).

Czy jest zatem jakieś uniwersalne rozwiązanie ?

Pornel, w swoim artykule Irracjonalne uwielbienie dla XHTML uważa iż nie wykorzystujemy zalet XHTML - jedyne co zrobiliśmy to oddzieliliśmy prezentacje od zawartości.

Moim zdaniem, XHTML stał się swego rodzaju symbolem. Gdyby go nie było, prawdopodobnie wielu webmasterów w ogóle nie zainteresowało by się powrotem do semantyki, wyrzuceniem tabelek i używaniem CSSów. XHTML stał się swego rodzaju marką pod którą kryją się poprzednio wymienione zagadnienia.

Podobnie jak mamy czasem problemy z przekonaniem niektórych “webmasterów” do nie używania tabel do layoutów, podobnie byśmy mieli problem z przekonaniem ich do porzucenia złych przyzwyczajeń. Jednak XHTML+CSS stały się powszechnie znane i na tym polega ich znaczenie.

Garr Reynolds od nie całego roku prowadzi swój blog na którym porusza kwestie efektywnych prezentacji. Z większością jego tez całkowicie się zgadzam.

Typowe prezentacje, przedstawione jako kolejne slajdy z dużą ilością wypunktowań są tak “normalne“, że mało kto zwraca na nie uwagę. Może i nie było by w tym nic złego, gdyby nie fakt iż większość “prezenterów” ma bardzo zły zwyczaj czytania prezentacji. Z ich ust płynie dokładnie taki sam przekaz jak ze slajdów.

Garr uważa iż znacznie lepszym sposobem, jest tworzenie sugestywnych slajdów, zaś prezentacją ma być nie to wyświetla rzutnik, zaś sam prezentujący.

W artykule Presentation Zen: The “Lessig Method” and sharing presentations over the web porusza problem publikacji prezentacji w sieci. Zamiast umieszczania samych slajdów powinno umieszczeć się filmy na których będzie widać zarówno slajdy jak i prezentującego. Wzmocni to przekaz poprzez nie werbalne metody komunikacji.

Ze swojej strony mogę dodać iż można wykorzystać darmowe oprogramowanie Microsoft Producer do stworzenia takiej prezentacji, jednak jakość stworzonej w ten sposób prezentacji jest średnia.

Jeżeli ktoś chciałby zrobić to naprawdę fajnie polecam wykorzystanie dwóch kamer (jedna filmuje prezentera, druga slajdy) i zmontowanie tego w Adobe Premiere.