Zpo-8-wyk-Slajd6: Różnice pomiędzy wersjami
Nie podano opisu zmian |
Nie podano opisu zmian |
||
| Linia 1: | Linia 1: | ||
== | ==Intuicyjna definicja== | ||
[[Image:zpo-8-wyk-Slajd6.PNG| | [[Image:zpo-8-wyk-Slajd6.PNG|Intuicyjna definicja]] | ||
Pierwsze nieformalne określenie refaktoryzacji podał w swojej rozprawie doktorskiej W. Opdyke w 1991 roku. Podkreślała ona trzy elementy: | |||
* jest to transformacja kodu źródłowego programu (a więc czytelnego dla programisty) | |||
* która poprawia jego pielęgnowalność poprzez uproszczenie struktury i dostosowanie jej do zmieniających się wymagań. | |||
* ale nie zmienia jego funkcjonalności z punktu widzenia użytkownika tego oprogramowania | |||
Szczególnie ta ostatnia własność – najważniejsza, ale i najtrudniejsza do zapewnienia – budziła wiele dyskusji. Dotyczyły one kwestii, czy program miał zachowywać się identycznie we wszystkich możliwych przypadkach, także wykraczających poza jego specyfikację (np. możliwa była inna odpowiedź systemu po przekroczeniu założonego obciążenia albo uruchomieniu w odmiennym środowisku), czy też wystarczy, jeżeli zmiana nie będzie zauważalna w typowym użyciu. | |||
Narzucenie bardziej rygorystycznej interpretacji powodowało konieczność przeprowadzania dowodu poprawności, co w praktyce wykluczało efektywne refaktoryzowanie programów. | |||
[[zpo-8-wyk-Slajd5 | << Poprzedni slajd]] | [[zpo-8-wyk-toc|Spis treści ]] | [[zpo-8-wyk-Slajd7 | Następny slajd >>]] | [[zpo-8-wyk-Slajd5 | << Poprzedni slajd]] | [[zpo-8-wyk-toc|Spis treści ]] | [[zpo-8-wyk-Slajd7 | Następny slajd >>]] | ||
Aktualna wersja na dzień 18:15, 4 lis 2006
Intuicyjna definicja
Pierwsze nieformalne określenie refaktoryzacji podał w swojej rozprawie doktorskiej W. Opdyke w 1991 roku. Podkreślała ona trzy elementy:
- jest to transformacja kodu źródłowego programu (a więc czytelnego dla programisty)
- która poprawia jego pielęgnowalność poprzez uproszczenie struktury i dostosowanie jej do zmieniających się wymagań.
- ale nie zmienia jego funkcjonalności z punktu widzenia użytkownika tego oprogramowania
Szczególnie ta ostatnia własność – najważniejsza, ale i najtrudniejsza do zapewnienia – budziła wiele dyskusji. Dotyczyły one kwestii, czy program miał zachowywać się identycznie we wszystkich możliwych przypadkach, także wykraczających poza jego specyfikację (np. możliwa była inna odpowiedź systemu po przekroczeniu założonego obciążenia albo uruchomieniu w odmiennym środowisku), czy też wystarczy, jeżeli zmiana nie będzie zauważalna w typowym użyciu.
Narzucenie bardziej rygorystycznej interpretacji powodowało konieczność przeprowadzania dowodu poprawności, co w praktyce wykluczało efektywne refaktoryzowanie programów.
