eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programmingprocedura tworzenia programów
Ilość wypowiedzi w tym wątku: 130

  • 71. Data: 2012-02-19 21:21:39
    Temat: Re: procedura tworzenia programów
    Od: " M.M." <m...@g...pl>

    bartekltg <b...@g...com> napisał(a):

    > W dniu 2012-02-19 20:48, M.M. pisze:
    > > bartekltg<b...@g...com> napisał(a):
    > >
    > >> ale za Chiny Ludowe nie widzę przypadku,
    > >> który odpowiadałby histroi o podnoszeniu szafki.
    > >
    > > Nie rozumiem czego nie rozumiesz.
    > >
    > > Nie zdarzylo Ci sie nigdy siedziec z kolega nad
    > > wspolnym problemem?
    > >
    > > Czy moze zawsze w tym samym czasie znajdowales rozwiazanie
    > > co kolega?
    > >
    > > A moze zawsze znales pierwszy rozwiazanie niz kolega?
    > >
    > > A moze zawsze gdy sie Ty myliles to kolega sie z Toba zgadzal
    > > ze masz racje i nic nie pomagal?
    >
    > Ale to ma się nijak do histroi o wspolnym podnoszeniu
    > mebla. To wszystko 'pokazywanie że się ominęło śmiecia'.
    > Tego nie kwestionuję. Chciałem tylko zobaczyć przykład
    > z programowania odpowiadający historii o wspolnym
    > podnoszeniu mebla.
    >
    > Masz taki, czy jednak analogia była nietrafiona?
    Jak nietrafiona, przeciez mowie o zwyklej rzeczy.

    Podciaga sie pod to kazda sytuacja gdy trzeba szybko
    cos zrobic. Jesli robia to dwie osoby, to jedna poda
    szybciej rozwiazanie niz druga, a druga ma szanse
    szybciej zweryfikowac slusznosc rozwiazania.

    Nigdy Ci sie nie zdarzylo ze kazde 15 minut zwloki powodowalo
    jakies ryzyko? Mnie sie zdarzylo ze przedwczesnie zainstalowany
    system uniemozliwil normalny powrot do domu 300 ludziom (i
    nie tylko). Poziom wkurwienia klienta rosl wykladniczo, klient
    znal 30 innych klientow i mogl smrodu narobic. Kazde 15 minut
    przy usuwaniu usterki bylo na wage zlota. Jestes pewny ze jeden
    programista tak samo podola jak para przy takim stresie?

    Pozdrawiam


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


  • 72. Data: 2012-02-19 21:26:10
    Temat: Re: procedura tworzenia program�w
    Od: " M.M." <m...@W...gazeta.pl>

    Andrzej Jarzabek <a...@g...com> napisaďż˝(a):

    > On 19/02/2012 20:11, bartekltg wrote:
    > >
    > > Ale to ma się nijak do histroi o wspolnym podnoszeniu
    > > mebla. To wszystko 'pokazywanie że się ominęło śmiecia'.
    > > Tego nie kwestionuję. Chciałem tylko zobaczyć przykład
    > > z programowania odpowiadający historii o wspolnym
    > > podnoszeniu mebla.
    > >
    > > Masz taki, czy jednak analogia była nietrafiona?
    >
    > Ja mam taki przykład. Przepraszam, że bez szczegółów, ale ogólnie
    > sytuacja wyglądała tak, że program się zachowywał w sposób, który nie
    > powinien być możliwy. Byłem w stanie prześledzić do konkretnego momentu
    > i po prostu wylgądało jakby zachowanie programu było sprzeczne z kodem,
    > tudzież zmieniało się wraz ze zmianą okoliczności, które na to
    > zachowanie nie powinny mieć wpływu. Straciłem dwa dni na debugowaniu wtę
    > i wewtę, logowaniu różnych rzeczy, podstawianiu danych itd. i nic - po
    > prostu paradoks. Pokazałem koledze i w 10 minut zorientowaliśmy się,
    > gdzie popełniłem błędne założenie.

    Mialem podobnie. Stracilem ze dwie doby na debugowanie i bledu nie
    znalazlem. Napisalem na grupe dyskusyjna i mi w 10 minut ktos powiedzial
    ze mam wersje kompilatora z bledami. Nigdy by mi do glowy nie przyszlo
    ze w kompilatorach moga byc bledy.

    Pozdrawiam









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


  • 73. Data: 2012-02-19 21:26:38
    Temat: Re: procedura tworzenia programów
    Od: Andrzej Jarzabek <a...@g...com>

    On 19/02/2012 21:14, A.L. wrote:
    > On Sun, 19 Feb 2012 19:18:08 +0100, szyk<s...@o...pl> wrote:
    >
    > Natomiast zeby nei wiem co pisac o "pair programming" i podobnych
    > rzeczach - koszt projektu jest sprawa najwazniejsza. Albowiem jak sie
    > sklada papiery w przetargu, to tzreba napisac ile projekt bedzie
    > kosztowal. Jak zorganizujemy go tak ze przy jednym komputerze bedzie
    > siedzialo dwoch facetow, to albo: a) koszt projektu wzrosnie
    > dwukrotnie, albo b) kazdy z facetow zadowoli sie polowa pensji. W tym

    Albo c) dwóch facetów zrobi to samo zadanie 2 razy szybciej niż 1 facet.


  • 74. Data: 2012-02-19 21:27:05
    Temat: Re: procedura tworzenia programów
    Od: A.L. <l...@a...com>

    On Sun, 19 Feb 2012 19:59:09 +0100, bartekltg <b...@g...com>
    wrote:

    >W dniu 2012-02-19 16:45, A.L. pisze:
    >
    >
    >> Bajanai wszelkich "gurus" padaja na podatny grunt, bo wiekszosc
    >> managementu nie ma przyslowiowego "clue", wiec lapie sie dowolnej
    >> glupoty any uratowac swa d..... Wiadomo ze jak nei potrafisz nic
    >> robic, to zostajesz guru. Musisz miec tylko odpowiednai ilosc Daru
    >> Bozego ktory nazywa sie "hucpa"
    >
    >
    >Ale to nikt z 'darem bożym' nie połapał sie i nie zrobił kariery
    >na demaskowaniu złych metod.
    >
    Dlaczego nie?

    Polecam ksiazke:

    Extremem Programming Refactored: The Case Against XP, Matt Stephens,
    Doug Rosenberg

    Z notki wydawcy:

    Extreme Programming Refactored: The Case Against XP (featuring Songs
    of the Extremos) takes a satirical look at the increasingly-hyped
    extreme programming (XP) methodology. It explores some quite
    astonishing Extremo quotes that have typified the XP approach quotes
    such as, "XPers are not afraid of oral documentation," "Schedule is
    the customer's problem," "Dependencies between requirements are more a
    matter of fear than reality" and "Concentration is the enemy."

    In between the chuckles, though, there is a serious analysis of XP's
    many flaws. The authors also examine C3, the first XP project, whose
    team (most of whom went on to get XP book deals shortly before C3's
    cancellation) described themselves as "the best team on the face of
    the Earth." (In a later chapter, the authors also note that one
    problem which can affect pair programmers is overconfidence--or is that
    "eXcessive courage"?). The authors examine whether the problems that
    led to C3's "inexplicable" cancellation could also afflict present-day
    XP projects.

    A tak w ogole, to trudno z tym walczyc. Proponuje pzreprowadzic
    analogie z obalaniem teorii Newtona pzrez niektoryc hwynalazcow, czy
    uporczywie krazacymi projektami samochodu napedzanego woda.

    A.L.
    >


  • 75. Data: 2012-02-19 21:31:45
    Temat: Re: procedura tworzenia programów
    Od: " M.M." <m...@g...pl>

    A.L. <l...@a...com> napisał(a):

    > Bycie firmy nie zalezy od programistow. To tak jakby powiedzec ze przy
    > budowie mostu kazdy spawacz musi meic zastepce, bo jakby ten wlasciwy
    > poszedl na chorobe i nei bylo zastepcy, to by sie budowa zawalila.

    To raczej tak jakby powiedziec ze jakosci spawow nie trzeba
    sprawdzac bo spawacz powinien sobie poradzic, w koncu byl na kursie i
    spawac umie.

    Pozdrawiam


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


  • 76. Data: 2012-02-19 22:20:40
    Temat: Re: procedura tworzenia programów
    Od: bartekltg <b...@g...com>

    W dniu 2012-02-19 22:16, Andrzej Jarzabek pisze:
    > On 19/02/2012 20:11, bartekltg wrote:
    >>
    >> Ale to ma się nijak do histroi o wspolnym podnoszeniu
    >> mebla. To wszystko 'pokazywanie że się ominęło śmiecia'.
    >> Tego nie kwestionuję. Chciałem tylko zobaczyć przykład
    >> z programowania odpowiadający historii o wspolnym
    >> podnoszeniu mebla.
    >>
    >> Masz taki, czy jednak analogia była nietrafiona?
    >
    > Ja mam taki przykład. Przepraszam, że bez szczegółów, ale ogólnie
    > sytuacja wyglądała tak, że program się zachowywał w sposób, który nie
    > powinien być możliwy. Byłem w stanie prześledzić do konkretnego momentu
    > i po prostu wylgądało jakby zachowanie programu było sprzeczne z kodem,
    > tudzież zmieniało się wraz ze zmianą okoliczności, które na to
    > zachowanie nie powinny mieć wpływu. Straciłem dwa dni na debugowaniu wtę
    > i wewtę, logowaniu różnych rzeczy, podstawianiu danych itd. i nic - po
    > prostu paradoks. Pokazałem koledze i w 10 minut zorientowaliśmy się,
    > gdzie popełniłem błędne założenie.

    To nawet częsta sytuacja. Ale to zwykła praca zespołowa.

    > Oczywiście możesz powiedzieć, że założenie błędne, bo gdybym nie
    > poprosił kolegi o pomoc, to pewnie sam bym w końcu wpadł na właściwe
    > rozwiązanie, nawet gdyby to miało zająć kolejne 3 dni, ale tak to już
    > bywa z analogiami - nie zawsze są w 100% dokładne.

    Ale ta była dodana jako kolejna, po 'zwykłej pracy zespołowej'.

    "Gdy trzeba wyrzucic zepsuta komode to jedna nigdy by nie
    poradzila bo jest za slaba.
    We dwie i tego smiecia sie pozbeda."

    Tu mamy zupełnie inną sytuację. Bez pomocy nie masz możliwości
    sobie poradzić, bo za mały udźwig, a z pomoca niesiecie.

    Wydeje mi się, że M.M po prostu przesadził z porównaniem i tyle.
    Bo porównanie jest z sufitu.


    > Inną, być może lepszą, ale też trudniejszą do wykazania na konkretnym
    > przykładzie analogią jest jakość kodu wytwarzanego przez programistów i
    > jego konsekwencje. Najbardziej oczywistą sprawą jest ilość defektów:
    > nawet mając dział QA, który wykrywa powiedzmy większość defektów, ilość
    > tychże w kodzie programisty ma kolosalne znaczenie: zawsze ilość
    > defektów pozostanie niewykrytych, co może narazić klientów na straty i
    > spowoduje utratę reputacji firmy i zespołu, natomiast nawet te, które
    > zostaną wykryte, będą opóźniać release lub powodować redukcję ficzerów w
    > danej wersji. I teraz możesz założyć, że dany programista będzie
    > popełniał ileś tam błędów w danym kawałku kodu - będzie to zależało od
    > różnych czynników, jak język, narzędzia, metodologia itd., ale zawsze
    > jakiś tam poziom błędów będzie. I w zasadzie niewiele może sam z siebie
    > zrobić, żeby ten poziom błędów zmniejszyć - gdyby potrafił pisać lepiej,
    > to by już tak pisał. Ta ilośc błędów to waga szafki, którą może
    > udźwignąć. Pracując z drugim programistą razem stworzą kod, który ma
    > mniejszą ilość defektów, niż którykolwiek z nich mógłby osiągnąć z
    > osobna. Czyli dźwigają cięższą szafkę, niż każdy z nich z osobna mógłby
    > udźwignąć.

    Nie. To jest dokładnie przykład z posta wcześniej, obie sprzątaczki
    szukają śmieci i razem mają mniejszą szansę przegapić paproszek.

    Takie przykłady można by mnożyć. Masz napisać coś na 'za 24h'.
    Sam nie dasz rady, z kolegą dasz. Ale nie jest to odpowiednik
    siłowania sie z szafką.


    > Taką samą analogię można zbudować dla innych parametrów jak performance,
    > maintainablility, jakość projektu rozmaitych interfejsów itd.

    Tak. I to wszytko analogia jakości sprzątania czy wyrobienia
    się na powrót właścicieli domu. Nie masz tam nigdzie sytuacji
    typu 'sam nie ruszysz bo nie masz możliwości'.

    pzdr
    bartekltg


  • 77. Data: 2012-02-19 22:32:40
    Temat: Re: procedura tworzenia programów
    Od: bartekltg <b...@g...com>

    W dniu 2012-02-19 22:21, M.M. pisze:

    > Nigdy Ci sie nie zdarzylo ze kazde 15 minut zwloki powodowalo
    > jakies ryzyko? Mnie sie zdarzylo ze przedwczesnie zainstalowany
    > system uniemozliwil normalny powrot do domu 300 ludziom (i
    > nie tylko). Poziom wkurwienia klienta rosl wykladniczo, klient
    > znal 30 innych klientow i mogl smrodu narobic. Kazde 15 minut
    > przy usuwaniu usterki bylo na wage zlota. Jestes pewny ze jeden
    > programista tak samo podola jak para przy takim stresie?

    Super, ale to nie ten przykład:)

    Dobra, kończe to bo się trollociąg z rozumienia
    różnic między analogiami zrobi

    pzdr
    bartekltg



  • 78. Data: 2012-02-19 22:32:43
    Temat: Re: procedura tworzenia programów
    Od: " M.M." <m...@g...pl>

    bartekltg <b...@g...com> napisał(a):

    > Wydeje mi się, że M.M po prostu przesadził z porównaniem i tyle.
    > Bo porĂłwnanie jest z sufitu.

    Porownanie bylo celowo tak dobrane aby uwypluklic o co chodzi, bo ktos
    kompletnie nie zrozumial i mysla ze chodzi o "dwie sprzataczki zamiataja
    jedna miotla".

    Pozdrawiam


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


  • 79. Data: 2012-02-19 22:34:53
    Temat: Re: procedura tworzenia programów
    Od: " M.M." <m...@g...pl>

    bartekltg <b...@g...com> napisał(a):

    > W dniu 2012-02-19 22:21, M.M. pisze:
    >
    > > Nigdy Ci sie nie zdarzylo ze kazde 15 minut zwloki powodowalo
    > > jakies ryzyko? Mnie sie zdarzylo ze przedwczesnie zainstalowany
    > > system uniemozliwil normalny powrot do domu 300 ludziom (i
    > > nie tylko). Poziom wkurwienia klienta rosl wykladniczo, klient
    > > znal 30 innych klientow i mogl smrodu narobic. Kazde 15 minut
    > > przy usuwaniu usterki bylo na wage zlota. Jestes pewny ze jeden
    > > programista tak samo podola jak para przy takim stresie?
    >
    > Super, ale to nie ten przykład:)

    Ten przyklad. Tam sobie sprzataczka nigdy nie poradzi sama. Tutaj sobie
    programista nigdy nie poradzi sam bo klient zrezygnuej ze zlecenia i
    firma padnie. No chyba ze bedze pracowal hobbystycznie bez wyplaty.

    Pozdrawiam


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


  • 80. Data: 2012-02-19 22:38:26
    Temat: Re: procedura tworzenia programów
    Od: Andrzej Jarzabek <a...@g...com>

    On 19/02/2012 22:20, bartekltg wrote:
    > W dniu 2012-02-19 22:16, Andrzej Jarzabek pisze:
    >>
    >> Ja mam taki przykład. Przepraszam, że bez szczegółów, ale ogólnie
    >> sytuacja wyglądała tak, że program się zachowywał w sposób, który nie
    >> powinien być możliwy. Byłem w stanie prześledzić do konkretnego momentu
    >> i po prostu wylgądało jakby zachowanie programu było sprzeczne z kodem,
    >> tudzież zmieniało się wraz ze zmianą okoliczności, które na to
    >> zachowanie nie powinny mieć wpływu. Straciłem dwa dni na debugowaniu wtę
    >> i wewtę, logowaniu różnych rzeczy, podstawianiu danych itd. i nic - po
    >> prostu paradoks. Pokazałem koledze i w 10 minut zorientowaliśmy się,
    >> gdzie popełniłem błędne założenie.
    >
    > To nawet częsta sytuacja. Ale to zwykła praca zespołowa.

    No więc zwykła praca zespołowa (przynajmniej taka, z jaką się zwykle
    spotykam) prowadzi do sytuacji, gdzie szukasz pomocy po np. dwóch dniach
    walenia głową w mur. Przewaga programowania parami jest taka, że pomoc
    masz od razu.

    [...]
    > Nie. To jest dokładnie przykład z posta wcześniej, obie sprzątaczki
    > szukają śmieci i razem mają mniejszą szansę przegapić paproszek.
    [...]
    >> Taką samą analogię można zbudować dla innych parametrów jak performance,
    >> maintainablility, jakość projektu rozmaitych interfejsów itd.
    >
    > Tak. I to wszytko analogia jakości sprzątania czy wyrobienia
    > się na powrót właścicieli domu. Nie masz tam nigdzie sytuacji
    > typu 'sam nie ruszysz bo nie masz możliwości'.

    Różne analogie można tworzyć, zależy co się za co podstawi. Ogólnie
    można powiedzieć, że praca sprzątaczki i praca programisty są na tyle
    różne, że dowolna analogia zawali się jak zaczniesz ją rozbierać.

    Tutaj jest analogia tylko taka, że kod produkowany przez parę
    programistów ma szanse mieć lepsze parametry, niż kod produkowany przez
    każdego z tych programistów oddzielnie.

    Być może analogia załamuje się na sytuacji, gdzie programiści co prawda
    na ogół pracują solo, ale sobie pomagają. Problem wtedy jest taki, że
    jeśli sobie pomagają rzadko i krótko to to niewiele daje, a jeśli sobie
    pomagają dużo i często to ma praktycznie wszystkie wady programowania
    parami, plus dodatkowo taką, że częste przełączanie kontekstów powoduje
    utratę produktywności samo z siebie.

strony : 1 ... 7 . [ 8 ] . 9 ... 13


Szukaj w grupach

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: