eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programmingCarnegie-Mellon przestaje uczyc programowania obiektowegoRe: Carnegie-Mellon przestaje uczyc programowania obiektowego
  • Data: 2011-04-18 10:47:55
    Temat: Re: Carnegie-Mellon przestaje uczyc programowania obiektowego
    Od: Andrzej Jarzabek <a...@g...com> szukaj wiadomości tego autora
    [ pokaż wszystkie nagłówki ]

    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.

Podziel się

Poleć ten post znajomemu poleć

Wydrukuj ten post drukuj


Następne wpisy z tego wątku

Najnowsze wątki z tej grupy


Najnowsze wątki

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: