Internet dla mas, czyli znowu o inżynierii oprogramowania

Ponad tydzień temu podzieliłem się z Wami moimi pierwszymi wrażeniami z realizacji projektu w war-roomie, zatem wypadałoby pociągnąć ten wątek w choćby minimalnym stopniu. Zwłaszcza, że w końcu uzyskaliśmy dostęp do internetu, z czego jesteśmy bardzo, ale to bardzo zadowoleni. W końcu można wczytywać filmy z YouTube z niezłą prędkością. Za to na korytarzu rozpoczął się totalny remont, zatem podróż do i z pokoju przez jakiś czas wiązała się z przymusowym ubieleniem (bynajmniej nie w Perwollu ani Vizirze), wchodzeniu do sali i komentarzem “o kurdę, ale naniosłem”.

W tym tygodniu praca zaczęła się na poważnie. Można to głównie poznać po coraz mniej czytelnych notatkach na tablicy - to oznaka, że nasze myśli są coraz bardziej pokręcone i zachowujemy się nienormalnie. Zaczęła się w końcu implementacja niektórych rozwiązań. Jest to o tyle fascynujące, że nasz projekt jest bardziej badawczy aniżeli zwykły projekt inżynierski (co nie znaczy, że tamte są złe), zatem siłą rzeczy niektóre rzeczy trzeba wymyślić. A potem kod wymaga dogłębnej refaktoryzacji, bo myśli wiją się w niesamowity sposób.

Ale nie o tym chciałem pisać - jeśli trafi się jakiś ciekawy problem techniczno-myślowo-implementacyjny, który będzie neutralny (nie będzie za bardzo "odkrywał" projektu), to pewnie o tym napiszę, ale główną misją tych notek jest dyskusja o inżynierii oprogramowania w praktyce.

Najpierw może przypomnę jak wygląda u nas struktura zespołu. Na samej górze jest promotor, który akurat nie bierze większego udziału w samych pracach (co nie oznacza, że nie jest nimi zainteresowany). Pod nim jest nasz główny opiekun (bezpośrednio zainteresowany projektem i jego rozwojem), którego wspiera inny opiekun, notabene koordynator poprzedniej wersji naszego systemu (ponieważ - niestety - rozbudowujemy coś, co zostało już w części napisane - pewnie o tym jeszcze pomarudzę). Kolejnym poziomem są nasi opiekunowie z IV roku, studenci specjalności Software Engineering, u których mnogość dokumentów, jakie muszą sporządzić, przekracza wszelkie oczekiwania wszelkich komisji i urzędników. Właśnie dlatego uważam, że proces powstawania gier komputerowych jest przyjemniejszy - o wiele mniej formalności, a jaka radość i zabawa. Przypadki użycia są dobre, ale uciążliwe w pisaniu, a w grach chodzi tylko o grywalność, fabułę i efekty (w tej kolejności). Ostatnim poziomem w strukturze jesteśmy my, programiści. Czasami odwiedzają nas właśnie opiekunowie - wtedy praca (i przeglądanie Internetu) schodzi na dalszy plan, a zaczyna się panel dyskusyjny o tym, co jest do zrobienia, jak to trzeba zrobić, po co i co to jest ten cholerny futbol amerykański, a także dlaczego tym jajem się tak ciężko rzuca. Przynajmniej jest weselej. Bo wiedzcie, że problemy są z grubsza interesujące w pierwszej fazie, czyli przy myśleniu nad nim, wstępnym projektowaniu. W samym projektowaniu oraz rozwiązywaniu problem staje się coraz mniej fascynujący, aż do pierwszych błędów typu "nie-wiadomo-dlaczego-to-nie-działa", kiedy człowiekowi nic się nie chce, bo nie wie co się dzieje (a Youtube kusi). Gdy w końcu uda się wyjść z takiego bagienka po mniejszych czy większych trudach, następuje znaczny wzrost fascynacji problemem, gdyż w końcu został rozwiązany (wtedy można też się chwalić wszem i wobec co się udało zrealizować). Można powiedzieć, iż jest to rozkład Gaussa, ale odwrócony do góry nogami.

Jak już wspomniałem, pracujemy na poprzedniej wersji systemu. Problemów z tym jest parę:

• Trzeba zwyczajnie "wbić" się w kod poprzedników, zobaczyć gdzie co jest
• Trzeba poznać technologię i biblioteki, jakich użyli
• Jest się trochę "zarażonym" architekturą poprzedniej wersji, nawet tymi niedobrymi elementami
• W naszym przypadku był problem, gdyż jedna biblioteka była przestarzała i już nie była w użyciu, a nowa nie była z nią zbytnio kompatybilna
• Był sam problem z importem do nowszej wersji IDE

Na szczęście, okazało się, że nie trzeba wykorzystywać całego kodu poprzedników, a jedynie poprzerabiać, w ostateczności napisać wszystko od nowa. Innym problemem jest technologia Web Services, z którą dotychczas nie mieliśmy do czynienia, a tutaj (i nie tylko tutaj) jest w szerokim użyciu. Na szczęście nie okazuje się to tak strasznie trudne, jak się wydaje, a zawsze lepiej wiedzieć coś więcej.

Niestety, jak dotąd nasza praca z metodologią XP nie ma zbyt wiele wspólnego, ale w gruncie rzeczy nie uważam, aby było to złe – na tym etapie projektu. Poniżej parę moich uwag odnośnie pracy w pierwszym i drugim tygodniu praktyk:

• Nie programujemy w parach, preferujemy podejście side-by-side, czyli “programowanie obok siebie”. Nie ma co prawda kontroli pisanego kodu, jednak w obecnym stadium, kiedy trzeba poznać wiele technicznych rzeczy (założyć i skonfigurować bazę danych, wczytać się w dokumentacje używanych bibliotek) nie miałoby to po prostu sensu. Side-by-side przyspiesza za to pracę w znacznym stopniu, gdyż każdy ma do dyspozycji swój komputer i zajmuje się konkretną częścią projektu.
• W naszym czteroosobowym zespole jesteśmy akurat tak podzieleni, że dwie osoby zajmują się jednym głównym “ficzerem” projektu, a dwie pozostałe – drugim głównym “ficzerem”. Ponieważ jedna i druga para siedzi koło siebie, przepływ informacji jest bardzo dobry, gdyż dwie osoby pracujące nad tym samym (w ogólności, gdyż najczęściej każda robi coś innego (np. pierwszy pisze, drugi ogląda Youtube, a potem pierwszy ogląda filmiki, a ten drugi pokazuje mu które)) mają bezpośredni wgląd w swoje monitory.
• Co prawda nie mamy obowiązku składania scrumowych raportów z poszczególnych dni/tygodni, jednak uznaliśmy, że jest to dobra metoda dokumentowania postępów i ewentualnie wymuszenie na nas korekt, jeśli nie idziemy “tą” drogą. Poza tym, pisząc o tym, co robiliśmy, co nas blokuje i co zamierzamy robić, niejako porządkujemy własną pracę, widzimy, jak daleko już zaszliśmy i czy nie trzeba czasem wzmóc tempa.
• Nie ma u nas stand-up meetings, czyli codziennych kilku- lub kilkunastominutowych rozmów na stojąco o tym, co nas czeka lub co już zrobiliśmy. To znaczy tego typu rozmowy się odbywają, ale nie są regularne, a jedynie pojawiają się wtedy, kiedy zachodzi taka konieczność. Przy ważniejszych problemach dana osoba mająca problem lub po prostu wątpliwość wstaje, podchodzi do tablicy, po czym zaczyna się przy niej dyskusja, do której dołączają zainteresowane osoby. Zaletą tego jest to, że choć drobna część dyskusji dotrze do ucha osób mniej zainteresowanych, a dodatkowe bodźce w postaci rysunków na tablicy czy chociażby podrzucania piłeczki wzmagają proces myślenia, kojarzenia i zapamiętywania.
• Właśnie – piłeczka. Niby drobna rzecz, ale bardzo potrzebna, co zresztą widać również przy burzy mózgów pod kierunkiem doktora Chałupy w znanym serialu. Kontakt z odbijającym się kulistym obiektem pożądania, podrzucanie go, ściskanie, odbijanie wpływa pozytywnie na człowieka. W dodatku można się na niej wyżyć, pogryźć ją, rzucić o ścianę i zrobić multum innych rzeczy. Wierzcie mi – taka piłeczka to skarb. Ile razy podczas rozmyślań nad kolejnymi etapami algorytmu zacząłem biegać po pokoju kopiąc piłkę przed sobą, odbijając ją od szafy, sufitu, ściany, aż w końcu wpadał mi pomysł, który mogłem zapisać i ruszyć dalej. Ogólnie przerwy w pracy są bardzo potrzebne, ale trzeba uważać, aby nie zajęły nas w pełni.
• Wspomniałem o wymyślaniu algorytmu i o tym, że trudno wejść w kod poprzedników, zwłaszcza, jak się nie zna technologii. Integracja nowych pomysłów ze starym kodem jest o tyle utrudniona, iż nie mieliśmy chociażby dostępu do bazy danych, która była niezbędna. Dlatego nie bójcie się pisać osobnych aplikacji, w których będziecie testować Wasze nowe rozwiązania i dostrajać je tak, aby skopiowanie kodu do właściwego projektu i ewentualne drobne przeróbki nie były zbyt bolesne. W tym czasie, kiedy pisany jest nowy kod przez jedną osobę, druga przygotowuje stare źródła do współdziałania z nowoutworzoną bazą danych – tak przynajmniej u nas to wygląda i na razie się sprawdza. Na razie, bo jeszcze nie integrowaliśmy naszych prac. Dlatego pewnie następne notki będą cenzurowane.

Jak widzicie, znowu o niczym konkretnym nie napisałem, aczkolwiek mam nadzieję, że rzucam coraz więcej światła na praktyki znane z inżynierii oprogramowania… w praktyce właśnie. Oby dalej nie było gorzej niż jest. I obym miał siłę pisać kolejne notki.

Pozdrawiam i dziękuję - SceNtriC