On Apr 18, 8:17 am, Michal Kleczek <k...@g...com> wrote:
> Andrzej Jarzabek wrote:
>
> > Mam problem z taką odpowiedzią, że trudno powiedzieć co, poza
> > wymienionymi przykładami, jest lub nie jest "metodyką".
>
> Dobrzy byloby nie wyladowac w niekonczacych sie dyskusjach dot. definicji
> metodyki, czy tez czy konkretne cos podane jako przyklad metodyka jest, czy
> tez nie. Mysle, ze wiadomo, ze chodzi o odpowiedz na pytanie: Jak
> postepowac, zeby stworzyc "dobre" oprogramowanie.

Mam wrażenie, że w większości przypadków na to pytanie odpowiada się
kombinacją istniejącego procesu, praktyk i doświadczenia w zespole.
Konkrety są tak zależne nie tylko od specyfiki zadania, ale też od
kultury instytucji i zestawu umiejętności i doświadczenia
reprezentowanego w danym zespole, że nawet jeśli nazwiesz to
"metodyką", to jest to metodyka, która ma zastosowanie tylko do tego
jednego projektu. W tym sensie istnieje mniej więcej tyle metodyk
wieloparadygmatowych, ile programów wieloparadygmatyowych.

Kolejna rzecz jest taka, że programy wieloparadygmatowe mogą powstawać
nie tylko z projektów z założenia wieloparadygmatowych, tylko (i
ostrożnie bym zgadywał że tak się często dzieje) ewolucyjnie, w miarę
powstania i zauważenia w projekcie sytuacji, gdzie inny paradygmat
sprawdzi się lepiej niż ten, założony jako obowiązujący dla projektu.
W początkowych założeniach może się wtedy najwyżej mieścić mniejsza
lub większa otwartość na daną ewentualność. Można w związku z tym
spytać: czy dopisanie do dowolnej istniejącej "metodyki" punktu:
"jeśli stwierdzisz, że dany kawałek funkcjonalności lepiej
zaimplementowac w innym paradygmacie - zrób to" - czynie z niej
metodykę wieoparadygmatową?

> > Z drugiej strony można powiedzieć, że w świetle tej odpowiedzi brak
> > "metodyk" nie jest takim dużym problemem, bo nawet w bardzo wielu
> > (większości?) projektów gdzie używa się OO, nie używa się niczego
> > podobnego do Booch'a czy RUP, o Shlaer-Mellor nawet nie wspominając.
>
> Sa nawet tacy, ktorzy publicznie w usenecie szczyca sie niestosowaniem
> zadnej metodyki :)

Ja w ogóle się nie wypowiadam, czy to dobrze, czy to źle, tylko że
skoro bardzo wiele projektów, nawet będąc robionymi w OO, nie stosuje
niczego w stylu wyżej wymienionych, to przy decyzji
wieloparadygmatowość yay or nay brak analogicznych metodyk nie jest
wadą.

> Ale _jakas_ metodyke (chocby w szczatkowej postaci) chyba jednak stosuja
> (chociazby XP + katalog refaktoryzacji Fowlera + GoF "design patterns") -
> raczej to jest tak, ze "nie wiedza, ze mowia proza" :)

Z mojego doświadczenia wynika, że to, co opisałeś byłoby już bardzo
sformalizowaną i rozbudowaną metodyką, w stosunku do tego, co się robi
w praktyce. To natomiast, czy stosują jednak _jakąś_ metodykę niestety
rozbija się o definicję metodyki. Stąd moje pytanie wcześniej.

Z drugiej strony samo XP jest "paradigm agnostic". Nie zawiera samo w
sobie receptur "jak kodować", ale te receptury będą przecież właśnie
różne dla różnych paradygmatów i dla każdego z osobna istnieje jakiś
tam zestaw, który można przyjąć.

> A tak zupelnie powaznie to zawsze mnie zastanawia - jak ci, ktorzy nie
> stosuja metodyki odpowiadaja sobie na pytania:
> 1) Jak w ogole zabrac sie do nowego projektu, jak zaplanowac prace, skad
> wlasciwie wiadomo, ze robimy wszystko tak, jak powinnismy?

