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

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.

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.

do góry

W dniu 2011-04-16 09:15, Maciej Sobczak pisze:
> On Apr 15, 5:57 pm, Jędrzej Dudkiewicz<jedrzej.dudkiew...@nospam-
> gmail.com> wrote:
>
>> Raczej nie o to chodzi. Ja rozumiem to tak, że masz klasę K, w niej
>> metodę M, implementacja metody nie jest pure, czyli np. loguje coś klasą
>> L. L używa do synchronizacji S itd, itp. Jeżeli projekt taki jest, to
>> faktycznie musisz targać za sobą pół dżungli.
[...]
>> Swoją drogą pytanie, jak to rozwiązać, jest dość ciekawe
>
> Ciekawszym pytaniem jest czy w ogóle trzeba to rozwiązywać. Widziałem
> przypadki, gdy adaptery i inne takie rozdmuchiwały projekt i same w
> sobie wnosiły nowe zależności (np. konieczność ładowania dodatkowych
> bibliotek) a nigdy nie było okazji skorzystać z potencjalnych zalet
> ich wprowadzenia. Wtedy jest koszt a nie ma zwrotu z inwestycji.
> Pytanie jak to przewidzieć.

To chyba z definicji nieprzewidywalne. Natomiast przy pierwszym
przypadku (kiedy widać zysk z "wyrywania dżungli z korzeniami")
postarać się delegować:
- nie "całą dżunglę" tylko poszczególne kawałki
- "opcjonalnie", czyli dając od ręki null-object lub trywialną
implementację/adapter do konkretnego środowiska

W końcu tworzymy projekty w jakimś celu, zazwyczaj za czyjeś pieniądze.

--
Paweł Kierski
n...@p...net

do góry

W dniu 2011-04-14 22:34, Wojciech Jaczewski pisze:
> Mariusz Marszałkowski wrote:
>
>> Jaki masz wspolczynnik trafnych przwidywan do nietrawnych, co do tego,
>> czy modul albo program sie rozrosnie i dobre praktyki (przerost formy
>> nad
>> tresica) przyspiesza jego realizacje, czy może skończy się na X<=500
>> linii kodu? Ja ostatnio mam... bliski zerowego :)
>
> Nie staram się przewidywać, czy się rozrośnie czy nie. Bez obiektowego
> przerostu formy nad treścią nie muszę się tym aż tak martwić, bo nie
> ograniczam się już na samym początku sztywną strukturą. I podchodzę to
> projektu przyjmując założenie, że ma robić tylko to, co jest w wymaganiach w
> tej chwili. Wiem, że prawie zawsze w jakimś tam stopniu się rozrośnie po
> pierwszych doświadczeniach serwisowych, ale zazwyczaj nie potrafię
> przewidzieć w którą stronę się to rozwinie.

Sztywność struktury nie jest własnością OO, choć bywa własnością
programów pisanych przez ludzi, którzy nie do końca wiedzą, jak
efektywnie w OO projektować. Wtedy faktycznie jest szansa na przerost
formy nad treścią i "sztywny" projekt. Odpowiednikiem tego
w strukturalnym paradygmacie jest np. nieprzewidzenie wielu instancji
(dane static), słabe parametryzowanie funkcji (ukryte, niepotrzebne
zależności).

--
Paweł Kierski
n...@p...net

do góry

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

do góry

Andrzej Jarzabek wrote:

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

Przy czym techniki, które były poprawne przy projekcie X - które zostały
spisane podczas jego tworzenia, mają dużą szansę być błędne przy projekcie
Y.
Gdyby drugi/trzeci/czwarty raz robić od nowa ten sam projekt, to pewnie
dałoby się spisać, które praktyki są dobre a które złe. Tyle że kolejny raz
ten sam projekt robi się tylko w niektórych dziedzinach, jak np.
kompilatory, gdzie od lat rozwija się na ich temat zarówno teoria jak i
praktyka.
W bardziej - że tak to określę - zwyczajnych projektach, przed ich
rozpoczęciem nie ma się tak dużej wiedzy, co się tam sprawdzi a co nie.

> 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",

Nie pamiętam, czy tak to określali, czy inaczej. Natomiast ogólny sens był
taki: udało się ---> zastosowali, nie udało się ---> zastosowali
nieprawidłowo.

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

Przecież praktycznie każda metoda tworzenia oprogramowania jest dość ogólna.
Gdyby była w 100% precyzyjna, program mógłby być tworzony przez generator,
zamiast człowieka.

do góry

Andrzej Jarzabek wrote:

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

Z tego co kojarzę, częściej stosuje się spisane zasady w firmach dużych, niż
w firmach małych. I jakoś tak zwykle się dzieje, że firma gdy już stanie się
dużą, traci umiejętność samodzielnego tworzenia dobrych produktów. Myślisz,
że to przypadek? Bo ja uważam, że jest to WYNIK zbyt szczegółowego
regulowania zasad w firmie - w tym zasad tworzenia oprogramowania.
Patrząc np. na liczbę zatrudnionych w wielkich korporacjach tworzących
oprogramowanie, wydawać by się mogło że powinni tworzyć na prawdę mnóstwo
świetnych produktów. Tymczasem dobre produkty pozyskują zwykle poprzez
wykupienie małej firmy, a nie samodzielne zrobienie.

do góry

On 16/04/2011 15:40, Wojciech Jaczewski wrote:
>
> Z tego co kojarzę, częściej stosuje się spisane zasady w firmach dużych, niż
> w firmach małych.

A skąd niby to kojarzysz? Robiłeś jakieś badania? Masz doświadczenie z
setek małych i dużych firm? Czytałeś jakieś artykuły na ten temat?

Poza tym ja nic nie mówiłem o tym, czy te zasady mają być _spisane_ czy
nie. Być może tak jest, że przy pięciu programistach potrzeba spisywania
zasad jest mniejsza.

> I jakoś tak zwykle się dzieje, że firma gdy już stanie się
> dużą, traci umiejętność samodzielnego tworzenia dobrych produktów. Myślisz,
> że to przypadek?

Myślę, że to nieprawda. Skąd masz takie informacje?

> Bo ja uważam, że jest to WYNIK zbyt szczegółowego
> regulowania zasad w firmie - w tym zasad tworzenia oprogramowania.
> Patrząc np. na liczbę zatrudnionych w wielkich korporacjach tworzących
> oprogramowanie, wydawać by się mogło że powinni tworzyć na prawdę mnóstwo
> świetnych produktów. Tymczasem dobre produkty pozyskują zwykle poprzez
> wykupienie małej firmy, a nie samodzielne zrobienie.

Tu jest kilka spraw. Po pierwsze jak najbardziej duże firmy potrafią
tworzyć dobre oprogramowanie. Osobna sprawa, że są to najczęściej
kolejne wersje wydawanych wcześniej produktów, ale to się wiąże z
kalkulacją ryzyka: robienie nowego produktu od zera jest ryzykowne, nie
wiadomo, czy uda się go skończyć, czy trafi się w rynek, czy znajdzie
się klientów. Z drugiej strony takie firmy mają i tak permanentny brak
mocy przerobowych do rozwijania produktów, które już sprzedają. Co
oczywiście nie znaczy, że to się nie zdarza, choćby Google jest przecież
taką firmą, która regularnie wypuszcza nowe produkty generalnie niezłej
jakości.

Z drugiej strony z małymi firmami jest tak, że bardzo wiele nigdy nie
dochodzi do etapu, gdzie mają "shippable" produkt, a w wielu przypadkach
te ich produkty, które zostają wydane lub oddane klientowi są niskiej
jakości. Tylko że w większości o nich nie słyszysz, bo takie firmy nie
stają się duże, a raczej bankrutują. Te, które zostają wykupione przez
duże firmy to 0.01% ogółu, który zostają wybrane dlatego, że pozostałe
99.99% to krap.

do góry

On Sat, 16 Apr 2011 16:40:50 +0200, Wojciech Jaczewski
<w...@o...pl> wrote:

>Andrzej Jarzabek wrote:
>
>> 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ć.
>
>Z tego co kojarzę, częściej stosuje się spisane zasady w firmach dużych, niż
>w firmach małych. I jakoś tak zwykle się dzieje, że firma gdy już stanie się
>dużą, traci umiejętność samodzielnego tworzenia dobrych produktów. Myślisz,
>że to przypadek? Bo ja uważam, że jest to WYNIK zbyt szczegółowego
>regulowania zasad w firmie - w tym zasad tworzenia oprogramowania.
>Patrząc np. na liczbę zatrudnionych w wielkich korporacjach tworzących
>oprogramowanie, wydawać by się mogło że powinni tworzyć na prawdę mnóstwo
>świetnych produktów. Tymczasem dobre produkty pozyskują zwykle poprzez
>wykupienie małej firmy, a nie samodzielne zrobienie.

Z czalym szacunkiem, bzdura. Gdy zaczynalem pracowac w firmia, miala
ona 20 osob, a "flagship product" mial pol miliona linii kodu. Kazdy
programowal jak chcial.

Dzisiaj firma ma 2000 osob a kod cos kolo 50 milionow linii. Gdyby te
50 milionow linii bylo napisane jak kto chce, bylby totalny burdel.
Zasada jest taka ze kod ma byc napisany tak, aby w przypadku
znikniecia autora, kazdy inny programista mogl przejac prace "z
marszu". Z reguly tez, inne osoby sa zaangazowane w utrzymanie kodu
(maintenace) niz te osoby ktore ow kod napisaly.

Swego czasu firma IBM stosowala nastepujaca zasade przy zatrudnianiu
programistow: a) kandydart dostawal do napisania program, b) pracownik
IBN dostawal ten program z prozba o odcyfrowanie co ten program robi.
O ile sie nei dawalo odcyfrowac, kandydat odpadal.

Zasady dzialania w firmie MUSZA byc regulowane. Jezeli nie sa, to
firma wystawia sie na "odstrzal"

Natomiast duza firma wykupuje mala firme tylko z jednego powodu: aby
pozyslac liste klientow.

A.L.

do góry

On 16/04/2011 15:15, Wojciech Jaczewski wrote:
> Andrzej Jarzabek wrote:
>
>> A trzecia opcja to przyjąć zestaw dobrych praktyk, np. zawierających
>> między innymi poprawne i sensowne stosowanie technik obiektowych,
>
> Przy czym techniki, które były poprawne przy projekcie X - które zostały
> spisane podczas jego tworzenia, mają dużą szansę być błędne przy projekcie
> Y.

No więc właśnie po to istnieje dyscyplina inżynierii oprogramowania,
żeby ludzie znający się na tym mogli z dużym prawdopodobieństwem
określić, co sprawdzi się w projekcie Y a co nie.

Z drugiej strony dlatego też firmy często się jakoś tam specjalizują, a
nie zabierają się za robienie kompletnego spektrum oprogramowania,
poczyjnając od gier na telefon a kończąc na oprogramowaniu do sterowania
elektrownią atomową.

Natomiast bardzo wiele dobrych praktyk sprawdza się zadziwiająco często,
w nawet pozornie niepodobnych do siebie projektach. W rzeczywsistości te
same praktyki będą dobre dla prawie wszystkich przypadkach, wyjątki są
bardzo rzadkie.

> W bardziej - że tak to określę - zwyczajnych projektach, przed ich
> rozpoczęciem nie ma się tak dużej wiedzy, co się tam sprawdzi a co nie.

Jak się na tym zna, to się ma. Dlatego m. in. tak często stosuje się OO.

>> 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",
>
> Nie pamiętam, czy tak to określali, czy inaczej. Natomiast ogólny sens był
> taki: udało się ---> zastosowali, nie udało się ---> zastosowali
> nieprawidłowo.

No ale chyba nie uważasz, że istnieją jakiekolwiek techniki czy metody,
które dają dobre rezultaty nawet wtedy, kiedy stosuje się je nieprawidłowo?

>> 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ł.
>
> Przecież praktycznie każda metoda tworzenia oprogramowania jest dość ogólna.
> Gdyby była w 100% precyzyjna, program mógłby być tworzony przez generator,
> zamiast człowieka.

To tak jak z budową mostów. Co nie znaczy, że nie istnieje dziedzina
wiedzy o tym, jak robić mosty i że człowiek może stosować tę wiedzę
prawidłowo lub błędnie.

do góry

Paweł Kierski <n...@p...net> napisał(a):

> W C++ - tworzeniem i rozbudowywaniem "The Class", co dawało taki sam
> efekt.
>
> Mój wniosek - zabagnienie w C jest nieco łatwiej rozwikłać niż w C++.
> Za to łatwiej unikać zabagnienia w C++ niż w C, bo C++ (szczególnie
> jeśli na początku dobrze użyte) narzuca pewne ograniczenia. W końcu
> trzeba jakoś wytłumaczyć, czemu "friend" i "public".

Z moich obserwacji wynika, ze teraz typowym zabagnieniem w projektach C++ jest
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
ktore sa de fakto ta sama klasa). Slyszalem o tym od innych ludzi i widze to w
duzym kodzie nad ktorym pracuje od niedawna.

KK

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

do góry