Przedwczesna optymalizacja

Pojęcie przedwczesnej optymalizacji … zastanowienie się nad tym ;).

Uderzyło mnie to przy próbie pisania w pl/sql. Poczułem się w tym na tyle swobodnie, że zacząłem tworzyć już z myślą o wydajności, wtedy kiedy jeszcze głównych założeń algorytmu nie miałem do końca uchwyconych. I straciłem pół dnia na roztrząsanie technicznych szczegółów (i to jeszcze na siłę próbowałem zrobić to sam, gdy mogłem zapytać o pomoc).
Zbyt szybko chciałem iść na skróty, kiedy musiałem poruszać się po omacku.
Lepiej jest więc napisać coś co już na starcie nie musi być optymalne, aby mieć przynajmniej pewność, że działa. Najpierw niech działa (zostanie zrozumiałe), potem może być udoskonalanie.

To znaczy: podążanie za przeczuciem do idealnego rozwiązania jest dobre kiedy umiesz się poruszać sprawnie w danym środowisku. W innym wypadku lepiej jest uważać na każdy krok (nie pomijać go). I liczy się z tym, że w pierwszej kolejności stwierdzenie „działa”, jest głównym wyznacznikiem tego że zmierzamy do celu.

Poszukiwanie narzedzia

Na początku była potrzeba tworzenia dokumentacji, zostało to opisane tutaj. Miało to jednak dalszą kontynuacje.

Wraz z przejściem do projektu (trwał on już od jakiegoś czasu) stanąłem przed wyzwaniem zapoznania się z bazą danych (jedną z wielu). Dokładniej miałem do rozpoznania jej wycinek, aby przygotować kilka zapytania. I tu okazało się, że to co kiedyś stworzyłem w innym projekcie na potrzeby klienta/administratora może być teraz pomocne dla mnie. Było to sposób produkcji dokumentu przedstawiającego relacje pomiędzy tabelami w bazie. W zamierzeniu miała to być pomoc do zaznajomienia się z baza, w sam raz na początek, gdy obraz jej nie jest jeszcze utrwalony w głowie.

Link – software craftsmanship

Link na który trafiłem podczas przerwy (obijania się) w pracy.
Jest to o coraz bardziej modnym słowie „software craftsmanship”.

Mam opory do wygłaszania tu jakichś ostrych opinii, nie wiem czy w ogóle jest potrzeba.
Zostawiam ślad w postaci tego linku i paru szybkich wrażeń, może ciekawie będzie spojrzeć na to za jakiś czas.

W wywiadzie podobało mi się to: Jeśli w danym momencie nie wyrabiasz się, nie masz czasu, czy zdolności, aby pracować w taki sposób jaki byś chciał (na poziomie jaki byś chciał), to OK!. Świat się nie wali. Rejestrujesz ten fakt i w przyszłości, kiedy czas pozwoli starasz się spróbować znaleźć sposób, aby móc zbliżyć się choć trochę bardziej do tego poziomu.
Jest to wola postarania się, aby znaleźć sposób na zmniejszenie tej przestrzenie jaka jest pomiędzy stanem obecnym, a tym jaki chciałbyś osiągnąć. I nie chodzi o to, żeby następnym razem zrobić coś doskonale. Sukcesem będzie już to, jeśli będzie to choć odrobinę lepiej zrobione niż poprzednim razem.

I na koniec hasło przewodnie: zdobycie umiejętności trwa ;).

Refleksja o/w testach

Używanie refleksji w normalnym/produkcyjnym kodzie może wydawać się: dziwne, wprowadzające komplikacje, czy zbyt duże obciążenie (zamieszanie), niekoszerne … Warto jednak zapoznać się z paroma sztuczkami, aby ułatwić sobie czasami testowanie.

Dzięki refleksji można zbudować proste narzędzia przydatne przy:
– wstrzykiwaniu zależności (ustawianie wartości), kiedy w normalny sposób nie można tego zrobić;
– pobieraniu wartości (tak samo jak wyżej, kiedy nie ma mechanizmu do tego).
Można powiedzieć, że zawsze da się sprawić, żeby to co nie jest dostępne było dostępne. Jednak jeśli jest to robione tylko na potrzeby testu, to może się wydawać zbyteczne (kod służący tylko do testowania jest w kodzie produkcyjnym, coś jak). Tu argumentem za jest także przypadek gdy pracujemy na kodzie, którego po prostu nie możemy zmienić.

Dlatego mechanizm operujący na obiektach danej klasy, a nie kod wewnątrz tej klasy, może być użyteczny.
W podstawowej wersji może sprowadzać się to do dwóch metod (szczegóły tego jak to zostało zaimplementowane tutaj):

	public static void setFiledValue(Object target, String filedNmae, Object value){
		...
	}
	
	public static Object getFiledValue(Object target, String filedNmae){
		...
	}

Gdzie to można użyć?
Wstrzykiwania zależności, np. do testowania EJB, gdzie mam wiele pól, które mają być ustawione przez kontener. Oczywiście można zawsze dostarczyć to bez takiego mechanizmu – użycie setterów lub stworzenie odpowiednich konstruktorów ;).

Pobieranie wartości, których normalnie nie da się pobrać. To jest przydatne w weryfikacji: czy to co miało się wykonać, wykonało się poprawnie i czy odpowiedni stan został ustawiony.
W ostatnim przypadku, także pewnie można znaleźć zamiennik.

Zawsze można powiedzieć, że gdzieś tam jest wspaniała biblioteka lub technika tworzenia kodu, która uwolni nas od takich problemów. Niemniej świadomość, że można tak robić, może być kolejnym sposobem na ugryzienie problemu lub przynajmniej wskazania rozwiązania dla niego ;).

Manipulowanie obiektem poprzez refleksje

Jest to opis tworzenia kodu/narzędzia. Jego główny cel to odczytywanie i manipulowanie stanem obiektu w sytuacji kiedy on sam nie udostępnia takich metod. Kod taki zdarzało mi się głównie stosować/używać w testach (większy opis o tym w następnym poście).
Do realizacji tej funkcjonalności jest użyta refleksja, co w podstawowej wersji wygląda tak:

	public static void setFiledValue(Object target, String filedName, Object value) {
		try {
			Field field = getFiled(target.getClass(), filedName);
			field.set(target, value);
		} catch (Exception e) {
			throw new RuntimeException("Exception in setFiledValue for: " + filedName, e);
		}
	}

	public static Object getFiledValue(Object target, String filedName) {
		try {
			Field field = getFiled(target.getClass(), filedName);
			Object object = field.get(target);
			return object;
		} catch (Exception e) {
			throw new RuntimeException("Exception in getFiledValue for: " + filedName, e);
		}
	}

	private static Field getFiled(Class<? extends Object> clazz, String filedName) {
		try {
			Field field = clazz.getDeclaredField(filedName);
			field.setAccessible(true);
			return field;
		} catch (Exception e) {
			throw new RuntimeException("Exception in getFiled for: "  + filedName, e);
		} 
	}