Testivus – kompletne starożytne nauki na temat testowania

Moje motto na temat Unit Testów i wielu innych rzeczy:

Less Unit Testing Dogma
More Unit Testing Karma

Nie ma co pisać wstępów, trzeba przeczytać krótkiego i zwięzłego PDFa The Way of Testivus

Good advice on developer and unit testing, packaged
as twelve cryptic bits of ancient Eastern wisdom.

Testivus Unit Testing

Mnie to olśniło, rzadko zdarza się dorwać coś, co jest tak fajnie przygotowane i aż się prosi o wydrukowanie.

Podzieliłem się moim odkryciem tak, że wydrukowałem w kolorze (dzięki Sylwia Lasek 🙂 ), zbindowałem i rozdałem osobom zainteresowanym tematem aby je zainspirować.

Trafiłem na Testivusa szukająć przykładów dlaczego pułap Code Coverage nie powinien być żadnym celem. Na SO znalazłem wytłumaczenie What is a reasonable code coverage % for unit tests (and why)?

Reklamy
Opublikowano Programowanie | Otagowano , , , | 1 komentarz

Static – dobry, zły i brzydki

Prywatne pola static – są bardzo NIE OK.
Metody static – są OK.

I o ile jest generalnie zgoda, że nie powinno się używać static w polach to chciałem pokazać, że metody będące statyczne są dobre. Czy powinny być statyczne to zależy od kontekstu. Ja stosuję to tak, że kiedy mogę to staram się przekazać argumenty i uczynić metodę statyczną. Przykłady takich metod z mojego kodu:

Przypadki, gdy zdarzają się publiczne właściwości:

  • ServiceLocator – generalnie antypattern, ale czasem inaczej się nie da i gdy wiem co robię to pozwalam sobie na to.
  • Puste obiekty, gdy sa immutable i mogą być reużywane, przykład EventArgs:
  • … (można dodać w komentarzach)

Przypadki, gdy można uniknąć statycznych publicznych właściwości:

  • Singleton => można rejestrować jako „AsSingleton” w kontenerze IoC.
  • Jest klasa (serwis), która ma stan, i takich instancji jest wiele w aplikacji. Dodatkowo potrzebuje dostęp do jakiejś statycznej kolekcji. Najprościej jest utworzyć jedno pole static, którego będą reużywać wszystkie instancje. Nie robiłbym tak, lepiej to coś co wydaje się być statyczne wydzielić do innego bytu i przekazać jako zależność, a w kontenerze zarejestrować jako AsSingleton (punkt wyżej).
Opublikowano Programowanie | Otagowano , , , | 3 Komentarze

Przyspieszone słuchanie podcastów i konferencji

play youtube faster

Czy oglądając video z konferencji nie nudzicie się czasem? Może za wolno? Zdecydowanie tak. Kiedykolwiek to pokazuję to każdy się zgadza, że można przyspieszyć.

Np. w youtube w prawym dolnym rogu klikamy Settings->Speed i dostaniemy wybór jak po prawej.

W Windows Media Player klikamy PPM->Enhancements->”Play speed settings”:

play windows media player faster

Oraz mój ulubiony (na androidzie), czyli prosty Music Speed Changer (to był jedyny który ściągnąłem, chętnie posłucham gdy są lepsze):

Android Music Speed Changer

Zyski

Ja oszczędzam w ten sposób bardzo dużo czasu. Gdy chodzi o podcasty to słucham na ok 140%. Gdy czasem ktoś mówi zbyt szybko to zmniejszam do 130%. W ten bardzo prosty sposób w 30 minut wchłaniam wiedzę z 40 minut.

Opublikowano Tip of the day | Otagowano , , , | 4 Komentarze

Dobra muza do kodowania

Wiadomo jest to bardzo subiektywne. Wracam jednak często po podobne bity, więc tak bardziej dla siebie wrzuciłem wreszcie na bloga.

Niech się stanie FLOW

i kolejne części „Concentration \ Programming Music”

Pomodoro

Polecam równocześnie technikę pomodoro i ustawianie czasu na 25minut pracy, 5minut przerwy. Mój programik to http://e.ggtimer.com/pomodoro

Opublikowano Tip of the day | Otagowano , | 1 komentarz

Okazjonalne (regularne) czyszczenie kodu Resharperem

Powiedzmy, że mamy projekt, w którym wcześniej nie znano Resharpera. Otwierając taki kod „wszystko świeci” na różne kolory sugerując, że mamy w kodzie wiele problemów. Moje doświadczenie programistyczne mówi mi, że warto wysprzątać te miejsca, ponieważ na wstępnie z automatu poprawi się nam wiele bugów i znacznie zwiększy czytelność.

cleanup code in resharper

I tutaj staje się przed problemem czy poprawiać wszystko? Czy tylko ważne rzeczy? Czy też przy okazji te automatyczne poprzez Alt+Enter?

