Po przygodnie z promocją bloga za pomocą Wave’a wracam do głównej tematyki. Z uwagi na to, że jest sobota – znalazłem trochę czasu na obszerniejszy tekst. Mam nadzieję, ze Wam też uda się znaleźć czas na jego przeczytanie. Mam nadzieję też na ciekawą dyskusję.

No, może nie wszystko, ale to co Ty jako programista, albo Twój zespół programistów robi ręcznie.

Piszę tu w kontekście programowania w php – niestety czasem musimy nadganiać innych. Mam wrażenie, że php jest traktowany jako język “przejściowy” – jednak można przy jego pomocy robić rzeczy naprawdę dobre i przydatne. Ale to temat na inny wpis.

Postaram się podać kilka obszarów, w których automatyzacja może stać się Twoim przyjacielem.

Struktura bazy danych

Odpowiedz sobie na dwa pytania: czy nad moim projektem pracuje tylko jedne osoba? czy mam ustaloną i zaprojektowaną strukturę bazy danych przed rozpoczęciem projektu, której nie zmienię, choćby klient chciał zapłacić mi milion dolarów za dodanie systemu komentarzy?

Jeśli odpowiedź na nie brzmi ‘nie’ – zastanów się nad automatyzacją aktualizacji struktury bazy danych. I nie chodzi mi o problem migracji, który próbowałem ugryźć, a który okazuje się być dość skomplikowany. Napisałem nawet MySchemaShell i radził on sobie z migracją, dopóki nie zaczęły się zmieniać indeksy- straciłem do niego serce.

Okazuje się, że skomplikowana migracja nie jest potrzebna (pod warunkiem, że masz też dane “startowe” o czym poniżej). Okazało się, że wystarczy napisać prosty skrypt, który zrobi drop’a wszystkich tabel w bazie, a potem utworzy je na nowo. Przy czystej bazie danych MySchemaShell radzi sobie świetnie.

Zawartość bazy danych

Ten element łączy się z poprzednim. Bardzo żadko zdarza się, żeby aplikacja internetowa, którą piszesz obywała sie bez jakichkolwiek danych w bazie. Często bywa tak, że do staru aplikacja potrzebuje danych w bazie. Choćby reguł dla ACLi, czy innych rzeczy (zależą one często od rozwiązań, jakie stosujesz). Wypełnianie tych rzeczy jest strasznie upierdliwe. Robisz svn update, wchodzisz na strone – “Missing database”. Dodasz tą bazę – “Brak uprawnień ACL”, dodajesz uprawnienia – jakieśtam drzewo się nie generuje, bo w bazie nie ma głównego elementu (root) itd. W gorszym dniu zanim zabierzesz się do pracy masz już ochotę na godzinę sam-na-sam z workiem treningowym – tak Cię rozszadza. Szkoda na to czasu. Lepiej napisać najprosztszy mechanizm, który jedną komendą wypełni Ci bazę danymi startowymi. Jeśli taki masz – możesz się nie przejmować migracją bazy danych. Możesz jej strzelić DROPa i stworzyć na nowo i odpalić wypełnianie danych.

Tutaj obojętne jest w jaki sposób to rozwiążesz. Mogą to być zwykłe pliki sql, jeśli na prawdę nie masz czasu. Ja osobicie wolę rozwiązania niezaleźne od engine’u bazy danych. Dlatego dla struktury używam MySchemaShell (zmodyfikowany cake’owy SchemaShell). A dla danych startowych też skryptu Shell’owego który zwyczajnie wykonuje save na odpowiednich modelach, niedługo postaram się go wrzucić na tego bloga. Jeśli jesteś zainteresowany praktycznym przykładem przeczytaj o tym w jaki sposób automatyzuję instalację w aktualnym projekcie.

Testy czarnej skrzynki

