eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programmingCarnegie-Mellon przestaje uczyc programowania obiektowegoRe: Carnegie-Mellon przestaje uczyc programowania obiektowego
  • Path: news-archive.icm.edu.pl!news.gazeta.pl!not-for-mail
    From: Wojciech Jaczewski <w...@o...pl>
    Newsgroups: pl.comp.programming
    Subject: Re: Carnegie-Mellon przestaje uczyc programowania obiektowego
    Followup-To: pl.comp.programming
    Date: Sat, 16 Apr 2011 16:15:08 +0200
    Organization: "Portal Gazeta.pl -> http://www.gazeta.pl"
    Lines: 52
    Message-ID: <ioc89l$g8m$1@inews.gazeta.pl>
    References: <1...@4...com>
    <2...@k...googlegroups.com>
    <f...@b...softax.pl>
    <4...@2...googlegroups.com>
    <m...@b...softax.pl> <innh81$6gk$1@inews.gazeta.pl>
    <inpsjn$nua$1@inews.gazeta.pl> <inqqea$9f4$1@inews.gazeta.pl>
    <int0c8$bkd$1@inews.gazeta.pl> <invfrd$edj$1@inews.gazeta.pl>
    <io0df9$9id$1@inews.gazeta.pl> <io28ga$do6$1@inews.gazeta.pl>
    <io2l6b$nuq$1@inews.gazeta.pl> <io4unk$41$1@inews.gazeta.pl>
    <a...@n...gazeta.pl>
    <io7jbo$dit$1@inews.gazeta.pl> <iobqid$3ct$1@inews.gazeta.pl>
    <iobub4$eoe$1@inews.gazeta.pl> <ioc56d$6kf$1@inews.gazeta.pl>
    NNTP-Posting-Host: 188.33.49.206
    Mime-Version: 1.0
    Content-Type: text/plain; charset="ISO-8859-2"
    Content-Transfer-Encoding: 8Bit
    X-Trace: inews.gazeta.pl 1302963318 16662 188.33.49.206 (16 Apr 2011 14:15:18 GMT)
    X-Complaints-To: u...@a...pl
    NNTP-Posting-Date: Sat, 16 Apr 2011 14:15:18 +0000 (UTC)
    X-User: wjaczewski1
    User-Agent: KNode/4.4.5
    Xref: news-archive.icm.edu.pl pl.comp.programming:189924
    [ ukryj nagłówki ]

    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.

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: