Porównanie C5 z System.Collections.Generic

Jestem po lektorze książki ".NET 4.0 Generics" napisanej przez Sudipta Mukherjee (wcześniej na jego stronie można było ściągnąć całą książkę). Najbardziej cenie tą książkę za przedstawienie wyników szybkości działania różnych typów kolekcji. Autor porównuje typy, które znajdują się w bibliotece C5 oraz w System.Collections.Generic. O bibliotece C5 już wcześniej pisałem. Chciałbym przedstawić zdjęcia z wynikami z tej książki.

Eksperyment nr 1:
Ile czasu potrzeba, aby sprawdzić czy element w liście istnieje.

Eksperyment nr 2:
Ile czasu potrzeba, aby znaleźć pierwsze wystąpienie elementu w liście.


Eksperyment nr 3:
Ile czasu potrzeba, aby znaleźć ostatnio występujący element w liście


Eksperyment nr 4:
Ile czasu potrzeba, aby dodać element w losowym miejscu w liście


Eksperyment nr 5:
Ile czasu potrzeba, aby usunąć pojedynczy element w losowym miejscu w liście


Eksperyment nr 6:
Ile czasu potrzeba, aby uzyskać dostęp do elementu w kolekcji asocjacyjnej (Dictionary, SortedDictionary, C5.HashDictionary, C5.TreeDictionary)


Eksperyment nr 7:
Ile czasu potrzeba, aby znaleźć unie dwóch zbiorów


Eksperyment nr 8:
Ile czasu potrzeba, aby sprawdzić czy jeden zbiór zawiera się w drugim zbiorze


Kod źródłowy dla tych testów można było pobrać stąd. Mam nadzieję, że Sudipta reaktywuje swoją stronę.

Kiedy pisać Unit Test?

TDD jest bardzo popularnym podejściem do pisania kodu. Najpierw piszesz test sprawdzający funkcjonalność, który nie przechodzi, później implementujesz ta funkcjonalność, aby ten test mógł przejść, a na końcu refaktorujesz kod i od nowa zaczynasz pisać kolejny test.

Dużo jest przeciwników TDD, gdyż uznaje się, że TDD jest zbyt wolny, nie nadaje się do małych zmian i nie ma czasu na 'ekperymentowanie' z TDD. Nie jestem w tym ekspertem, ale jedno wiem. Pisanie kodu produkcyjnego z TDD nie jest wolniejsze od samego pisania kodu, ale pisanie kodu eksperymentalnego z TDD jest wolniejsze od samego pisania kodu. Jest to najprostszy argument, przeciwko TDD.

Innym podejściem do pisania testów jest zasada Test-First. Kiedyś byłem, na praktyce w zagranicznej firmie, w której dwóch doświadczonych programistów pisało kod z takim podejściem. Jedna osoba pisała testy, a druga osoba implementowała te testy. Wszystko ok, ale bardzo często implementator kodu przychodził do twórcy testów, aby zmienić testy - w trakcie rozwoju aplikacji funkcjonalność się zmieniała jak i pomysły rozwiązania problemów. Test-First bardzo dobrze uzupełnia się z TDD, gdyż jedna osoba (na ogół jest to architekt) pisze podstawowe testy (kontrakty), a implementator kodu dodaje bardziej szczegółowe testy.

Ale, skoro TDD zawiera bardzo dużo czasu, a testy pisane metoda Test-First są często zmieniane to może pisać testy metoda Test-After? Minusem Test-After jest to, że bardzo trudno jest uzyskać wysokie pokrycie kodu. Mamy wtedy wewnętrzną potrzebę, aby zmienić coś w kodzie, aby łatwiej można było napisać test, nie mając przy tym gwarancji, że po zmianie wszystko będzie działało. Na dodatek nigdy nie ma czasu na testy i wszyscy mówią (managery), że po ważniejszych zmianach będzie można przetestować funkcjonalność. Oczywiście po tych zmianach nie mamy pewności czy wszystko działa tak jak wcześniej działało.

Może pisanie testów nie powinno być z góry określone, kiedy należy pisać. Może wystarczą testy, kiedy mamy taką potrzebę - Test-Whenever. Coś takiego jak zasada 80-20. 20% testów sprawdza 80% funkcjonalność. Niektóra funkcjonalność nie potrzebuje testów, a przy kodzie, gdzie mniej bezpieczniej się czujemy to możemy napisać więcej testów. I ta metoda ma swoją wadę. Zawsze jak zaczynam pisać nowy kod to mam wrażenie jakby wszystko było czytelne, oczywiste, proste i wszyscy powinni zrozumieć co kod robi, ale jak po roku wracam do swojego kodu to klnę na autora tego spaghetti kodu :)

Może testy nie powinny wyjść z potrzeby autora code, ale od osoby, która robi code review.

Dylematy z pisaniem testów jest bardzo dużo. Każda metoda ma swoich zwolenników i przeciwników. Może lepiej będzie zastosować metodę Test-Never?

Spotkania z "Brown Bag"

Brown Bag to potoczna nazwa opakowania na lunch.



Brown bag seminar to szkolenia albo sesja informacyjna o rzeczach związanych z pracą zorganizowana podczas obiadu. Seminarium ma taki minus, że jest to spotkanie, które trwa koło godziny.
Brows Bag Meetings to spotkania, gdzie dowolna osoba może przedstawiać ważne informacje w ciągu trwania luncha (w praktyce 15 minut).



Dużym plusem takich spotkań jest transfer informacji wśród ludzi pracujących w firmie. Czasami tak jest, że 2 sąsiednie zespoły w obrębie jednej firmy nic o sobie nie widzą. Bardzo podobnie jest z scrum meetings, gdzie każda osoba w zespole wie co robi inna osoba, ale w firmie mamy kilka projektów, to zwyczajny pracownik nie ma bezpośredniej możliwości dowiedzenia się co dzieje się w innych projektach. Oczywiście jest Scrum of Scrums Meeting, ale na tych spotkaniach jest transfer informacji na wyższym szczeblu. Brown Bag Meetings daje możliwość wszystkim pracownikom udziału w życiu firmy.

Architekt jest jak ogrodnik

Bardzo mi się podoba metafora "architekt jest jak ogrodnik". Ogrodnik powinien pielęgnować ogród. Architekt powinien pielęgnować architekturę.

Problem może pojawić się, kiedy mamy architekta, który mówi, że wszystko jest ok, nie trzeba modernizować starego systemu, manualne czynności nie muszą być zautomatyzowane, projekt działa wystarczająco szybko, nie jest potrzebna reużywalność i tak dalej... To tak samo by było, gdyby ogrodnik nie chciałby wyciąć drzewa, które zagraża życiu ludzkiemu, przesadzić suche i brzydkie kwiatki czy podciąć zarośnięty żywopłot i nie dba o dróżki prowadzące przez ogród.

Z drugiej strony mamy architekta, który od nowa chce stworzyć system, zastosuje technologie jakie są teraz modne, a stary system z przyjemnością by usunął. Tak samo jest z ogrodnikiem, który chce wyciąć wszystko i od nowa posadzić nowe roślinki (oczywiście ogrodnik ten nie zna do końca wymagań wszystkich rośliny). Można zrobić fantastyczne ogrody tak jak labirynt znajdujący się w Kurozwękach czy ogród Herrenhäuser w Hannoverze, ale koszt utrzymania takiego ogrodu jest bardzo duży.


Pamiętaj, "architekt jest jak ogrodnik, pielęgnuje architekturę systemu".

Zapomniane C5

C5 oznacza Copenhagen Comprehensive Collecton Classes for C# i jest to biblioteka składająca się z generycznych kolekcji. C5 daje Ci większą kontrolę nad selekcja danych w kolekcjach. Programista może zdecydować czy chce mieć kolekcje zaimplementowana na funkcji haszującej (hash-based), drzewa (tree-based), tablicy (array-based) czy na LinkedList-based.


Mimo tego, że C5 ma duże zastosowanie w problemach wydajnościowych, mam wrażenie jakby biblioteka nie była popularna i projekty nieakademickie nie chcą korzystać z niej.

Najlepsze praktyki dla System.Collections.Generic

Krótko chciałem napisać 13 najlepszych praktyk przy używaniu generycznych kolekcji.

1) Nie używaj generyków jeżeli wiesz, że nie potrzebujesz
2) Używaj Stack<T> do implementacji list LIFO
3) Używaj Queue<T> do implementacji list FIFO
4) Używaj List<T> do implementacji listy z losowym dostępem do danych
5) Używaj LinkedList<T> jeżeli potrzebujesz dodawanie lub usuwanie elementów na brzegach listy
6) Używaj HashSet<T> jeżeli lista nie ma duplikatów lub potrzebujesz szybki zbiór danych
7) Używaj foreach na kolekcji kluczy zamiast używać pętli for po IDictionary<TKey,TValue>
8) Nie używaj metody ElementAt() czy ElementAtOrDefault()
9) Używaj dedykowanej klasy zamiast Tupli z dużą ilością parametrów.
10) Używaj SortedDictionary<TKey,TValue> jeżeli potrzebujesz mieć posortowane elementy
11) Używaj SortedSet<T> jeżeli potrzebujesz posortowany zbiór danych
12) Używaj KeyValuePair<TKey,TValue> zamiast Tuple<T1,T2>
13) Jeżeli implementujesz po interfejsie IEnumerable<T> to również zaimplementuj IEnumerable(z powodu wstecznej kompatybilności)

Wykład Jacka Walkiewicza z pełną mocą

Dzisiaj widziałem prezentacje Jacka Walkiewicza. Wykład był o spełnianiu marzeń, strefie komfortu i ufaniu sobie.




Wywiad z Panem Jackiem można przeczytać na tej stronie. Jest też jeszcze drugi filmik. Bardzo polecam obejrzenie tych TED prezentacji.