On 19/02/2012 20:11, bartekltg wrote:
>
> Ale to ma się nijak do histroi o wspolnym podnoszeniu
> mebla. To wszystko 'pokazywanie że się ominęło śmiecia'.
> Tego nie kwestionuję. Chciałem tylko zobaczyć przykład
> z programowania odpowiadający historii o wspolnym
> podnoszeniu mebla.
>
> Masz taki, czy jednak analogia była nietrafiona?

Ja mam taki przykład. Przepraszam, że bez szczegółów, ale ogólnie
sytuacja wyglądała tak, że program się zachowywał w sposób, który nie
powinien być możliwy. Byłem w stanie prześledzić do konkretnego momentu
i po prostu wylgądało jakby zachowanie programu było sprzeczne z kodem,
tudzież zmieniało się wraz ze zmianą okoliczności, które na to
zachowanie nie powinny mieć wpływu. Straciłem dwa dni na debugowaniu wtę
i wewtę, logowaniu różnych rzeczy, podstawianiu danych itd. i nic - po
prostu paradoks. Pokazałem koledze i w 10 minut zorientowaliśmy się,
gdzie popełniłem błędne założenie.

Oczywiście możesz powiedzieć, że założenie błędne, bo gdybym nie
poprosił kolegi o pomoc, to pewnie sam bym w końcu wpadł na właściwe
rozwiązanie, nawet gdyby to miało zająć kolejne 3 dni, ale tak to już
bywa z analogiami - nie zawsze są w 100% dokładne.

Inną, być może lepszą, ale też trudniejszą do wykazania na konkretnym
przykładzie analogią jest jakość kodu wytwarzanego przez programistów i
jego konsekwencje. Najbardziej oczywistą sprawą jest ilość defektów:
nawet mając dział QA, który wykrywa powiedzmy większość defektów, ilość
tychże w kodzie programisty ma kolosalne znaczenie: zawsze ilość
defektów pozostanie niewykrytych, co może narazić klientów na straty i
spowoduje utratę reputacji firmy i zespołu, natomiast nawet te, które
zostaną wykryte, będą opóźniać release lub powodować redukcję ficzerów w
danej wersji. I teraz możesz założyć, że dany programista będzie
popełniał ileś tam błędów w danym kawałku kodu - będzie to zależało od
różnych czynników, jak język, narzędzia, metodologia itd., ale zawsze
jakiś tam poziom błędów będzie. I w zasadzie niewiele może sam z siebie
zrobić, żeby ten poziom błędów zmniejszyć - gdyby potrafił pisać lepiej,
to by już tak pisał. Ta ilośc błędów to waga szafki, którą może
udźwignąć. Pracując z drugim programistą razem stworzą kod, który ma
mniejszą ilość defektów, niż którykolwiek z nich mógłby osiągnąć z
osobna. Czyli dźwigają cięższą szafkę, niż każdy z nich z osobna mógłby
udźwignąć.

Taką samą analogię można zbudować dla innych parametrów jak performance,
maintainablility, jakość projektu rozmaitych interfejsów itd.