eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programmingProwadzenie/dokumentowanie projektu...Re: Prowadzenie/dokumentowanie projektu...
  • Data: 2013-01-07 01:09:21
    Temat: Re: Prowadzenie/dokumentowanie projektu...
    Od: Andrzej Jarzabek <a...@g...com> szukaj wiadomości tego autora
    [ pokaż wszystkie nagłówki ]

    On 06/01/2013 17:03, Edek Pienkowski wrote:
    > Dnia Sun, 06 Jan 2013 16:25:45 +0000, Andrzej Jarzabek wyszeptal:
    >>
    >> Nawet wtedy pomoże. Dokładna metoda opisana jest w "Working Effectively
    >> With Legacy Code" Michaela Feathersa. Przede wszystkim jednak chodzi o
    >> to, żeby do takiej sytuacji nie doprowadzić, i skuteczne narzędzia do
    >> tego dają ci TDD i incremental refactoring (plus być może kilka innych
    >> rzeczy, jak dobre coding standards i karty CRC).
    >
    > No tak, jak coś jest w jakiejś książce, znaczy to jest Święta prawda ;)

    Nie znaczy, ale w tym przypadku akurat tak jest. Podałem namiar na
    literaturę w celu odniesienia do opis tego, o czym mówię - dowodem
    skuteczności natomiast nie jest istnienie książki, tylko korroboracja
    tych technik w bardzo wielu projektach - również przeze mnie.

    > Agile składa się z wielu technik, ale celem większości jest skrócenie
    > cyklu feedbacku w wielu procesach, z których zbudowany jest większy
    > proces zwany produkcją oprogramowania. Do czego nawiązuje nazwa.

    No więc jedną z metodologii, na których zbudowany został ruch Agile jest
    XP, który właśnie wprowadził techniki, o których mówię - jeszcze zanim
    cokolwiek się nazywało Agile. Od tego czasu zresztą te techniki zostały
    mocno rozwinięte i są po prostu częścią ogółu technik określanych jako
    Agile.

    Opierają się one jak najbardziej na cyklach feedbacku (tych
    najkrótszych, liczonych nawet w minutach), ale zasada, z której
    wypływają jest inna: jeśli oddajesz oprogramowanie często, np. co
    tydzień, i z zasady oddajesz je w stanie nadającym się do produkcji, to
    nie masz szczególnych powodów, żeby starać się zrobić więcej w jednym
    tygodniu, jeśli to oznacza, że w następnych zrobisz mniej. Zasadą jest
    "sustainable pace" - starasz się w każdej iteracji oddawać podobnej
    wielkości kawałek roboty, a potem na tym budujesz plany szacujące kiedy
    mniej więcej co zostanie zrobione. Dlatego też jeśli taki proces ma
    działać, twój kod musi cały czas być "maintainable", bo jak się w nim
    zagrzebiesz, to stracisz możliwość dostarczania sensownej wielkości
    inkrementów w kolejnych tygodniach.

    [...]
    > oprogramowania, dopiero one są inżynierą oprogramowania czyli materią,
    > sam Agile/Waterfall to ogólna rama kontroli procesów, same procesy
    > są bardzo podobne - z wymienionych testy i coding standards
    > są uniwersalne, dochodzi wiele spraw technicznych i ogólne
    > zarządzanie utrzymujące wysokie standardy.

    TDD to nie tylko testy, poza tym oczywiście można stosować te wszystkie
    rzeczy nawet w ramach procesów które nie mają nic wspólnego z Agile.

    Ja tylko polemizowałem z tym, że Agile "nie daje narzędzi" - otóż daje,
    bardzo skuteczne narzędzia, tylko trzeba wiedzieć gdzie patrzeć. Prakyki
    Agile tworzą pewne spektrum od "management practices" do "engineering
    practices". Jeśli szukamy narzędzi do utrzymywania "maintainability"
    kodu, to raczej będą one po stronie "engineering" nie "management"
    (gdzie np. leży cały Scrum).

    > No ale jak ktoś mówi "przepiszmy wszystko", to trochę tak jakby
    > ktoś w towarzystwie powiedział "jesteście głupi" (nie mylić
    > z "czy aby jesteście trzeźwi, obywatelu"). Albo faktycznie muszą
    > gruntownie zmienić zachowanie i jest to mesjasz, który odmieni
    > oblicze projektu, albo też nie do końca zrównoważony łepek,
    > który ani nie potrafi modyfikować kodu, ani też nie będzie
    > potrafił go napisać (tym bardziej) od początku, nie mówiąc
    > o "lepiej". Tak czy inaczej, bez więcej niż jednego podbitego
    > oka się nie obędzie, więc najwyraźniej coś do tej pory mocno
    > zawiodło: albo faktycznie proces pisania kodu nie podlegał
    > żadnej kontroli, albo w grupie jest ktoś "nie do końca rozumiejący
    > sytuację" i "radykalny wobec istniejących norm społecznych".
    > (Słyszałem już parę razy "przepiszmy", częściej był
    > to głupi pomysł, ale widziałem też uzasadniony. Zawsze osoba
    > wykazująca wtedy niezbędną specjalną troskę była sowicie opłacana,
    > błędy katastrofalne kosztują).

    Nie do końca wiem jak zinterpretować tę wypowiedź. Ja w życiu
    uczestniczyłem w kilku rewrite-ach, i newt nie twierdzęę, że to zawsze
    zły pomysł (chociaż zawsze ryzykowny). Natomiast jet to świadectwo
    osatecznego krachu "maintainability" - pomijając szczególne sytuacje,
    jeśli znajdujemy się w sytuacji, gdzie bardziej opłaca się napisać coś
    od nowa niż poprawiać istniejący program, to raczej mamy do czynienia z
    nagromadzeniem dużej ilości błędów, z której nie bardzo wiadomo, jak się
    wycofać. Zwykle takich decyzji się lekką ręką nie podejmuje.

    >>>> Jest duży postęp w dziedzinie inżynierii oprogramowania, nic
    >>>> dziwneggo,
    >>>> że nowsze metody dają lepsze rezultaty niż stare.
    >>> Tak, od małpy do świnki morskiej nastąpiła długa droga ewolucji.
    >> To trochę OT, ale proponuję podszkolić się z biologii.
    >
    > To byłaby połowiczna analiza tekstu pisanego.

    Masz na myśli tekst "O pochodzeniu gatunków" Darwina?

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: