On 16/04/2011 12:25, Wojciech Jaczewski wrote:
> Andrzej Jarzabek wrote:
>>
>> Z punktu widzenia projektu ważne są różne cele, m.in. takie żeby program
>> można było łatwo i szybko modyfikować, nie wprowadzając przy tym zbyt
>> wielu błędów.
>
> Tylko nie można tłumacząc się wizją ewentualnych późniejszych modyfikacji
> odwlekać powstania programu, który ma zrealizować założenia, które już w
> danym momencie są znane.

Zależy o ile odlekasz. Zwykle warto odwlec o 5 minut jeśli implementacja
będzie trwała więcej niż 20 minut. Jeśli przewidywany czas implemetnacji
wynosi 20 minut lub mniej, to zgodzę się, że podejście
proceduralno-strukturalne może być sensowniejsze.

>> I w sytuacji, kiedy nad kodem pracuje wielu programistów,
>> (i powiedzmy mamy możliwość zatrudnienia programistów znających
>> odpowiednie techniki), to narzucenie użycia technik obiektowych, w
>> języku wspiejającym obiektowość, znacznie skuteczniej osiąga ten cel niż
>> robienie tego proceduralnie/strukturalnie.
>
> To jest zawsze coś za coś. Można znacząco zwiększyć zespół, lub znacząco
> wydłużyć czas powstawania projektu (tym samym znacząco zwiększając jego
> koszt, lub sprawiając że potencjalny zamawiający w ogóle nie będzie
> zainteresowany), trzymać się jakiejś ustalonej formy i mniej martwić
> ewentualnymi zmianami pracowników. Jest to tym łatwiejsze im mniej
> powstanie, dzięki narzuceniu ograniczeń.
> Inna opcja to zaryzykować, zrobić coś szybciej, a w razie czego trochę
> więcej czasu poświęcić na przejmowanie przez jednego pracownika, tego co
> zrobił inny. Trudność jest tu tym większa w porównaniu z bardziej
> sformalizowanym sposobem prowadzenia projektu, że do przejęcia jest dużo
> więcej - bo to więcej w ogóle miało szansę powstać.

A trzecia opcja to przyjąć zestaw dobrych praktyk, np. zawierających
między innymi poprawne i sensowne stosowanie technik obiektowych, wziąć
programistów, którzy będą potrafili posługiwać się odpowiednimi
technikami, i zrobić produkt szybciej i wydajniej niż w dwóch
pierwszych, z mniejszą ilością błędów, i w taki sposób, żeby potem można
go było łatwo modyfikować.

>>> Nie wiem dlaczego miałbym się uczyć, jak osiągnąć ten sam cel przy pomocy
>>> dłuższej, mniej czytelnej, ale za to obiektowej struktury programu.
>>
>> To się zgadza - nie wiesz.
>
> Z takimi wypowiedziami kojarzą mi się trafiające się z rzadka dyskusje o
> metodologii "agile" (co do której mam stosunek obojętny). Ktoś stosował te
> zwyczaje i projekt mu się udał ---> udał się DZIĘKI "agile". Ktoś stosował i
> się nie udał ---> stosował "agile" nieudolnie.

No więc analogicznie do twoich wypowiedzi, z których można wywnioskować,
że nie rozumiesz o co chodzi z programowaniem obiektowym, z powyższej
wypowiedzi też można łatwo wywnioskować, że jeśli ktoś stosował coś
takiego jak "metodologia agile", to albo kompletnie nie rozumie o co
chodzi, albo stosował jakąś swoją własną metodę, w związku z czym trudno
się dziwić, że jeden stosował swoją własną metodę projekt się udał, a
ktoś inny też stosował swoją własną, i projekt się nie udał.

Żeby nie być kryptycznym, szybko wyjaśniam: nie ma czegoś takiego, jak
"metodologia agile". Agile jest co najwyżej właściwością danej
metodologii czy procesu - niektóre metodologie czy procesy są agile,
inne nie są. Jeśli ktoś mówi "metodologia agile", to zasadniczą są dwie
możliwości - albo wie, o czym mówi i używa "agile" jako przymiotnika,
nie wdając się dalej w to, co to była za metodologia, albo - najczęściej
- nie ma większego pojęcia o metodologiach agile, i wydaje mu się, że
jak rezygnuje z "big design up front", to już stosuje "metodologię agile".