Aby nasz kod stawał się coraz lepszy, elastyczniejszy, bardziej przejrzysty powinniśmy stosować wiele różnych narzędzi. Ich dobór powinien zależeć od wymagań projektu, gdyż nie zawsze potrzebujemy wytaczać armaty na proste Hello World. Generalnie ich dobór w dużej mierze będzie zależał od docelowego odbiorcy. Projekty możemy podzielić na 3 główne grupy:
- własne – pisane na potrzeby chwili, do rozwiązania dręczących nas problemów
- na zlecenie – pisane w pojedynkę, ale gdzie wpływ na naszą pracę ma zewnętrzna osoba
- pisane w grupie – czy OpenSource, czy komercha, nasz kod wpływa na innych, a kod innych na nasz
Można to także traktować jako swego rodzaju rozwój. Jako młodzi adepci sztuki programowania zaczynamy od dłubania w domowym zaciszu, powoli otwieramy się na świat i przyjmujemy nowe wyzwania. Rozwija się także nasz warsztat. Problem jedynie w tym, żeby przechodząc między poszczególnymi poziomami nie kastrować siebie jako programisty. Bo jasnym jest, że wielokrotnie będziemy chodzili w górę i w dół tej listy.
Projekty własne
Mój ulubiony typ. Gdzie nikt nas nie goni, gdzie możemy spokojnie dopracować szczegóły. Myślimy tylko i wyłącznie o własnych potrzebach. Fajnie, ale to wymaga niesamowitej dyscypliny. Ile razy brak deadline’u paradoksalnie sprawił, że pomysł poszedł do kosza? Ile razy zaczynaliśmy od nowa, bo nie było tak dobrze jak byśmy chcieli?
Znacie ten stan? Nowy pomysł, problem, ołówek, kartka w dłoń i wypisujemy ogólne założenia. Chcemy jak najszybciej zasiąść przed edytorem. Co bardziej doświadczeni założą jakieś repozytorium.
Ktoś powie czego chcieć więcej. Najważniejsze, żeby API było przyjazne, dopracowane, spełniało nasze wymagania. To krótki projekt, odnajdziemy się we własnym kodzie, więc po co nam wewnętrzna dokumentacja. Strata czasu. Po co nam BugTracker i zarządzanie zadaniami i czasem – jestem związany ze swoimi wypocinami, wiem co gdzie i kiedy.
I fakt, może to czasem zadziała. Ale z doświadczenia swojego i innych takie kawałki kodu żyją raczej niedługo.
Freelancing
Głównym czynnikiem zmieniającym nasze podejście jest klient. Niemal na pewno założymy miejsce do dzielenia się plikami i założeniami co do systemu. Być może użyjemy BugTrackera. I często na tym się kończy, chociaż teoretycznie powinniśmy także upewnić się, że nasza aplikacja jest bug-free stosując testy jednostkowe, udokumentować kod za pomocą PHPDoc.
Cóż, często szybki zarobek przysłania nam świat, pragniemy oddać kod jak najszybciej i zgarnąć pieniądze. Nie ma w tym nic dziwnego. Myślimy: Klient nie zauważy, czy kod nadaje się do dalszego rozwoju, czy nie
. Byle do przodu! Wiele razy coś takiego się uda i da nam spory zysk. Pomijając sprawy etyczne takie podejście bywa zgubne. Praktycznie zamykamy sobie możliwość dalszego rozwoju tej aplikacji, gdyby nabywca zechciał wrócić i coś rozwinąć. Nie wspominam już nawet o ewentualnych błędach, poprawkach i debuggowaniu ciągnącego się w nieskończoność.
Praca zespołowa/kod dostępny publicznie
Wreszcie! Wreszcie miejsce, gdzie możemy zabłysnąć naszym kunsztem. Chcemy się pokazać przed innymi jako porządni koderzy. Staramy się wdrażać wszelkie dobre porady, które kiedyś tam przeczytaliśmy. A przy okazji… stajemy się totalnie nieefektywni. Nieefektywni, bo nieprzyzwyczajeni.
Jak nasza praca powinna wyglądać?
Po pierwsze przygotowanie się do pracy. Upewnijmy się, że mamy kompletną dokumentację (przypadki użycia, może jakieś makiety), wiemy co chcemy napisać i co jest myślą przewodnią. Zadbajmy także o miejsce na nasze działania – załóżmy repozytorium, BugTracker, zautomatyzujmy testy dzięki Continuous Integration Server (które mam nadzieję wkrótce opiszę).
Gdy już mamy gdzie pracować pomyślmy przez moment jak pracować. Jeżeli nie zamierzamy stosować techniki Test Driven Development (o którym będzie tuż przed omawianiem automatycznych testów), napiszmy chociaż interfejsy.
Wreszcie, podczas kodowania zadbajmy o równoczesne pisanie dokumentacji PHPDoc i testów. Nie, nie wrócisz do tego później. Zapewniam, że nie będzie Ci się chciało. Przecież każda kolejna klasa zbliża Cię do końca projektu, pisanie dokumentacji nie wiadomo komu – nie. Dlatego rób to równolegle do powstających metod i plików. Zapewniam, że bycie porządnym zaowocuje.
I boom! Dla programisty obytego z tymi narzędziami czas pracy wzrasta średnio 2-3 krotnie. Niestety, większość z nas nie ma wyrobionych odpowiednich nawyków i dbanie o te rzeczy jest dla nich męką. A wiadomo, że wtedy pracujemy mniej wydajnie, i czas tworzenia oprogramowania wydłuży się nawet 4-5 razy. Czy warto? TAK!
Dlaczego to takie ważne?
Powyższa lista wygląda jak dużo pracy, huh? Owszem, ale tylko dopóki nie napiszesz dwóch bibliotek z zachowaniem powyższych, dobrych praktyk. Z czasem, gdy wejdzie Ci to w nawyk będziesz wykonywał odpowiednie czynności automatycznie. Albo i napiszesz sobie odpowiednie skrypty, które pomogą utrzymać porządek, przecież jesteśmy programistami. :) Poza tym, nie namawiał bym Cię, gdyby chodziło o zwykłe bycie porządnym.
Myślę, że każdy z nas dąży do rozwoju, pisania rzeczy coraz większych, czy coraz bardziej zmieniających scenę PHP. W pewnym momencie rozwoju dojdziesz do takiego punktu, że nie stosując powyższych narzędzi wcześniej – utkniesz. Na bardzo długo. Albo nawet tak, że łatwiej Ci będzie przepisać kod od nowa. Wiem z doświadczenia. A i pewnie wielu z Was też miało kilka takich wpadek.
Stosowanie się do praktyk polecanych przez tysiące programistów teraz może wydawać się stratą czasu. Co jednak, jeśli w projekcie z dziesiątkami tysięcy linii kodu wedrze się błąd? Zresztą… wedrze się na pewno, najważniejsze to zminimalizować ryzyko. Stosując system kontroli wersji + testy + automatyczne testowanie prawdopodobnie od razu zobaczymy w którym momencie schodzimy na złą ścieżkę. Bez tego moglibyśmy zabrnąć znacznie głębiej i znacznie częściej.
Dokumentacja pomoże nie tylko w wypadku przyjęcia kolejnych osób do zespołu. Także Ty możesz korzystać z jej zalet już teraz. Czy to poprzez wbudowane w IDE opcje podpowiadania kodu zintegrowane z PHPDoc, czy po prostu wracając do swojego dzieła sprzed miesiąca czy więcej.
Także BugTracker Ci się przyda nawet wtedy, gdy pracujesz samodzielnie. Brandon Savage wymienia, dlaczego to takie istotne:
- Bardzo szybko zapomnimy o wielu szczegółach danej usterki/pomysłu. Choćby nie wiem jaka więź łączyła nas z tworzonym kodem – nie będziemy pamiętać wszystkich jego aspektów
- Pomaga w zarządzaniu projektem, „wskoczeniu” w nastrój odpowiedni do pracy. Widząc co mamy przed sobą, ale także co już osiągnęliśmy znacząco motywuje do działania
- Oprócz listy CO mamy do zrobienia mamy także mniejsze lub większe obeznanie z tym, ILE CZASU nam zajmie dany punkt
Jak sobie poradzić, gdy motywacji brak?
Sprawa wbrew pozorom jest bardzo prosta – upublicznić nasz kod. Opisać na blogu, założyć repozytorium na przykład na GitHubie (swoją drogą świetny serwis do pracy zespołowej). Komentarze innych bywają bardzo motywujące. Często także mogą robić za kubeł zimnej wody, gdy robimy coś bez sensu.
Zakończenie
W tym poście wypisałem całkiem sporą listę narzędzi z którymi przyjdzie nam współpracować. Temat jest tak obszerny, że bez problemu można by napisać o tym nie jedną książkę (ech… szkoda, że mój język ojczysty wciąż jest taki… „garbaty”). Tym sposobem chciałbym rozpocząć serię wpisów skupiających się nie tyle na tłumaczeniu dokumentacji każdego z wymienionych dzisiaj punktów, ale przedstawieniu zalet, wpływu na naszą pracę, ciekawych pomysłów wygrzebanych z internetu, opinii i alternatyw.