Czyli testy od strony interfejsu. Bardzo prosto jest je wykonać z odpowiednim narzędziem. My używamy Selenium. Często jest tak, że “trzeba by przeklikać” system i sprawdzić, czy się nie sypie. To jest praca dla odpowiednio wytresowoanej małpki, więc szkoda na to Twoich programistów. Małpki są pod ochroną, a tresowanie nie jest takie proste jak zainstalowanie selenium – wybór jest więc prosty. Selenium za Ciebie przeklika całą aplikację. Trochę to trwa, więc nie ma co tych testów odpalać przed każdym commitem. Ale raz na iterację (zaraz się dowiesz kiedy dokładnie) warto odpalić wszystkie.

Unit testy

Gdy pierwszy raz się z nimi zetknąłem zrezygnowałem, bo testy kontrolerów i widoków były etdy koszmarem. Nie wiem, czy dalej są. Ale stosując zasadę, że “wszystko jest sztuką możliwego” doszliśmy do konkluzji, że wystarczą nam testy tylko w modelach. I nawet nie potrzebujemy 100% pokrycia kodu w tychże. Stosujemy unit testy w dla skomplikowanych reguł walidacyjnych i ogólnie wszędzie tam, gdzie dana funkcja jest skomplikowana. Na przykład, gdy chcemy powiązać element A z B (habtm), gdzie w powiązaniu istnieją daty. Daty danego powiązania nie mogą się zazębiać + jeszcze kilka skomplikowanych reguł biznesowych.

Oczywiście takie metody można napisać i bez unit testów (i TDD), ale w momencie kiedy nam się to uda – jedynym dowódem, że robią to co mają robić jest nasze przeświadczenie, że rozpatrzyliśmy wszystkie warunki. Poza tym, gdzy warunki się zmienią i tą walidację trzeba będzie zmienić – strach będzie tknąć się tej metody. Unit testy, które powstają przy okazji TDD nas przed tym chronią.

Jakie są efekty?

Oprócz braku negatywnych zjawisk, które opisałem przy okazji każdego zagadnienia – w prezencie dostajesz przyjemność. Przyjemność ta utrzymuje się dłużej w czasie, gdy projekt się rozrasta i staje bardziej skomplikowany. Chętniej zasiadasz do pracy, a to oznacza, że wydajniej pracujesz. Nie będę się rozpisywał – nie mam zamiaru reklamować mojego podejścia. Jeśli, któreś z tych elementów Cię irytuje – spróbuj zastosować.

Z własnego doświadczenia wiem, że zawsze warto mieć te mechanizmy w projekcie, który jest większy od “strony wizytówki” i ma trwać dłużej niż 3 tygodnie. Oczywiście jest to dodatkowy kod, który muszisz pielęgnować. Wymagania dot. tych skryptów mogą się zmienić. Ale koszty tych działań w porównaniu do zysków w naszym przypadku są pomijalne.

Zyskujesz przy okazji jeden bonus. Jeśli sotsujesz iteracje, to po każdej powinno się odbyć demonstracja jej efektów. Aby się odbyła potrzebujesz systemu, który działa. Wrzucasz go na serwer, odpalasz instalację, odpalasz unit testy, a na koniec testy interfejsu. Jeśli team jest zdyscyplinowany (a w stosując te rozwiązania czuje, że są dobre, więc je stosuje nadal) – usadawiasz się wygodnie w fotelu i patrzysz jak kolejne testy przechodzą. Potem cieszysz się, że masz demo, które działa.

Co dalej?

Jeśli masz te działające mechanizmy, możesz się zastanowić nad systemem (przepraszam za wyrażenie) Build’owania aplikacji. Właściwie masz już taki system, ale na przykład phing daje Ci dodatkowe możliwości (odpowiedz sobie tylko na pytanie, czy ich potrzebujesz).

Następnym krokiem jest system ciągłej integracji. To jest następny obszerny temat, którego tutaj nie opiszę, ale zachecam do zapoznania się z ideą – warto wiedzieć, co jest pod ręką.