🚀 go-pugleaf

Przemek Pokrywka napisał(a):
> Grzesiek G. napisał(a):
> 
>> Ale zadanie wykonywane przez program to jest coś, co jest opisane w 
>> jakimś dokumencie. Więc jeżeli nikt nie napisał, że sprawdzanie 
>> istnienia pliku jest częścią zadania, to (według przedstawionej przeze 
>> mnie teorii) jest sytuacją wyjątkową i można ją śmiało obsłużyć przez 
>> catch.
>>
>> Co do tezy, że klient nie interesuje się tym co robi w środku metoda 
>> się zgadzam. Jednak klienta interesuje jak robi. Więc jeśli robi zbyt 
>> wolno, bo przebieg programu jest sterowany wyjątkami, to klient może 
>> się zainteresować.
> 
> 
> Przedstawiona teoria jest dla mnie bardzo naciągana, z tego powodu, że 
> klient, jeśli mu zależy na wydajności, to napisze o tym wprost, i to w 
> odniesieniu do konkretnych przypadków użycia, a nie w postaci stwierdzeń 
> na temat obsługi wyjątków w ciałach poszczególnych metod.
> Wyjątki mogą stanowić problem wydajnościowy w marginalnych wypadkach i 
> tylko raport narzędzia typu profiler może stanowić przesłankę do 
> zastąpienia ich czymś innym. Byłbym bardzo zainteresowany usłyszeniem o 
> przypadku, w którym u kogoś to faktycznie obsługa wyjątków pod względem 
> wydajności stanowiła wąskie gardło systemu, przez co system nie spełniał 
> wymagań wydajnościowych postawionych mu przez klienta.

Aż dziw mnie bierze (i przyznam że zazdroszczę) :-), że się nie 
spotkałeś ani razu :-). Miałem do wykonania program walidujący i 
importujący plik csv do bazy danych. Wyjściem z nieudanej walidacji był 
raport błędów. Program był zrobiony tak, że przetwarzał plik do 
struktury obiektowej, którą obrabiał i zapisywał w bazie. Plik był 
poprawny, jeśli dawał się przekształcić do struktury obiektowej.

Niestety, rzeczywiste pliki okazały się fatalne. Tworzyło je pare osób w 
  MS Office i różnych Open Officach, także walidacja stała się ważna. Co 
gorsza za długo trwała (kilka minut), co bardzo złościło klienta. Była 
napisana poczętkowo w stylu:
try
{
	zmienna = decimal.Parse(napis);
	...
}
catch(InvalidFormatException exc)
{
	logger.log("Nie można skonwertować ...);
}

została przepisana na:
if(decimal.TryParse(napis)
{
	zmienna = decimal.Parse(Napis);
}
else
{
	logger.log("Nie można skonwertować ...);
}
Czas wykonania walidacji skrócił się do kilkudziesięciu sekund.


> Jeszcze raz za mistrzem Knuthem powtórzę, że "premature optimization is 
> the root of all evil"
> 

Z tą tezą też się zgadzam. Ale jeżeli np. w naszej aplikacji WWW strony 
ładują się u klienta kilkadziesiąt sekund, to nie czekamy na 
uzupełnienie specyfikacji uwagami o wydajności, tylko bierzemy się do 
pracy. Często wystarczy wyłączyć emula u użytkowników sieci klienta, ale 
czasami trzeba poprawić nasz soft.

Pozdrawiam

-- 
Grzegorz Gruza
Odpowiadając usuń "spamerom_nie." z adresu!!!