wtorek, 28 czerwca 2011

Logika + intuicja = inteligencja ?

Rzadko mi się to zdarza, ale czasem trzeba usiąść i przewartościować to i owo w swoim życiu. Bez obaw, nie będzie to tekst o uczuciach, związkach i innych takich:) Będzie o sposobie myślenia, przyswajania wiedzy i to niekoniecznie w stricte programistycznym kontekście.

Czy zdarzyło Ci się kiedyś, że poświeciłeś 2/3 dni na jakiś problem, zadanie - bez większych rezultatów, a nagle (czasami nawet kilka dni później), nie wiadomo skąd - oświecenie - Twój mózg dostarcza rozwiązanie, praktycznie na talerzu. Ja miałem tak przy całkach, czasami potrafiłem zmarnować cały dzień na 1 całkę, żeby rano obudzić się i ją po prostu ładnie rozpisać. Jeśli chcesz wiedzieć skąd się to bierze, to koniecznie musisz przeczytać:


Tutył tcorhę nie ceikawy, ale jśeli ztsawnaaisz się delazcgo potarsfiz pzreyczatć ten tkest bez wikęzsyh porblmóew, to opdoeiwdź na m.in. to pyatine zanjzdisez w tej kąsicże.

Co do przewartościowania, to musiałem zmienić swój pogląd dotyczący wszelkich aktywności o naturze bardziej "artystycznej", które uważałem, do tej pory, za nieprzydatne i zbędne (przynajmniej dla mnie). Myślałem, że logika jest głównym silnikiem mojego mózgu. Co nie mija się mocno z prawdą, aczkolwiek każdy z nas ma drugi silnik - zupełnie nielogiczny i bardzo abstrakcyjny. Intuicja, instynkt (tak nazywany jest ten silnik) wydają się nie do końca potrzebne w przypadku np. programowania, ale tak de facto dopiero one pozwalają w pełni rozwinąć skrzydła (właściwie czymkolwiek byśmy się nie zajmowali). To właśnie silnik nr 2 pozwala obudzić się z rozwiązaną całką przed oczyma. Jego możliwości są praktycznie nieskończone jak i bardzo nieprzewidywalne. Ważne jest aby dbać i rozwijać oba silniki. Jak sugeruje autor książki, właśnie aktywności wywodzące się z szeroko rozumianej sztuki, rozwijają ten drugi silnik. Wątpię żebym nagle zaczął pisać wiersze, ale dostrzegam sens np. plastyki (i innych podobnych przedmiotów) w szkole, które (pomijając to, że były moim zdaniem po prostu źle prowadzone) mogą przydać się w ogólnym rozwoju.

Tak samo krytycznie nastawiony byłem do różnego rodzaju "niestandardowych" sposobów nauczania. Nie twierdze, że nagle wszystkie nabierają dla mnie sensu, ale cześć technik, ma swoje naukowe uzasadnienie i muszę przyznać, że chciałbym kilka z nich wypróbować. Mam nadzieję, że wystarczająco zaciekawiłem, aczkolwiek ciężko streścić książkę, która sama w sobie jest streszczeniem wielu prac i badań naukowych.

Dla tych bardziej leniwych, polecam wykład, który w dużej mierze pokrywa się z tą książką:
http://www.infoq.com/presentations/Developing-Expertise-Dave-Thomas

Wyjściowym źródłem informacji dla mnie był m.in. blog:
http://art-of-software.blogspot.com/2011/06/trawienie-confitury.html
http://art-of-software.blogspot.com/2010/01/wspinaczka-do-profesjonalizmu.html

wtorek, 21 czerwca 2011

Partial mock - stosować, czy nie?

Na samym początku chcę zaznaczyć, że prawdopodobnie ten post nie będzie udzielał jednoznacznej odpowiedzi, jego celem (przynajmniej na chwilę obecną) jest zebranie wszystkich za i przeciw stosowaniu częściowego mockowania.

Zakładam, że ewentualnemu czytelnikowi sama idea mockowania jest znana. Partial mock danego obiektu to taka hybryda prawdziwego obiektu i mocka, innymi słowy część metod danego obiektu może być zmockowana, a cześć działać normalnie. Więcej o tym:
Co to daje? Przede wszystkim ułatwia testowanie, czy raczej samo napisanie testu. Wyobraźmy sobie sytuację, w której dana klasa ma jedną publiczną metodę, która korzysta z 20 innych prywatnych, pozagnieżdżanych między sobą. Załóżmy, że te 20 metod tworzy spójną całość i wydzielanie ich do osobnych klas byłoby bezsensowne. Napisanie testu dla takiej publicznej metody jest zajęciem dość karkołomnym. Taki test, który np. sprawdzałby czy metoda 17 robi coś tam poprawnie, zawiera w sobie całą masę mocków i innych obiektów, które umożliwiają taki przepływ w kodzie klasy, aby dojść do tej metody 17 i ją przetestować. Zrozumienie takiego testu dla człowieka, który go nie pisał jest dramatem.

Czy nie lepiej napisać oddzielny test dla metody 17? A potem odpowiednio sprawdzić, czy metoda ta jest wywoływana w innej metodzie, właśnie za pomocą partial mockingu? Jak dla mnie takie podejście jest o wiele przejrzystsze.

Konserwatywni w dziedzinie testowania, na pewno już się gotują, że piszę o testowaniu metod prywatnych, ale powiedzmy, że zmieniam im dostęp na pakietowy:). Tak, czy inaczej na pewno nie pochwalą partial mocków, bo to podejście śmierdzi, jest "niekoszerne".

Ogólnie zgadzam się z nimi w jednej kwestii, na pewno konieczność zastosowanie partial mockingu do testów, jest bardzo wyraźnym sygnałem, że z naszym kodem jest coś nie tak i prawdopodobnie lepszym wyjściem będzie jego refaktoring.

Jednakże istnieją sytuacje (jak chociażby legacy code), gdzie partial mock jest nie dość, że wygodnym, to czytelnym rozwiązaniem.

Oczywiście nie jestem w dziedzinie testów aż takim ekspertem jakbym chciał, dlatego jeśli istnieją inne przesłanki za lub przeciw partial mockom, to proszę o komentarze.

Artykuły o partial mocking:
http://nathan.crause.name/entries/programming/partial-mocking-stubbing-and-why-it-s-not-evil
http://monkeyisland.pl/2009/01/13/subclass-and-override-vs-partial-mocking-vs-refactoring/
http://stackoverflow.com/questions/3806977/partial-mocking-as-code-smell