Niemal z każdej strony słyszymy, jak wiele możemy zyskać angażując się w projekty typu open source. Bardzo często podkreślany jest fakt, że jest to dobrze postrzegane przez potencjalnych pracodawców, wpływa pozytywnie na rozwój całej społeczności lub zwyczajnie daje całą masę praktycznego doświadczenia. Nie chodzi tutaj oczywiście o nasze solowe projekty wrzucone na GitHuba, ale projekty tworzone w zespołach.

Najlepszym przykładem są tutaj różnego rodzaju biblioteki, jak na przykład Almofire na iOS, czy ButterKnife na Androida, ale do tej kategorii zaliczać się również będą mniejsze, hobbystyczne projekty tworzone przez niewielkie grupy programistów. Ważne jest, aby projekt był tworzony przez zespół. Na projekty open source nie trzeba wcale poświęcać całego wolnego czasu. Wystarczy nawet kilka godzin w tygodniu, aby czerpać z nich wymierne korzyści.

Postaram się opisać Wam wszystkie zalety na podstawie własnego doświadczenia, przedstawię również dlaczego moim zdaniem angażowanie się w projekt open source w pełnym zakresie czasowym może nie być najlepszym rozwiązaniem. Na tym jednak skupię się na samym końcu.

 

 

 

pierwszy projekt open source

 

 

W listopadzie zeszłego roku udało mi się dostać na kurs online organizowany przez Udacity do spółki z Google. Pisałem o tym co nieco w tym artykule. W lutym udało mi się przejść do następnej fazy. Kurs ogólnie całkiem fajny. Jego największym atutem okazał się fakt, że udało mi się nawiązać współpracę z programistami / programistkami z całej Polski. Wspólnymi siłami zaczęliśmy tworzyć aplikację na Androida, która w założeniach ma pomagać w adoptowaniu zwierząt ze schronisk. Tutaj macie link do GitHuba:

 

Psiak App

 

Niestety na chwilę obecną projekt został zamrożony, bo jak to w życiu bywa, każdy ma różne sprawy na głowie. W przypadku naszego zespołu przeszkodą okazały się głównie obowiązki służbowe. Niemniej doświadczenie, które udało nam się wspólnie zdobyć przez te kilka miesięcy jest (przynajmniej z mojego punktu widzenia) nie do przecenienia. Przede wszystkim była to bardzo fajna przygoda, do której mam nadzieję jeszcze powrócimy. Ale co konkretnie zyskałem pracując nad tym projektem?

 

 

Komunikacja w zespole

 

 

Punkt szczególnie ważny dla początkujących programistów. Otwarta komunikacja jest dzisiaj podstawą sprawnie działających zespołów deweloperskich. Z pozoru rzecz wydaje się oczywista. Nie ma nic skomplikowanego w rozmowie z drugim człowiekiem. Jednak kodując solo jesteśmy Panem / Panią sytuacji i nie musimy brać pod uwagę zdania innych osób. Sami decydujemy jak dana funkcjonalność ma zostać zaimplementowana lub jaka biblioteka ma zostać użyta. W zespole, co oczywiste, decyzje należy podejmować na drodze dyskusji i porozumienia. Decyzję większości zespołu trzeba będzie uszanować. Bardzo ważna jest tutaj umiejętności przedstawiania swoich pomysłów / potrzeb / argumentów w jasny i czytelny sposób. A tego nie nauczymy się pracując w pojedynkę.

 

 

Bardzo prawdopodobne jest również, że nasz zespół zdecyduje się na jedną z wielu platform, które wspierają komunikację oraz organizację pracy. To świetna okazja do zdobycia doświadczenia również na tym polu. Często czytając ogłoszenia o pracę, możemy znaleźć w wymaganiach wzmiankę o „mile widzianym” doświadczeniu z platformą Jira lub innym podobnym narzędziem. Akurat nasz zespół zdecydował się na skorzystanie z Trello do śledzenia postępów w projekcie oraz Slacka do codziennej komunikacji. Wybór konkretnego narzędzie nie ma aż tak dużo znaczenia, ponieważ większość z nich działa na podobnej zasadzie. Ważnym jest, aby nauczyć się jak można zwiększyć produktywność zespołu korzystając z dostępnych narzędzi.

 

 

Sposób pracy innych programistów

 

 

Krótko po tam jak rozpocząłem naukę programowania, bardzo zaczęło zależeć mi na tym, aby dowiedzieć się jak do rozwiązywania zadań oraz pisania kodu ogólnie podchodzą inny programiści. W moim przypadku nie było mowy o stażu stacjonarnym (za stary jestem 😋), czy zatrudnieniu w jakiejkolwiek firmie ze względu na śladowe ilości doświadczenia. Zostało mi oczywiście przeglądanie kodu open source oraz czytanie różnego rodzaju artykułów, jednak w obu tych przypadkach miałem do czynienia z czymś co już się dokonało. Nie było możliwość dokładnego przeanalizowania toku rozumowania danego programisty, zrozumienia jak doszedł do tego konkretnego rozwiązania. Pracując w zespole możemy w każdej chwili zapytać naszego kolegę / koleżankę z zespołu i wypytać się o szczegóły. Trudno opisać słowami jak pozytywnie wpływa takie doświadczenie na nasz rozwój. Możliwość spojrzenia na problem z innej perspektywy pozwala na podniesienie naszych umiejętności na poziom nieosiągalny podczas samodzielnej pracy.

 

 

Code Review

 

 