A z metodyką wiadomo? Dla jakiegoś innego rozumienia "powinniśmy" niż
"tako rzecze Booch"?

> 2) Jak ocenic koszt i oplacalnosc projektu _przed_ jego przeprowadzeniem (w
> kazdym razie jak najwczesniej - zanim wydamy juz duzo pieniedzy)?

No, są różne sposoby, najczęściej oparte na estymatach developerów i
jako takie raczej niezależne paradygmatu programowania. Zwykle
istotnym elementem jest przefiltrowanie tego przez doświadczenie
różnych osób np. kierownika projektu.

> 3) W jaki sposob wyciagac wnioski z przeprowadzonych projektow i zwiekszac
oplacalnosc kolejnych?

Znowu chyba się to głównie opiera na doświadczeniu. Jeśli występują
jakieś problemy, to często analizuje się przyczyny i poprawia proces
tak, żeby zapobiec im w przyszłości.

> > Ja akurat nawet pracowałem kiedyś w firmie, gdzie wprowadzano proces
> > wzorowano w pewnych aspektach na RUP, ale akurat z całej części z
> > diagramem klas i w ogóle UML zrezygnowano.
>
> Ja mialem takie szczescie, ze moja pierwsza praca w przemysle zetknela mnie
> z narzedziem COOL:Gen (teraz "CA Gen", oryginalnie IEF - "Information
> Engineering Facility" - jak jeszcze powstalo to w firmie Texas Instruments)
> - to takie narzedzie typu "MDA", tyle ze wspierajace programowanie
> strukturalne. Z narzedziem zwiazana byla wlasnie metodyka, calkiem dobrze
> opisana w dokumentacji.
> Pozwala mi to teraz - z perspektywy - docenic wartosc stosowania
> metodycznego podejscia.

Ja - znowu - nie mówię, czy to, co opisałem było dobre czy niedobre,
tylko że w praktyce stosuje się różne metody, które określają cykl
życia procesu, różne etapy, deliverables itd., ale nie schodzą na
poziom projektowania kodu, tylko zatrzymują się na tym, że jak jest
komponent, który trzeba stworzyć, jest jakoś tam zadana specyfikacja
funkcjonalna, to od tego programista jest programistą, żeby wiedział
jak zaimplementować tę specyfikację - a jak nie wie, to się radzi
kolegów. W takiej "metodyce" (bo w końcu bez definicji nie wiem, czy
to jest już "jakaś" metodyka czy jeszcze "nie stosowanie metodyki")
ustandardyzowane mogą być projekty do poziomu komponentów (w UML
component, deployment, może package diagrams), natomiast istnienie
dokumentu projektowego na poziomie kodu może być po pierwsze
opcjonalne ("w uzasadnionych przypadkach"), po drugie nawet w tych
przypadkach jego rolą będzie nie tyle stworzenie projektu, który potem
programista będzie realizował, co udokumentowanie projektu stworzonego
ad hoc przez programistę. Ten ogólny schemat można potem dostosowywyać
do konkretnych potrzeb projektu, np. jeśli wiadomo, że wiele
komponentów będzie podobnych, to tworzy się framework do budowania
tego typu komponentów i udokumentowuje się na odpowiednim poziomie.

Z kolei wszystkie znane mi metodologie agile zdają się znakomicie
nadawać do programowania wieloparadygmatowego (choć przyznam, że nie
mam w tej dziedzinie żadnego praktycznego doświadczenia). W XP masz
'Coding Standards', ustalane przez zespół, więc mogą obejmować
wszystkie paradygmaty, które zespół przyjmie, i pair programming,
który rozwiązuje problem kiedy nie wszyscy programiści są obeznani ze
wszystkimi stosowanymi paradygmatami.

Scrum z kolei wręcz wychodzi z założenia, że członkowie zespołu między
sobą posiadają wiedzę jak zrobić oprogramowanie posiadające zadaną
funkcjonalność i postuluje realizowanie tej wiedzy przez
samoorganizację. W takiej sytuacji decyzja o tym, czy programować
wieloparadygmatowo, jakie paradygmaty stosować i w jaki sposób należy
tylko do członków zespołu.