Dnia Sat, 05 Jan 2013 11:37:37 +0000, Andrzej Jarzabek wyszeptal:

> On 02/01/2013 17:28, AK wrote:
>> Użytkownik "Wojciech Muła" <w...@g...com> napisał :
>>
>>> Agile skupia się na tworzeniu działającego produktu, nie dostarcza
>>> żadnych narzędzi dla zespołu w celu tworzenia utrzymywalnego programu
>> ^^^^^^^^^^^^^^^
>>
>> To (i calosc posta Wojtka) to dla mnie sedno tzw. Agile.
>
> 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.

Jak ja lubię tą legendę. Oznacza ona mniej więcej: "to już wiecie,
dlaczego dotychczas nam nie szło, teraz będzie super".

--
Edek

do góry

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.
>
> Jak ja lubię tą legendę. Oznacza ona mniej więcej: "to już wiecie,
> dlaczego dotychczas nam nie szło, teraz będzie super".

Jest duży postęp w dziedzinie inżynierii oprogramowania, nic dziwneggo,
że nowsze metody dają lepsze rezultaty niż stare.

do góry

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.

>> Jak ja lubię tą legendę. Oznacza ona mniej więcej: "to już wiecie,
>> dlaczego dotychczas nam nie szło, teraz będzie super".
>
> 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.

Ja preferuję Agile, z tym że z zupełnie innych powodów niż prezentujesz.
Waterfall góruje nad dowolnym amorfizmem.

--
Edek

do góry

On 2013-01-05 18:55, Edek Pienkowski wrote:
> Dnia Sat, 05 Jan 2013 12:19:17 +0000, Andrzej Jarzabek wyszeptal:
>
>
> Ja preferuję Agile, z tym że z zupełnie innych powodów niż prezentujesz.
> Waterfall góruje nad dowolnym amorfizmem.
>
W przypadku zmienajacych sie w trakcie wymagan klienta rowniez ? ;-)


Pozdrawiam

Marek

do góry

Dnia Sat, 05 Jan 2013 20:06:54 +0100, Marek Borowski wyszeptal:

> On 2013-01-05 18:55, Edek Pienkowski wrote:
>> Dnia Sat, 05 Jan 2013 12:19:17 +0000, Andrzej Jarzabek wyszeptal:
>>
>>
>> Ja preferuję Agile, z tym że z zupełnie innych powodów niż
>> prezentujesz.
>> Waterfall góruje nad dowolnym amorfizmem.
>>
> W przypadku zmienajacych sie w trakcie wymagan klienta rowniez ? ;-)

Eee, nie, waterfall będzie się toczył nawet jak klyent powie "nie,
już mi sie odechciało" ;) Chyba że szef zadzwoni, żeby odejść od
klawiatury.

--
Edek

do góry

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

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

do góry

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

do góry

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?

do góry

W dniu poniedziałek, 31 grudnia 2012 18:12:49 UTC+1 użytkownik M.M. napisał:
> W dniu niedziela, 30 grudnia 2012 20:42:52 UTC+1 użytkownik firr kenobi napisał:
>
> >(zeby cos zaprogramowac wystarczy zaprogramowac a zeby cos ladnie wygladalo
>
> >czeba to czasem programowac 15 razy nim sie trafi na cos co wyglada a i tak
>
> >posniej efekt sie moze posypac przy kolejnych dobudowach)
>
> Powiedzmy umownie, ze sa dwa rodzaje aplikacji.
>
>
>
> Jedne po prostu sie pisze, maja dzialac, a szczegoly typu: szybkosc
>
> dzialania, ilosc pamieci, rodzaj wykorzystanych technik programistycznych -
>
> mozna z jakis powodow calkowicie, albo prawie calkowicie pominac.
>
>
>
> Drugi rodzaj to taki, w których rzeźbi się tygodniami, żeby przyspieszyć o
>
> kilka milisekund, albo myśli się miesiącami, żeby opracować lepszy algorytm.
>
> Czasami trzeba udowodnić czy dany algorytm w ogóle może rozwiązywać jakieś
>
> zadanie. Do tego drugiego rodzaju można by jeszcze sporo dorzucić, Ty np.
>
> dorzucasz dopracowanie grafiki, efektów, itd.
>
>
>
>
>
> Wszystko wskazywałoby na to, że ten drugi rodzaj aplikacji jest dużo
>
> trudniejszy, bardziej ambitny, czy wymagający większych umiejętności. Okazuje
>
> się jednak, że ten pierwszy typ aplikacji, może po pierwsze znacznie
>
> się rozrosnąć - zgranie dużej ilości rożnych elementów programu powoduje,
>
> że staje się on równie trudny jak te z drugiego rodzaju. Po drugie, może
>
> być bardzo mały budżet na ich wykonanie, wtedy trzeba taką aplikację szybko
>
> zrealizować żeby wyjść na jakiś minimalny plus.
>

