Krzysztof Kędziorski - Notatnik programisty

Oj długo nic nie pisałem na blogu…

Jestem właśnie w trakcie lektury książki “Pragmatyczny programista od czeladnika do mistrza” A Hunt, D. Thomas (link). W podrozdziale “Refaktoryzacja” znalazłem świetne porównanie projektów programistycznych do otaczającego nas świata.

“Oprogramowanie przypomina bardziej ogród niż tradycyjny plac budowy - więcej tam elementów organicznych niż betonu. Sadzimy w naszym ogrodzie wiele roślin zgodnie z początkowym planem i panującymi warunkami. Część roślin szczególnie dobrze rozwija się w towarzystwie innych gatunków, które nie zasłaniają światła lub - wprost przeciwnie - zapewniają cień oraz osłonę przed wiatrem i deszczem. Przerośnięte rośliny są przycinane, a rośliny, których kolory odbiegają od projektowanego zabarwienia całości, trafiają w inne, bardziej odosobnione miejsca. Wyrywamy chwasty i nawozimy rośliny, które wymagają dodatkowej opieki. Stale monitorujemy zdrowie całego ogrodu, wprowadzając na bieżąco niezbędne poprawki (w glebie, w samych roślinach i w całym projekcie).”

W mojej ocenie wydaje się idealnie oddawać naturę projektu.

OK. Właśnie skończyłem czytać książkę Mariusza Lipińskiego “Przygotowanie do certyfikacji SCJP 6″. Cóż mogę powiedzieć ? Książka objętościowo niewielka jednak w zasadzie nie ma strony która nie byłaby koncentratem wiedzy.  Autor zdecydował się pominąć całe te lanie wody, długie opisy itp występujące w innych książkach  i skupił się tylko na zagadnieniach niezbędnych do znania egzaminu SCJP 6. Książkę czyta się raczej ciężko ze względu właśnie na ten ogrom informacji zawartych na raptem 210 stronach. Ale to w dużej mierze zasługa samego SCJP, który jest egzaminem sprawdzającym znajomość różnych kruczków Javy i są to czasem zagadnienia ciężkie do zapamiętania - bo raczej niepraktyczne. Niemniej dowiedziałem się z tej książki kilku informacji które mogą się przydać również w prawdziwym życiu programisty - co tylko pokazuje, że jeszcze muszę się trochę pouczyć :) Książkę oceniłbym w mojej subiektywnej skali na 8 z 10 pkt.

Zanim podejdę do egzaminu planuję przeczytać ją raz jeszcze - w końcu to tylko 210 stron :) A na pewno podniesie to mój wynik.

W zeszłym tygodniu skończyłem czytać książkę “Head First Design Patterns”. Wg mnie książka jak najbardziej godna polecenia. Każdy wzorzec został dokładnie opisany w charakterystyczny dla serii Head First lekki sposób. Autorzy przedstawiają nam kolejne wzorce poprzez przykłady. Stawiając przykładowym aplikacjom kolejne wymagania refaktoryzują kod aby korzystał z określonego wzorca argumentując swoją decyzję i wskazując możliwe skutki uboczne. Książkę czyta się lekko - czasem nawet zbyt lekko. Jeśli miałbym cokolwiek zmienić byłaby to objętość - 650 stron to trochę za dużo - jednak mam świadomość ,że odbyłoby się to kosztem lekkości czytania. W mojej subiektywnej ocenie książka otrzymuje 9 na 10 punktów.

Teraz zabieram się za czytanie książki Mariusza Lipińskiego “Przygotowanie do certyfikacji SCJP 6″

Jutro (tj. 13 września - tj. 256 dnia roku) Dzień Programisty. Takiego newsa sprezentował mi dziś Helion na maila.

Jutro z tej okazji możemy kupić książki z Helionu z 20% zniżką.

Szkoda, że Dzień Programisty nie jest zbyt popularny ;] może wtedy ktoś sprezentowałby mi niespodziewanie jakąś książeczkę …

Jak już pisałem w poprzednim poście jestem w trakcie czytania książki Czysty Kod. Podręcznik dobrego programisty. Pomyślałem sobie, że w trakcie czytania będę starał się wypisywać zawarte tam rady. Efektem tychże notatek będzie właśnie ten wpis. Mam nadzieję, że komuś taki spis dobrych zasad w pigułce się przyda. A ja będę miał go w jednym miejscu :)

Zdecydowałem się na wypisywanie porad zgodnie z rozdziałami książki.

1. Znaczące nazwy:

• nazwy przedstawiające intencję
• unikanie dezinformacji
• wymawialne nazwy
• nazwy łatwe do wyszukania

2. Funkcje:

• możliwie jak najkrótsze (max 20 wierszy)
• najlepiej bez lub jedno argumentowe
• pojedyncza odpowiedzialność
• jeden poziom abstrakcji
• bloki try{} catch{} w osobnej funkcji

3. Komentarze:

• jak najmniej (samo komentujący się kod)
• dozwolone komentarze:
  • komentarz z rodzajem licencji
  • TODO
  • komentarze ostrzegające
• nie komentujmy na siłę
• nie zostawiajmy za komentowanych fragmentów kodu

4. Formatowanie:

• małe pliki (klasy) są lepsze niż duże
• u góry klas najogólniejsze metody poniżej coraz bardziej szczegółowe
• pionowe odstępy między segmentami kodu
• funkcja wywoływana zaraz pod funkcją wywołującą
• wiersze maksymalnie 120 znakowe
• spacje wokół operatorów
• wcięcia poziome oddzielające bloki kodu
• spójne formatowanie w całym zespole

5. Obiekty i struktury danych:

• NIE dodawać na ślepo setterów i getterów
• przestrzegajmy prawa Demeter
• unikanie “wraków pociągów”, czyli kodu postaci: a.getB().getC().getD().getZ().doSth();
• unikać hybryd (trochę obiekt, trochę struktura danych)

6. Obsługa błędów:

• wyjątki zamiast kodów powrotu
• NIE zwracamy null
• NIE przekazujemy null
• tworzenie komunikatów błędów z informacją o typie awarii i co miało się wykonać oraz przesłanie ich w wyjątku

7. Granice:

• separacja obcego kodu od naszego
• testy “uczące” obcego kodu
• wzorzec Adapter

8. Testy jednostkowe:

• kod testów jest tak samo ważny jak kod produkcyjny
• czytelność testów
• w testach nie jest tak istotna wydajność
• jedna asercja na test - niekoniecznie
• jedna koncepcja na test
• testy powinny spełniać zasady F.I.R.S.T.
  • Fast - szybkie
  • Independent - niezależne
  • Repeatable - powtarzalne
  • Self-Validating - samo kontrolujące się
  • Timely - o czasie

9. Klasy:

• organizacja klas (od góry):
  • publiczne stałe statyczne
  • prywatne zmienne statyczne
  • prywatne zmienne instancyjne
  • publiczne metody
  • prywatne metody
• klasy powinny być małe
• pojedyncza odpowiedzialność (SRP)
• niewiele zmiennych instancyjnych
• zachowanie dużej spójności