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.