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?