On 2011-05-19, Andrzej Jarzabek <a...@g...com> wrote:
>> Koszt utrzymania przy wykorzystaniu automatów
>> dokumentujących jest niewielki (zarówno czasowy jak i kwotowy). Tylko
>> trzeba mieć dobry i sumienny zespół który wie co robi.
>
> Z mojego doświadczenia: wartość automatycznie generowanej dokumentacji
> też nie jest szczególnie wielka (w porównaniu z przeglądaniem kodu).

Bo ja wiem? Nawet w niewielkich projektach, gdy mam kod podzielony na
moduły, wolę oglądać API modułu pisanego parę tygodni temu
w przeglądarce HTML niż w kodzie źródłowym, w którym zresztą i tak muszą
być takie same komentarze określające konwencje, jak te idące do
perldoca czy innego doxygena.

Inaczej: jeśli te komentarze i tak już tam muszą być, to czemu by
przyzerowym kosztem ich nie wyróżnić (dla człowieka i dla generatora
dokumentacji) i nie wygenerować z nich dokumentacji dla API?

> Czy ta wartość równoważy overhead, nie mam na ten temat zdania, ale
> zdecydowanie uważam, że nie robi to większej różnicy.

Wielkiej różnicy nie robi, ale moim zdaniem i tak jest wystarczająca
żeby zrównoważyć koszt wprowadzenia formatowania.

>> > Tu trochę przyznam, że wychodzę poza swoje kompetencje, ale o ile
>> > rozumiem, to przede wszystkim XP pomyślanie jest nie pod kątem
>> > projektów, które się w pewnym momencie zdaje i zamyka, tylko raczej do
>> > takich, które w pewnym (wczesnym) momencie mają pierwszy release, a
>> > potem regularni i dość często kolejne release'y, np. co miesiąc albo co
>> > dwa miesiące.
>>
>> To co opisujesz, to bardziej mi pasuje do starej definicji
>> prototypowania z ominięciem najważniejszej części, że prototypu nie
>> wdraża się produkcyjnie.
>
> Hm? Prawie każdy produkt software'owy po wypuszczeniu do produkcji ma
> kolejne wersje.

Ale co miesiąc? O_o
Toż samo testowanie czy wszystko działa w środowisku zbliżonym do
produkcji trwa tyle czasu (patrzę z perspektywy admina, więc osoby,
która to wdraża u klienta na produkcji).

--
Secunia non olet.
Stanislaw Klekot