no i co? ja sie prawie wylacznie interesuje
ta opcja z optymalizacja no i tyle -
[[ aczkolwiek ostatnio wogole wzialem sobie
troche urlop od kodowania znowu "nie firrr,
to koniec, nie bedzie nic wiecej... ZALUJE ZE
CIE ZNALAM A A xD" ;-) ]]
- Teraz jest w sumie tak ze pc ma akurat
dosyc mocy do pewnych zastosowan ale z
drugiej strony ciagle jednak trzeba sie
nabiedzic by ramka miala 15 ms a nie 30
a jest to bardzo znaczna roznica w
feelingu

do góry

Ja tak z pozoru offtopicznie:

On Thu, 27 Dec 2012, boryspower wrote:

> Przykład: Stworzenie aplikacji do fakturowania

1. Przeczytać ustawę o VAT i stwierdzić że nic się z tego nie rozumie
2. Spytać "fachowca" jak ma być
3. Stwierdzić że coś nie pasuje
4. Sprawdzić to i owo w internecie
5. powtórzyć 1. i stwierdzić że "fachowiec" był niedouczony ;)

Potem można zabrać się za rozważania jak program ma działać.

Nie, *NIE* żartuję - wziąłeś doskonały przykład, niemal wzorcowy,
na to jak można wtopić na błędach założeń :)
Policzenie choćby tylko VAT (a niekoniecznie jest to jedyny
podatek który musi być ujawniany na dokumencie) jest dopuszczalne
na wiele sposobów, w tym takich trudniejszych do wymyślenia,
ale *niekiedy* napotyka na ograniczenia (trzeba zastosować
się do któregoś spośród tych wielu) i wtedy na .podatki pojawia
post w kategorii "a u głupka kontrahenta nie chcą poprawić f-ry
bo twierdzą że system nie pozwala" :P

Nie, nie mam na myśli stawki itede :)

Obstawiam że takich przypadków jest sporo - coś co wydaje się
proste zawiera pułapki które później trudno usunąć.
Taka aplikacja, dobrze zrobiona ale mająca działać bez wsparcia
"24h na dobę czas dostarczania poprawki 2h" ;) np. powinna
umożliwiać wpisanie dokumentu w 100% ręcznie lub ręczne
poprawienie wszystkich pól, bo nie sposób przewidzieć która
z kombinacji "metod" może wyskoczyć.
Uczciwie - przewidziałbyś?
Nie ma to nic wspólnego z tym co opisałeś - co wykonawca może
zrobić doskonale po stworzeniu własnego opisu.

> - jak przygotować dokumentację/opis projektu

Tak żeby był tam zapis "zgodnie z przepisami", co daje do ręki
narzędzie do doprowadzenia wykonawcy do rozpaczy ;)
(patrz p.1 :), polecam osobiście zajrzeć do treści)

pzdr, Gotfryd

do góry