Whatever

świętymi bądźmy... ale trzeba znać umiar

Ostatnimi czasy zdarzało mi się trafiać w review kodu na zażarte dyskusje na temat pewnego jego fragmentu. Czasami rozmowy tam prowadzone zmieniały się w dialogi nie za pośrednictwem komentarzy i klawiatur, a werbalne.
Gdy się wsłuchiwałem (bądź wczytywałem) w nie, ciężko było trzymać stronę któregokolwiek z dyskutantów, a to dlatego, że moim zdaniem każdy z nich miał rację, a rozmowa sprowadzała się do kwestii estetycznych i osobistych preferencji aniżeli do "obrony jakości kodu" przed "nieodpowiednimi" linijkami.

No i tak sobie te dyskusje trwały do momentu, gdy w końcu obaj rozmówcy decydowali się na skorzystanie z "telefonu do przyjaciela", co sprowadzało się do skierowania spojrzeń w kierunku najbliższego programisty i zadania mu jakże istotnego pytania - "A Ty co o tym sądzisz?".

Zdarzało się tak, że owym programistą byłem ja. I cóż mogłem odpowiedzieć?

O tworzeniu obiektów w JavaScriptcie słów kilka...

Ciekawa prezentacja zrobiona przez moich kolegów z zespołu (Piotrka Repetowskiego i Mirka Filipa) dotycząca tworzenia obiektów w JavaScripcie i problemów, które można po drodze napotkać.

Cóż mogę napisać? Polecam i czekam na więcej (a wiem z dobrych źródeł, że owo "więcej" jest jedynie kwestią czasu:).
Co prawda jest ona w języku angielskim, ale z dużą ilością kodu, więc każdy, kto zna JS'a powinien wszystko bez większych problemów zrozumieć:)

Prezentacje znajdziecie pod tym linkiem.

Jeżeli coś jest niejasne to piszcie w komentarzach, a ja postaram się ich namówić na udzielenie odpowiedzi :)

Enumy w PHPie? Oczywiście, że się da!

Ostatnio, przeglądając jedno z reviewew mój kolega z zespołu rozpoczął rozmowę na temat naszych pseudo-enumów w aplikacji.
Nie odkryliśmy tutaj koła na nowo i nasze "klasy enumeracyjne" wyglądały tak, jak w większości frameworków, bibliotek i aplikacji, które widziałem, a które zostały napisane w PHP:

interface PseudoEnum
{

    const SUCCESS = 1;
    const FAILURE = 2;
}

Dobre rozwiązanie? No cóż, osobiście od dawna bolałem nad tym, że takie konstrukcje nie pozwalają nam na jedną z jakże istotnych funkcjonalności, które w przypadku zwykłych obiektów PHP posiada, a które są bezproblemowe w językach, gdzie coś takiego jak enum istnieje. O czym mowa? Chodzi o typowanie.

Pomimo cudownych i deskryptywnych nazw, te stałe, jakby na to nie patrzyć, w gruncie rzeczy są int'ami i w chwili, gdy któraś metoda mogła przyjąć wartość tylko i wyłącznie taką, jaka została zadeklarowana wcześniej w naszym pseudo-enumie, to musieliśmy tworzyć do tego celu specjalne metody sprawdzające.
Nie mogę powiedzieć, że było to zadowalające rozwiązanie, ale jakoś z tym żyliśmy.

... a test, żeby testował jedną rzecz...

to zależy

Ostatnio mieliśmy w pracy prezentacją dotyczącą test double (swoją drogą polecam zainteresować się tematem i zacząć stosować wszelkiego rodzaju mocki itp., programista nawet nie zdaje sobie sprawy, jak wpływają one na jakość tworzonego kodu i czytelność testów).
Ale ja nie o tym (przynajmniej nie dzisiaj :).
Po prezentacji (i w jej trakcie) poruszyliśmy kilka tematów dotyczących testowania w ogóle i jednym z owych tematów było pytanie: czy jeden test powinien składać się z jedej asercji?
Jak to zazwyczaj bywa z takimi ideologicznymi pytaniami ludzie się podzielili na dwie grupy i zaczęliśmy dyskutować i wymieniać się poglądami. Nie muszę dodawać, że konkluzją było stwierdzenie "to zależy" :)

Tylko czy rzeczywiście "zależy"? A jeżeli tak, to od czego?

Ten kod mi się nie podoba...

somehow I don't like it

Rok, może dwa lata temu mieliśmy w firmie dyskusję na temat tego, co można zakwalifikować jako defect, a co nie powinno za takowy zostać uznane.
Nie mieliśmy na celu twardej definicji, ponieważ każdy z nas zdawał sobie sprawę, że granica jest dość cienka i subiektywna i najlepiej większą część "klarowania definicji" przerzucić na powolny proces jej naturalnego stabilizowania się w obrębie konkretnego zespołu.

Skupiliśmy się przede wszystkim na tym, co nie powinno zostać nazwane błędem. Pomysł na zrobienie takiego spotkania był wynikiem wielokrotnego pojawiania się "defectów", które nie informowały o niczym, nie dawały żadnych wskazówek i niekiedy nawet, po ich przeczytaniu nie było wiadomo co należy poprawić i co tak bardzo zirytowało osobę przeglądającą kod, że zdecydowała się na ten drastyczny krok.

Więcej nie znaczy wolniej

to już jest koniec

I dotarłem (i Wy również:) do końca tej serii wpisów.

