! Hello world

Nawiązując do uznanej tradycji, rozpocznę od opisania jak nie napisałem Hello World w Java.

Zacznijmy od zaopatrzenia się w jakiś zacny formatter kodu, aby nasz wpis jakoś wyglądał. Wybierzmy jakiś ciekawy język, na przykład jakiś dialekt Lisp:

; Hello World in Scheme

(begin
(display "Hello R5RS")
(newline))

Jako osoba trochę związana ze światem Java, powinienem aktywnie przeciwdziałać zaszufladkowaniu jako programista jednego języka. Wybranie Scheme jest, zatem, na miejscu.

Trochę to kolorowanie nie do końca działa. Można by rozszerzyć narzędzie, tak by realizowało pożądaną funkcję. W końcu każdy ma nieograniczony czas na pisanie bloga. Prawda 🙂

Zresztą brak wsparcia dla wybranego języka to tylko wyjątek potwierdzający regułę. Większość narzędzi, bibliotek i frameworków tak wspaniale ze sobą współpracuje i jest tak łatwa do integracji.

Tylko, czy wybór zakresu funkcjonalności oferowanych przez program zadowoli potencjalnego czytelnika? Większość programistów nie przeczyta dużo więcej niż drugi rozdział Scheme in Fixnum, więc logiki nie ma co rozbudowywać.

Żeby rozwiać wątpliwości dorzucę jeszcze skrypt w Ruby:

print "Yo"

W każdym poście o IT musi być coś w języku funkcyjnym. TIOBE szacuje ich udział na dobre 4%! Weźmy dla przykładu, wspominany czasami na InfoQ, Erlang:

-module(hello).
-export([do_magic/0]).

do_magic() -> 
   do_magic("Hello .... world?").

do_magic([]) -> 
   io:format("~n", []);
do_magic( [H|R] ) -> 
   io:format("~c", [H]),
   do_magic(R).

OK. Skoro już nie napisałem Hello World w Java, to mogę jeszcze nie napisać Hello World w Java.

Oczywiście trzeba zacząć od najważniejszego czyli dokumentacji pełnej diagramów UML: czytelnych i przewidujących wszystko łącznie z problemami kompilacji i hakami wymaganymi do zaimplementowana śmiałej i eleganckiej wizji projektanta 🙂 W końcu funkcjonalności są oczywiste i nie ma co robić analizy wymagań. Prawda.

Zresztą każde narzędzie CASE oferuje własny, idealnie zoptymalizowany i dostosowany do potrzeb absolutnie każdego użytkownika interfejs. Dzięki szczegółowej i wyczerpującej dokumentacji, każdy projektant będzie mógł, jeszcze przed zakończeniem licencji, odnaleźć obszerne, dogodnie rozbite na wiele różnych sekcjach informacje. Więc po co rysować diagramy na tablicy czy kartce papieru?

Skoro mamy już świetny projekt, napiszmy automatyczny test:

@Test public void shouldPrintHelloWorld() {
   // given

   // when
   HelloWorld.say( "Hello World" );

   // then
   // TODO
}

Tylko jak sprawdzić czy jest wyświetlony napis … gdyby tak zastąpić to statyczne pole (System.out) jakimś mockiem … ale final. Hmmm …. to może przeciążyć say i … ale static. Może odpalić osobny JVM i tam za pomocą podmieniania bytecodu …. Można by rozwiązanie trochę zmienić … tylko że projekt już zakończony …

Syndrom naruszenia zasad pisania nadającego się do testowania kodu? Może to czerpanie pełnymi garściami z klasycznych rozwiązań nie jest pozbawione wad? Już wiem! Test zdecydowanie jest zbyt integracyjny, wystarczy tylko pominąć te niepotrzebne operacje IO:

@Test public void shouldPrintHelloWorld() {
   // given

   // when
   // HelloWorld.main( "Hello World" ); optymalizacja 

   // then
}

Test pięknie przechodzi, więc nie trzeba nic więcej robić. Prawda?
Że nie wspomną o wspaniałej optymalizacji wykonanej bez konieczności porównywania czasu i szukania wąskich gardeł. Czyż można temu coś zarzucić?

Tak oto, udało mi się nie napisać Hello World w Java 🙂