On 25/07/2012 07:18, Roman W wrote:
> On Tuesday, July 24, 2012 9:23:42 PM UTC+1, Andrzej Jarzabek wrote:
>>
>> Natomiast czy potrafisz wymienić coś takiego, bez czego nie ma OOP
>
> Chocby enkapsulacja.

To dość niejednoznaczne pojęcie, ale kolesie od Lispa i innego
programowania funkcyjnego powiedzą ci, że robili enkapsulację na długo
przed OO i dalej robią bez żadnego OO.

Z kolei aspekty enkapsulacji, zarówno wiązanie kodu z danymi, jak i
ukrywanie prywatnych danych i prywatnego kodu, było robione w typowo
stukturalno/proceduralnym programowaniu przez użycie modułów.

A taki Python jest uważany za język wspierający OO, a nie pozwala na
information hiding.

>> , albo
>> co powoduje, że jest się OO?
>
> Jezeli masz enkapsulacje, abstrakcyjne interfejsy, kod stowarzyszony z danymi oraz
"stary kod moze wywolywac nowy kod", to IMHO mozesz juz mowic o OOP.

Wydaje mi się, że jeśli weźmiesz ogół rozwiązań (języków, innych
narzędzi) i konkretnych programów, które można określić i są określane
jako OO, to często będzie brakować przynajmniej jednej z tych rzeczy,
albo ich obecność będzie sporna. Każda z tych rzeczy może też występować
w rozwiązaniach zdecydowanie nie będących OO, zapewne mogłyby również
wszystkie na raz.

> OK, moge pewnie powiedziec, ze nie ma Agile bez Scrum albo ze jak mam Scrum to mam
Agile. Tylko ze roznica jest, ze w przypadku OOP te "must have features" to sa
uzyteczne rzeczy same w sobie, natomiast Scrum to rytual. Uzyteczne rzeczy sa
przemycane obok (jak TDD). No to ja sie pytam, czy musze miec rytual zeby robic TDD -
nie musze.

Na pewno nie można powiedzieć, że nie ma agile bez Scrum; są różne
metodologie agile, Scrum jest tylko jedną z nich.

Scrum jako takie jest dość nieźle zdefiniowane, teoretycznie można są
konkretne rzeczy, o których można powiedzieć, że jak je robisz, to
robisz Scrum, a zatem jesteś Agile. Problem jest taki, że Scrum ma
aspekt, nazwijmy to, rytualistyczny, i jego wykonywanie jest
najłatwiejsze do sprawdzenia, ale podstawą są w nim pewne zasady, z
których wynika _po co_ są te wszystkie rytuały, i właśnie w aspekcie
tych zasad i celu robienia tego wszystkiego Scrum jest agile, a nie w
aspekcie konkretnych rytuałów. Tak więc jeśli masz codzienne zebrania,
które nazywasz "scrum", jeśli używasz do estymacji kart ze "story
points", jeśli nazwiesz team leada "scrum master" i jeśli robisz inne
zebrania w dwutygodniowych cyklach, które nazywasz "sprintami", to nie
czyni cię to ani trochę bardziej "agile". Inne kwestie są trochę
trudniejsze do "odhaczenia". Skąd wiesz, że praktykujesz "openness"? W
niektórych firmach robi się tak, że każdy pracownik dostaje list od CEO,
że w naradzie z senior managerami zdecydowali, że ma być openness i od
tej pory wszyscy pracownicy są zachęcani żeby praktykować openness.
Podobnie jest z takimi sprawami jak autonomia zespołu.

Wydaje mi się, że na ogół problemy z adopcją agile polegają na tym, że
czyta się o scrumie, ignoruje się lub wypiera wszystko, czego zrobienie
w danych warunkach byłoby trudne, i wynosi się z tego, że jak się będzie
robić codzienne "scrumy", dwutygodniowe "sprinty", burndown charty i co
tam jeszcze, to będzie lepiej. I potem zdziwienie.