Wielokrotnie, gdy czytałem któryś z nich, zaraz przed jego publikacją, dochodziłem do wniosku, że jeszcze przecież tyle rzeczy wypadałoby napisać, dodać i już prawie miałem to zrobić, ale... patrzyłem na jego długość i stwierdzałem, że jednak byłaby to przesada. Poza tym, nie gruntowne omówienie zagadnienia było moim zamierzeniem, a uzmysłowienie, w jak najbardziej skompresowanej formie, zalet opisywanych aktywności/procesów/technik oraz tego, że we wszystkim trzeba znać umiar. Czy mi się to udało? To pozostawiam już do Waszej oceny.

Zdaję sobie sprawę, że na każdy z poruszonych przeze mnie tematów możnaby (i już nieraz to robiono) napisać obszerne tomy i wiem również, że wiele rzeczy pozostało jeszcze do omówienia, więc jeżeli macie jakieś pytania albo chcielibyście więcej, to czekam na komentarze lub wiadomości na fan page'ach (na Google+ lub Facebooku).

Jeżeli chcecie niektóre (wszystkie?) z opisanych procesów zaimplementować u siebie w projekcie/pracy, ale nadal macie wątpliwości lub problemy z rozpoczęciem, to również czekam na Wasze pytania, może wspólnie uda nam się rozwiązać problem :)

Więcej nie znaczy wolniej cz. 8 - dokumentacja

Na wstępie cytat o tym, że dokumentacja jest jak seks

dokumentacja jest jak...

Dzisiaj zacznijmy od cytatu:

Documentation is like sex: when it is good, it is very, very good; and when it is bad, it is better than nothing. - Dick Brandon

Osobiście uważam, że nic tak nie oddaje istoty tego, czym właściwie jest dokumentacja.

Więcej nie znaczy wolniej cz.7 - refaktoryzacja

ach refaktoryzacjo, a na cóż Ty mi?

Dzisiaj przyszła pora na jedną z przyjemniejszych aktywności opisywanych w ramach tej serii. Żeby jednak jakiś temat poruszyć, trzeba najpierw wiedzieć o czym będzie mowa, tak więc zacznijmy od początku, a na początku był kod (i jeszcze kilka innych produktów było wcześniej, ale na dzisiaj możemy założyć, że od kodu zaczynamy :).

Każdy z nas ma pewnie w sobie coś takiego, że chciałby aby jego kod był doskonały, pewnie większość z Was zaliczyła jakiś własny projekt, w którym setki razy dopieszczaliście isniejącą funkcjonalność, bo mimochodem wpadliście na pomysł, co tu zrobić, żeby działa/wyglądała lepiej, była czytelniejsza bądź przyjemniejsza dla oka. I tak w nieskończoność, aż pewnego dnia dochodzimy do wniosku, że już szkoda naszego czasu na pracę nad nim i trafia on gdzieś na dno szafy.

Pewnie równie wielu z Was zdaje sobie sprawę, że w projektach, które muszą ujrzeć światło dzienne i wyjść do użytkowników, takie zabiegi nie są możliwe i w pewnym momencie (zazwyczaj dość szybko) musimy powiedzieć stop i iść dalej.
Jednym zdaniem - projekty dzielimy na te idealne i te zrealizowane (niestety nie pamiętam autora cytatu) i osobiście zgadzam się z nim w zupełności i pomimo mojej lubości dobrych praktych, czytelnego kodu, itp., itd., kiedyś trzeba powiedzieć stop i ruszyć do przodu.

Więcej nie znaczy wolniej cz.6 - code review

Ech... i jeszcze to review kodu

Pora na kolejną "problematyczną" praktykę, a mianowicie na code review. Sama idea jest prosta do zrozumienia i polega ona na tym, że kod (jego forma, wygląd i sposób rozwiązania problemu) musi zostać zaakceptowany przez kogoś poza jego twórcą.
Tak naprawdę nie jest istotne czy używasz do tego celu specjalnie dedykowanych narzędzi, czy rozsyłacie patche ze zmianami, czy stosujesz do tego celu jeszcze inną technikę, ważne jest, aby na każdą linijkę, która chce "dostać się" na produkcję, popatrzył ktoś poza jej autorem. Dzięki temu nieustannie dbamy i poprawiamy jakość kodu, eliminujemy bugi implementacyjne, dodajemy, nie wzięte pod uwagę przez autora, test case'y itp.

Dobra, to skoro podstawowe informacje mamy za sobą, to pora przejść do jakichś konkretów :)

YAGNI + Test First

czy warto pisać testy przed implementacją?

Testowanie samo w sobie przynosi korzyści, zazwyczaj w dłuższej (oby:) perspektywie czasu, ale prędzej czy później jesteśmy w stanie dostrzec ich wartość i nieraz oddychamy z ulgą, gdy widzimy, że ludzie pracujący nad kodem przed nami, poświęcili trochę czasu na napisanie solidnych zestawów. Lecz o zaletach posiadania testów już pisałem ostatnio (tutaj i ciąg dalszy :).

I o ile z tym, że posiadanie testów przynosi korzyści i jest to jedna z tych rzeczy, którą wielu programistów chce praktykować nie kłóci się nikt, o tyle nie wszyscy widzą jakikolwiek sens w pisaniu testów przed implementacją. Że niby sprawia, że kod jest lepszy, że jeszcze raz myślimy o problemie, że patrzymy na niego od innej strony, itp., itd.
Problem z tymi wszystkimi stwierdzeniami jest taki, że to są jedynie oklepane zwroty, którymi karmią nas bardziej doświadczeni, mądrzejsi znawcy tematu, którzy powołują się na własne doświadczenie i którym powinniśmy zaufać. I ja wcale nie twierdzę, że nie mają racji, czy też nie neguję ich kompetencji, ale człowiek (a programista też człowiek :) woli uczyć się na własnych błędach. Przynajmniej do momentu, gdy nie zobaczy konkretnego przykładu, który pokazuje mu, że jednak jest tak, jak podpowiada starszy kolega.