Programista - zawód niewdzięczny...

Bycie programistą nie jest proste, a im lepszym się stajesz, im więcej widzisz i wiesz, tym cięższe staje się Twoje życie. I wcale nie mam na myśli tej ciągłej konieczności bycia "na bieżąco", uczenia się nieustannie nowych języków, paradygmatów, technik, bibliotek i wszystkiego tego, co dobry programista wiedzieć powinien, aby być "wartościowym towarem" na rynku pracy.
Nie, to naprawdę nie jest problematyczne, a im trafniejszy był wybór Twojego zawodu, tym bardziej te wszystkie rzeczy Cię cieszą. Rozwój może być wycięczający i męczący, ale w gruncie rzeczy każdy z nas chce to robić i w dodatku chce to robić bez przerwy, zarówno w pracy jak i po godzinach.

Czasami szkoda czasu na najlepsze rozwiązania

Kilka dni temu rozmawiałem z członkiem mojego zespołu na temat niektórych defectów, które zgłaszamy.
Stwierdził on, że o ile zazwyczaj nie ma się nad czym rozwodzić i kłócić, to zastanawia się, czy w niektórych przypadkach nie jest to zwyczajny przerost formy nad treścią (nie cytuję, więć z góry przepraszam za wszelkie odstępstwa). O co mianowicie chodziło?
Zastanawiał się czy rzeczywiście zawsze warto inwestować czas w poprawianie kawałka kodu tak, aby był jeszcze lepszy, skoro spełnia on swoje założenia i wcale zły nie jest.

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.