Praca nad projektem open source z całą pewnością wpłynie pozytywne na jakości naszego kodu. Nawet jeżeli będzie to niewielka poprawa to warto. Podczas samodzielnej nauki programowania bardzo łatwo jest nabrać złych nawyków programistycznych. Niby kto ma nam powiedzieć, że robimy coś źle?

 

 

Pomimo bardzo dużej ilości dobrych materiałów w sieci (i jeszcze większej ilości kiepskich) trudno jest czasami odnaleźć właściwą drogę. Autorzy artykułów opisują stosowanie dobrych praktyk, ale z uwagi na oczywiste ograniczenia prezentują oni tylko pewien wycinek całości. Kiedy usiądziemy już do pisania kodu to bardzo często okazuje się, że nie do końca wiemy jak dopasować do siebie wszystkie klocki. Wysoce prawdopodobne jest że w zespole znajdzie się osoba, która będzie miała większe doświadczenie lub zwyczajnie będzie lepiej „łapać” dany temat i dzięki temu wskaże nam właściwy kierunek.

Podczas pracy nad aplikacją PsiakApp wprowadziliśmy zasadę, że każda zmiana, która miała być połączona (merge) z gałęzią (branch) „develop” na GitHubie, musiała w pierwszej kolejności otrzymać recenzje dwóch innych programistów. Oczywiście w taki wypadku musicie się przygotować (zwłaszcza na początku) na bolesny kontakt z ziemią, ale właśnie o to w tym chodzi 😎 Nikt nie tworzy kodu idealnego 😅.

 

 

Przyswajanie nowej wiedzy

 

 

Bardzo ważny punkt bez względu na to na jakim właśnie jesteśmy etapie. Tempo nauki nowych przy projektach open source rzeczy jest powalające. Samotne programowanie nie będzie nigdy w stanie dostarczyć nam takiego doświadczenia. Każda osoba posiada inny zakres wiedzy, którą może podzielić się z nami podzielić. W naszym zespole znajduje się na przykład doświadczony programista, który bardzo dobrze orientuje się w architekturze MVP na Androida. Przygotował on przykładową implementację, tak aby każdy mógł zobaczyć jak to wygląda na żywym organizmie. Następnie na jednym ze spotkań (przez Google Hangouts) wyjaśnił jak wszystkie elementy zostały do siebie dopasowane. Uwierzcie mi na słowo, że żaden tutorial nie wyjaśni tego lepiej 🤩.

Do tego dochodzi jeszcze czynnik motywacyjny. Jeżeli widzimy, że są w zespole osoby posiadające większy zakres wiedzy od naszej, to jest bardzo prawdopodobne, że będziemy chcieli im dorównać i włożymy więcej wysiłku w naszą naukę. A najlepsze jest to, że w zasięgu ręki będziemy mieli osoby, które nas w tym wesprą. Jeżeli zespół powstał w wyniku oddolnej inicjatywy, to jest wysoce prawdopodobne, że panuje w nim atmosfera wzajemnego szacunku i zaufania. A to najlepsze warunki do rozwoju 😉.

 

 

To po prostu dobra zabawa

 

 

Praca nad projektem open source kryje w sobie niesamowite pokłady czystej frajdy. Mamy niemal pełną dowolność (w ramach zespołu) w wyborze technologi. To najlepszy czas na skorzystanie z najbardziej „trendowych”, branżowych nowinek. Możemy na przykład napisać aplikację całkowicie w oparciu o programowanie reaktywne lub iść na całość i stworzyć coś w Flutterze. Tutaj nie ma ograniczeń. W projektach open source chodzi przede wszystkim o to, aby zdobywać nowe doświadczenia, a nie powtarzać w kółko to samo.

 

 

Czy to jest dla każdego?

 

 

Udział w projektach open source to bardzo szczytny cel i wiąże się z nim wiele korzyści. Jednak moim zdaniem są sytuacje, w których warto się chwilę zastanowić, zwłaszcza jeżeli planujemy zaangażować się w projekt w większym wymiarze czasowym. Często jest tak, że w naszej głowie siedzi pomysł, który nie daje nam spokoju. Na przykład komercyjny projekt, który potencjalnie pozwoli nam na osiągnięcie upragnionej niezależności finansowej, a ta pozwoli z kolei na realizację kolejnych pomysłów i poświęcanie czasu na rzeczy, które naprawdę mają dla nas znaczenie.

W takim momencie warto zastanowić się, co jest dla nas ważniejsze. Zainwestować swój czas we własne pomysły czy uganiać się za branżowymi trendami ( w tym wypadku projektami open source)? Wydaje mi się, że wiele osób zapomina o tym, że czas to bardzo ograniczony zasób i nie da się cofnąć pewnych decyzji. A może warto iść za tym cichym głosem, który podpowiada nam, że pomysł, który siedzi w naszej głowie od dłuższego czasu, jest strzałem w dziesiątkę? Warto postawić na siebie i robić to co nam w duszy gra.

 

 

Słowo na drogę

 

 

Jak sami widzicie udział w projektach open source wiąże się niemal z samymi zaletami, pod warunkiem, że w pełni świadomie podejmujemy nasze decyzje. Z całą pewnością każdy powinien choć raz spróbować swoich sił w takim projekcie, choćby z czystej ciekawości. Bez ideologii open source nasza branża wyglądałby zupełnie inaczej. Jej siłą jest społeczność, która poświęca swój czas, aby stworzyć niesamowite narzędzia, dostępne zupełnie za darmo. Z całą pewnością warto jest być jej aktywnym uczestnikiem 😇.

 


 

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *