Dnia Sun, 06 Jan 2013 16:25:45 +0000, Andrzej Jarzabek wyszeptal:

> On 05/01/2013 17:55, Edek Pienkowski wrote:
>> Dnia Sat, 05 Jan 2013 12:19:17 +0000, Andrzej Jarzabek wyszeptal:
>>
>>> On 05/01/2013 11:46, Edek Pienkowski wrote:
>>>> Dnia Sat, 05 Jan 2013 11:37:37 +0000, Andrzej Jarzabek wyszeptal:
>>>>>
>>>>> Jest dokładnie przeciwnie - to Agile wprowadziło skuteczne narzędzia
>>>>> do tworzenia utrzymywalnego programu. Przedtem było tak, że się
>>>>> tworzyło program, a potem w ramach utrzymywania jego utrzymywalność
>>>>> się stopniowo degradowała, aż dochodziło do tego, że taniej było
>>>>> zrobić rewrite niż zmieniać istniejący kod.
>>
>> Powtórzę się: tu Agile juz niewiele pomoże.
>
> 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 ;)

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.

Przy czym milczącym założeniem jest, że te procesy faktycznie istnieją,
i że jest nad nimi kontrola, czyli istnieje reakcja adekwatna do
sprzężenia zwrotnego. Tak jak w kontroli procesów przemysłowych
procesy i ich kontrola wymagają tych elementów, pomimo tego, że
tutaj część maszynerii jest białkowa; procesy owe dotyczą wytwarzania
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.

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

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

--
Edek