Zanim jeszcze zdążyłem dojść do eksperymentu dyfrakcji, już rozgorzała dyskusja na temat tego, czy aby na pewno podążam prawidłową ścieżką i czy wykonuję prawidłowe doświadczenia z prawidłowymi założeniami. Zanim kupię sobie w końcu porządny wskaźnik laserowy, postanowiłem chwilę odetchnąć i napisać notkę kończącą cykl artykułów o lekkiej metodyce wytwarzania oprogramowania. Moje poprzednie artykuły są tutaj:
W ostatniej notce poświęconej programowaniu obiecałem napisać jak ulepszyć samo pisanie programów (tzn. przyspieszyć kodowanie i zarazem zapewnić jego jakość). Wymienię tylko kilka reguł:
Po pierwsze, zanim zaczniemy pisać kod programu, powinniśmy doskonale wiedzieć, kiedy nasz kod przejdzie kryteria akceptacji. Wyobraźmy sobie, że klient daje nam do wykonania następujące zadanie: "zaprojektować młynek do kawy". Podstawowe pytanie: w jaki sposób ten nasz młynek będzie przez klienta sprawdzony, że działa prawidłowo? Wyobraźmy sobie odpowiedź: "młynek zaakceptuję, jeżeli trzy losowo zapytane osoby na ulicy spróbują kawy zrobionej przez automat i powiedzą, że jest smaczna". W ten sposób, mamy jasno określony cel, którego będziemy się trzymać.
Dzięki temu uniknęliśmy całych "ton" dokumentacji zamieniając je na cele, chociaż z drugiej strony czy to jest na pewno efektywniejsze działanie? Skoro już działamy w "sztucznym świecie" komputerów, gdzie możemy napisać dowolny program, dlaczego nie zautomatyzować czynności sprawdzania "smaczności" kawy?
Zatrudniamy więc juz nie trzy, ale całą armię botów (testów jednostkowych) sprawdzających "smaczność" kawy produkowanej przez projektowany przez nas młynek. Za każdym razem, gdy poprawimy parametry młynka, napiszemy jego nową funkcję, klikamy "Uruchom testy", by otrzymać natychmiastową informację, co powinniśmy poprawić.
Dysponując takim narzędziem, informatyk nie lęka się wprowadzać zmian do tworzonego systemu, bo jego ewentualna usterka zostanie wychwycona przez testy jednostkowe.
A czym jest tak naprawdę pojedynczy test jednostkowy? Ano wyobraźmy sobie, że napisaliśmy klasę (zestaw funkcji) odpowiedzialną za wysyłanie i pobieranie danych z serwera FTP. Aby taką klasę przetestować, wyobraźmy sobie taki zestaw testów:
- Sprawdzamy czy plik lokalny istnieje na dysku
- Sprawdzamy czy plik docelowy istnieje na serwerze
- Usuwamy plik docelowy z serwera
- Sprawdzamy czy plik docelowy został usunięty z serwera (już nie istnieje)
- Wysyłamy plik lokalny z dysku na serwer
- Sprawdzamy czy plik docelowy już istnieje na serwerze
- Sprawdzamy czy długość pliku na serwerze jest taka sama jak pliku lokalnego na dysku
- ........
Oczywiście programista zakoduje taki zestaw w postaci kodu programu, który zostanie zrozumiany przez każdego drugiego programistę.
W ten sposób doszliśmy tylnymi drzwiami do jeszcze jednej zasady eXtreme Programming: czytelny kod programu powinien być jednocześnie jego dokumentacją. Dla programisty czytającego kod, sam kod powinien mu wystarczyć do zrozumienia jego działania.
Aby to było możliwe i aby projekt systemu nie runął niczym wieża Babel, zespół programistyczny powinien dysponować wspólnymi zasadami pisania kodu. Przykładowy C# Coding Style Guide Scotta Bellware w tym pliku PDF. Każdy programista zespołu powinien stosować te same wcięcia, te same zasady nazewnictwa m.in. powinien wiedzieć kiedy stosować wielkie lub małe litery w nazwach, kiedy stosować jakie przedrostki, kiedy jakie przyrostki. W jednej z notek napiszę dokładniej jak krok po kroku przeprowadzić refaktoryzację, czyli przejście z kodu nieczytelnego do czytelnego.
Skoro już programiści piszą elegancko we wspólnym języku, to pozostaje jeszcze jedna kwestia. W ciężkiej metodyce określany był często ścisły podział odpowiedzialności. Ty robisz to, Ty to, Ty to itd. Gdy dochodziło do złożenia fragmentów w jedną całość często okazywało się, że one nie całkiem do siebie pasowały.
Aby tego uniknąć, w metodyce eXtreme Programming jedną z zasad jest codzienna kompilacja całego systemu i gdyby którykolwiek z fragmentów nie pasował, to się go odrzuca, a następnego dnia pisze od nowa tak, aby był kompilowalny z całym systemem. Proces kompilacji powinien następować automatycznie i uwzględniać również nadanie nowego numeru wersji, zrobienie wersji instalacyjnej, przesłanie nowej wersji na stronę, rozesłanie do użytkowników wraz z opisem zmian itd. W tej metodyce codziennie dysponujemy kompletnym systemem, który jest codziennie coraz lepszy i kompletniejszy.
No i ostatnia w dzisiejszej notce zasada. Gdy polski oddział Borlanda dostosowywał się do działań centrali ogłaszającej nową strategię Agile, zorganizował seminarium. Prelegent opowiadał wtedy, że jedną z podstawowych zasad w XP jest programowanie w parach - w tym samym zdaniu storpedował sam siebie, że jest to szczytna zasada, lecz jego zdaniem niemożliwa do realizacji. Zapytałem dlaczego, to odpowiedział (o ile dobrze pamiętam) - bo tego się nie stosuje ze względu na efektywność (szybkość pracy programistów).
Odnalazłem na sieci film pokazujący współpracę kierowcy i nawigatora w rajdach samochodowych. Przepraszam za użyte tam słownictwo.
W programowaniu jest podobnie. Gdy jedna osoba klepie w klawisze (kierowca), druga w tym czasie (nawigator) wyszukuje objaśnienia "jak to zrobić" w książkach, omawia program z innymi programistami, patrzy na ekran i wytyka błędy, a takie przyspiesza pisanie programu i jednocześnie zapewnia większą jakość kodu.
Jeżeli do tego jeszcze dodamy, że pary się zamieniają zarówno miejscami (nawigator z kierowcą), jak i zmieniają w całym zespole, to mamy również zapewniony efekt synergii, gdyż cały zespół się szybko poprzez taką współpracę uczy. I co ważne: każdy z członków takiego zespołu może zmienić dowolny fragment kodu w całym systemie, bo się na tym zna.
To tyle jeżeli chodzi o programowanie. O dyfrakcji napiszę, gdy w końcu kupię ten porządny wskaźnik laserowy. Notki poświęcone lub dochodzące do fizyki kwantowej oznaczam przedrostkiem QF, a pozostałe notki są bez przedrostka.