Kiedyś przerobiłem cały kod w solucji za pomocą opcji „Cleanup Code” (PPM na projekcie/solucji/katalogu).

cleanup code in resharper

Na początku żeby zacząć utworzyłem nowy profil, nazwałem go „just remove unused references”, i jak widać na obrazku robi to oraz dodatkowo sortuje. Jest to „bezpieczny” niewymagający naszej ingerencji refactoring. Dzięki niemu gdy będziemy już z głową refaktorować kod (usuwać duplikacje, zmieniać strukture itp, itd) nie będziemy się rozpraszać rzeczami, które może poprawić za nas automat.

Warto też od czasu do czasu jeszcze raz przerobić tym automatem cały kod w solution, ponieważ takie rzeczy (jeśli inne osoby o to nie dbają) regularnie zaśmiecają projekty.

Muszę kiedyś napisać o podejściu „Resharper green”, może to rzuci trochę więcej światła.

Opublikowano Programowanie, Tip of the day | Otagowano , , | 5 Komentarzy

Jak nie dać się zwariować napływowi informacji

Angielski tytuł brzmiałby „It’s not what you read, it’s what you ignore” bo jest on tytułem znakomitego wystąpienia Scotta Hanselmana:

Od siebie mogę dodać kilka rzeczy, które robię:

  • Email prywatny w pracy jest w nieużywanej przeglądarce, więc prawdopodobieństwo jego przypadkowego przeglądania jest bardzo niskie.
  • Wyłączenie powiadomień mailowych na komórce (zarówno głosowych jak i wizualnych).
  • W pracy na stałe włączony jest tylko Slack projektowy.
  • Wyłączenie powiadomień Slackowych na komórce (tylko głosowe, wizualne zostały).

Dwa powyższe punkty (o emailach) sprawiły, że na dzień dzisiejszy mam +1000 nieodebranych emaili… i bardzo dobrze mi z tym 🙂 Oznacza to, że pewnie te rzeczy nie były tak ważne. Zysk z tego taki, że nic mnie w ciągu dnia nie pinguje i nie odrywa z tego co akurat robię – BEZCENNY. Z drugiej strony kiedyś już w 90% napisałem posta o Inbox Zero, bo to też jest fajne i chciałbym do tego wrócić. Na obecna chwilę nie chcę jednak zaprzątać sobie głowy zadaniem sprzątania skrzynki. Najważniejsze rzeczy mają odpowiednie priorytety i się dzieją.

Do przemyślenia w najbliższym czasie jest czy nie zrobić sobie kilku godzin w ciągu dnia z wyłączonym Outlookiem. Już tak kiedyś pracowałem – czasem trzeba wrócić z powrotem do dobrych, ale zapomnianych praktyk.

A jakie są wasze productivity tips?

Opublikowano Tip of the day | Otagowano , , , , | 1 komentarz

Code Review a spacje i inne pierdoły

Chodzi o taką sprawę:

couple random spaces in Code Review

Te ciemno zielone to kilka dodatkowych spacji, które się pojawiło (a nie było ich wcześniej). Inne to: dodatkowo zbędna, podwójna linia, brak pustej linii, brak spacji w parametrach lub zbyt duża ich liczba, itp, itd.

Przypadkowo podczas pracy nad kodem gdzieś się pojawiło kilka spacji za dużo lub za mało. Czy chcielibyśmy przypieprzać się do takich rzeczy na Code Review? – nie bardzo, są ciekawsze rzeczy do kminienia. Jak unikać takich przeszkadzajek:

  • Formatować kod przed commitem, a najlepiej na bieżąco, skrót Ctrl+K, Ctrl+D.
  • Jeśli powyższego nie możemy zrobić, bo ogólnie cały kod jest syfiasty gdy chodzi o wcięcia/formatowanie to możemy formatować tylko kod, który dodaliśmy. Zaznaczamy kod i skrót Ctrl+K, Ctrl+F. To akurat robię rzadko.
  • Jeśli już nie możemy (albo nie chcemy) korzystać z automatycznego formatowania to przed pushowaniem do centralnego repozytorium powinniśmy oczyścić commity z takich przeszkadzajem (git rebase interactive).
  • Już naprawdę w ostateczności gdy nic z powyższych nie podziałało to podczas tworzenia pull requesta (obszerny opis o co w tym biega na przykładzie Git/BitBucketa) zobaczmy wszystkie nasze zmiany. Na tym etapie wyłapiemy te pierdoły, na które będzie tracił czas każdy robiący Code Review (a czasem jest to kilka osób, których czas byśmy zmarnowali).

Innym podejściem jest włączeniem do projektu StyleCopa. Dzięki temu wymusimy pewne standardy formatowania, czyli brudną robotę odwali za nas narzędzie.

Opublikowano Programowanie | Otagowano , , , | Dodaj komentarz