On Sun, 17 Apr 2011 16:22:47 -0500, A.L. <l...@a...com> wrote:
> Panowie, czy mozna wiedziec jakie jest Panow doswiadczenie
> PRZEMYSLOWE?... Bo poki co, wyglada mi ze wypowiadacie
> sie Panowie moca teoretycznej wszechwiedzy. Podpierajac sie
> dosyc kiepska teoria

A można konkretniej? Bo nie zamierzam przypisywać tutaj swojego CV.
Powiem tyle, że pracuję ponad 10 lat w software houses różnej
wielkości, poczynając od względnie niedużej, zatrudniającej
kilkudziesięciu pracowników, a kończąc na korporacjach na indeksie
FTSE 100 i z listy Fortune 500.

do góry

Andrzej Jarzabek wrote:

> On 15/04/2011 16:44, Michal Kleczek wrote:
>> Andrzej Jarzabek wrote:
>>
>>>> Jak pisalem w innym poscie - brak "wieloparadygmatowych metodyk" jest
>>>> dzis sporym problemem.
>>>
>>> Jak rozumiesz tutaj "metodykę"?
>>
>> Na przyklad dla OO:
>> http://en.wikipedia.org/wiki/Shlaer%E2%80%93Mellor_m
ethod
>> http://en.wikipedia.org/wiki/Booch_method
>> http://en.wikipedia.org/wiki/Object-oriented_softwar
e_engineering
> [...]
>
> 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.

Moze podaj "wieloparadygmatowe" przyklady jakie ci przychodza do glowy.

> 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 :)

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" :)

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?
2) Jak ocenic koszt i oplacalnosc projektu _przed_ jego przeprowadzeniem (w
kazdym razie jak najwczesniej - zanim wydamy juz duzo pieniedzy)?
3) W jaki sposob wyciagac wnioski z przeprowadzonych projektow i zwiekszac
oplacalnosc kolejnych?
...
n) i tak dalej :)

> 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.

--
Michal

do góry

Andrzej Jarzabek <a...@g...com> napisał(a):

> On Sat, 16 Apr 2011 19:45:42 +0000 (UTC), " "
> <k...@g...SKASUJ-TO.pl> wrote:
> > pisanie wszystkiego w szablonach (templates), nawet jesli
> > nie daje to zadnego zysku nad zwyczajnym polimorfizmem
> > przez dziedziczenie i funkcje wirtualne (a koszt jest: czas
> > budowania kodu, slimaczenie sie debuggera na fafnastu klasach
>
> Jaki debugger ci się ślimaczył? Ja nigdy nie zauważyłem, żeby na
> szablonach jakiś działał wolniej, niż na normalnym kodzie.

MS Visual Studio 2008 z SP1 (wersja pro).

>
> Ja sam głównie zauważyłem takie problemy, że czas kompilacji potrafi
> się wydłużyć, i że komunikaty o błędach bywają mało zrozumiałe.

"Link-time code generation", to dopiero wydluza.

>
> Z drugiej strony jednak szablony, jeśli się da je zastosować, oferują
> jednak często różne korzyści ponad to, co daje OO z funkcjami
> wirtualnymi. Performance, to jedna sprawa, ale to nie zawsze jest
> istotne. Często natomiast ważna jest możliwość kontroli pewnych
> rzeczy na etapie kompilacji, gdzie polimorfizm w stylu OO pozwalałby
> sprawdzać je dopiero w runtime.

Tak, wiem. Ale IMHO ludzie maja tendencje do naduzywania szablonow.

KK


--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

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.

do góry

On Apr 18, 8:32 am, " " <k...@g...SKASUJ-TO.pl> wrote:
> Andrzej Jarzabek <a...@g...com> napisa (a):
>
> > On Sat, 16 Apr 2011 19:45:42 +0000 (UTC), " "
> > <k...@g...SKASUJ-TO.pl> wrote:
> > > pisanie wszystkiego w szablonach (templates), nawet jesli
> > > nie daje to zadnego zysku nad zwyczajnym polimorfizmem
> > > przez dziedziczenie i funkcje wirtualne (a koszt jest: czas
> > > budowania kodu, slimaczenie sie debuggera na fafnastu klasach
>
> > Jaki debugger ci się ślimaczył? Ja nigdy nie zauważyłem, żeby na
> > szablonach jakiś działał wolniej, niż na normalnym kodzie.
>
> MS Visual Studio 2008 z SP1 (wersja pro).

Hm, może faktycznie to prawda, że późniejsze wersje mają problemy, bo
ja debugowałem ostatnio pod VS2005 całkiem mocno szablonowy i "meta-
programowy" kod (no dobra, nic klasy boost::lambda czy boost::spirit,
ale jednak wychodzące nieco ponad pojedynczą funkcję czy klasę
szablonową) i nie zauważyłem żadnego spowolnienia...

> > Ja sam głównie zauważyłem takie problemy, że czas kompilacji potrafi
> > się wydłużyć, i że komunikaty o błędach bywają mało zrozumiałe.
>
> "Link-time code generation", to dopiero wydluza.

A to jest przecież dopiero coś, czego sensowność w bardzo wielu
wypadkach można kwestionować.

do góry