Firmowy Pet Project – czyli nauka przez zabawę

Ostatnio firmie dostałem zadanie przygotowania teamu do projektu, który właśnie rozpoczęliśmy. Długo się zastanawiałem jak to zrobić by zarówno osoby zapoznały się z środowiskiem pracy jak i z narzędziami.

Jako, że osoby biorące udział w projekcie są bardziej Junior Dev niż Dev a tym bardziej senior wpadłem na pomysł by w ciągu dwóch tygodni napisali mini projekt. Tak naprawdę prosty sam w sobie, i kiedy się wykorzystuje wbudowane narzędzia w VS w ciągu jednego dnia, maks dwóch można go napisać.

By jednak projekt miał ręce i nogi, poprosiłem ich o przetestowanie różnych narzędzi. Na przykład by pisząc testy zastanowili się nad nUnit, mbUnit, xUnit jak i MSpec i zobaczyli co im tak naprawdę leży a co nie.

Ogólnie chodziło o to, by pisząc na przykład testy zobaczyli jaki framework rozumieją, w którym jest im łatwiej pisać.

Podczas tych tygodni obserwowałem programistów i zauważyłem super ciekawą rzecz. Zaczęli oni między sobą dyskutować na temat tego, dlaczego uważają iż coś jest lepsze od innego. Na przykład w przykładzie testów padły takie informacje jak:

nUnit jest dość podobny do mbUnit, ogólnie jak już się bawiłeś jednym to nie ma sensu iść w drugi

xUnit jest dość ciekawy, prosty w obsłudze, ja nie kumam tych SetUp itp. a ty?

MSpec jest super prosty, rozumiem go jak język mówiony, jednak nie jestem przyzwyczajony do lambda expression i moim zdaniem tutaj może być kłopot ze zrozumieniem dla mnie kodu pisanego

Ich obserwacje naprawdę były ciekawe i trafne. Także zauważyłem iż dzięki temu się z żyli ze sobą. Dla przykładu, jedna osoba próbowała rozgryźć DI framework, kiedy inna bawiła się ORM. Ze względu na to, że dwa tygodnie nie były wystarczające na przetestowania wszystkiego przez wszystkich, zaczęli nieświadomie robić pair programming. Kiedy to jedna osoba pokazywała co i jak napisała i dlaczego tak a druga zaczynała coś sprawdzać na kodzie napisanym.

Dla mnie to było niesamowite przeżycie jako obserwatora, nigdy jeszcze z czymś takim się nie spotkałem i nabrałem dużego szacunku do ludzi z którymi pracuję. W Polsce raczej przeważnie spotykałem się z odpowiedzią a po co mam marnować czas, tutaj zaś programiści z chęcią zaczęli się uczyć nowych rzeczy.

Dużym plusem takiego projektu było to iż pod koniec analizy i zabawy, jak usiedliśmy do dyskusji na temat zbioru narzędzi które chcemy wykorzystać doszło do bardzo ciekawych dyskusji jak i wniosków.

Na przykład dlaczego wolą wykorzystać Fluent NHibernate a nie xml mapping, dlaczego TestDriven.NET im się nie podobał i wolą R#. Podobało mi się to iż wchodzili w dyskusję dlaczego nie wykorzystać LINQ 2 SQL czy też Entity Framework i o dziwo potrafili odpowiedzieć na część pytań sami sobie – podczas tych tygodni natrafili na kilka problemów, które albo wymagały kompletnej aktualizacji całego modelu EF co powodowało że ich custom mapping w XML znikał, albo natrafili na problem, którego rozwiązać nie mogli przeszukując googla. Zupełnie inaczej zaś mieli z NHibernate kiedy to jak coś im nie działało to potrafili to rozwiązać, zaczęli rozumieć jak to mniej więcej działa.

Rezultat takiego mini projektu jest niesamowity. Po pierwsze ludzie się ze sobą zżyli, po drugie zobaczyli jakie narzędzia są dostępne i co mogą im one dać, po trzecie opanowali podstawowe operacje na każdym z narzędzi, po czwarte opanowali trochę lepiej (nieświadomie) narzędzia które wybrali. Dzięki czemu start oficjalnego projektu przeszedł miękko i płynnie. Od razu było widać, że zespół wykorzystuje zdobytą wiedzę. Rozumie na czym polega Unit Test, jak z mapować encję, wykonać zapytanie na bazie danych. Jak stworzyć kontroler i widok w MVC i na jakiej zasadzie to działa.

To co było w tym całym procesie bardzo istotne, to to, że oni wybierają narzędzia, i oni decydują jak to chcą zrobić. Uważam, że to był klucz do sukcesu. Bo gdyby to było tak, że oni mają się bawić a ja potem i tak podejmę decyzję, to by się nie sprawdziło. Jedyną rzeczą jaką ja zrobiłem to przygotowałem listę narzędzi do przetestowania. Nie ograniczałem się do jednej, dwóch opcji, wręcz przeciwnie dawałem momentami po 5 możliwości. Chodziło o to, by programiści nie z fiksowali na jednym produkcie. Dodatkowo chodziło o to by pokazać im, że istnieją określone produkty na określone problemy – gdyż research ich mógłby im zająć dużo więcej czasu. Pozostawienie ich bez listy by było dość drastyczne, prawie jak pytanie na interview wymień cykl życia strony ASP.NET z pełną listą zdarzeń które zachodzą:)

Jeżeli macie taką możliwość to gorąco zachęcam do wykonania takiego mini pet projektu w firmie.

Poniżej zamieszczam listę narzędzi, którą dałem do przetestowania. Narzędzie pogrubione to wybrane, przy większości starałem się dać podsumowujący feedback zespołu dlaczego tak, dlaczego nie (kursywa – ich opinia, normalna czcionka moja adnotacja/opinia). Może się wam lista jak i komentarz do narzędzia przyda, albo da jakieś spojrzenie na pewne technologie – jeżeli macie własne uwagi/sugestie zapraszam do komentarzy :)

Unit Test:

• nUnit – trochę za dużo tych atrybutów, można się pogubić, mało przejrzysty;
• xUnit – prosty w obsłudze, przyjemnie się z niego korzysta;
• mspec – jak język mówiony, super sprawa, jednak lambda expressions trochę komplikują sprawę; inna osoba: a co to są lambda expression? (blah!);
• mbUnit – to jak nUnit;
• MSTest – mówi, że nie może znaleźć pliku a przecież go ma… aaa nie ma, co to za folder?

Test Runners:

• TestDriven.NET – ciekawe, fajne ale daje głównie tylko wykonywanie testów i to też jakoś tak w output window…
• Gallio – fajne i zintegrowane z ReSharperem, czyli nie trzeba z tego osobno korzystać?
• ReSharper – super ciekawe, mogę czyścić klasy! Oo integruje się z StyleCop i działa z xUnit oo CTRL+T, lol Alt+Enter i unit testy dość szybko się wykonują. A co to jest dotCover? O jak fajnie teraz mam Code Coverage w testach;
• Visual Studio – wolne, ale może być plus potem z TFS, jednak wolimy ReSharpera z Gallio;

Mocking Framework:

• TypeMock Isolator – prawie all można z mockować, jednak jakoś tak dziwnie, zresztą reszta jest darmowa, to po co płacić?
• Rhino Mocks – nie odpowiada nam zbytnio konstrukcja, co to jest Playback? Zbytnio tego nie rozumiemy :(
• Moq – proste w obsłudze i w składni, fajnie się z tego korzysta, jednak wciąż mam problem ze zrozumieniem co to jest ten mock i po co on nam; inna osoba: ale on korzysta z lambda expression, a ja wciąż nie wiem co to;
• JustMock – [nie testowany]
• FakeItEasy – [nie testowany]

DI Frameworks:

• Ninject – [nie testowany]
• AutoFac – tak naprawdę nie wiem czemu nie został on wybrany, opinie były różne lub po prostu się nie przyznali, że nie testowali :) tak czy siak możliwe, że z powodów dla których wybrali Castle, zrezygnowali z AutoFac;
• Windsor Castle – bardzo dużo informacji, oraz także ma wsparcie dla nhibernate, fajnie, że na stronie są opisane przykłady jak i gdzie to wykorzystać, także mówiłeś iż z tym już pracowałeś;
• Unity – mhh na SO znalazłem informacje, żeby o nim zapomnieć, więc sądzę, że lepiej z niego nie korzystać (jak to opinia netu może wpłynąć na naszą opinie;));
• StructureMap – jakoś ta strona na starą wygląda, trochę ciężko z dokumentacją (albo szukać nie potrafiliśmy), jakoś tak sami nie wiemy, dziwnie;

ORM:

• Own – chyba nie mamy czasu na napisanie własnego, zresztą po co skoro jest tyle możliwości?
• nHibernate – baaardzo dużo informacji w sieci, dużo przykładów a do tego Fluent nHibernate. Bardzo prosto się z tego korzysta, i fajne jest to, że możemy rozpocząć pracę bez bazy a potem ją stworzyć, plusem jest rozszerzenie do Spatial;
• Entity Framework (Code First could be helpful here) – kłopot mieliśmy z custom mapping na kilku rzeczach, dodatkowo to „obejście” by zaczął działać typ Spatial, trochę denerwujące jest znikające mapowanie w trakcie aktualizacji jeżeli jakąś ręczną operację wykonaliśmy na XMLu;
• LINQ to SQL – fajne i proste i ma wsparcie designera, i podobnie jak EF ma kłopot z Spatial;
• LLBGEN – [nie testowany] ogólne uwagi były, że po co testować skoro inne są darmowe lub wbudowane w VS/.NET;

Database

Lista była przygotowana przed informacją, którą otrzymaliśmy – odgórne dostaliśmy przykaz MS SQL. Ja chciałem iść osobiście z document database bo uważam, że aplikacja idealnie do tego się nadaje, no cóż :) Ogólnie zespół zanim się nie dowiedział od odgórnej decyzji zainteresował się docdb, jednak jak stwierdzili i tak mają dużo do nauki więc może lepiej nie przesadzać. Byli jednak wstanie odpowiedzieć na pytani dlaczego pewne bazy z niżej wymienionych raczej odpadają

• RavenDb – [nie testowany];
• MongoDB – [nie testowany];
• CouchDB – [nie testowany];
• SQLLite – dziwnie… tak w pamięci, mieliśmy mały kłopot by w ogóle z tego skorzystać;
• MySQL – GIS team mówi, że może być kłopot z Spatial bo jakoś serwer ich może z tym nie współpracować – mimo iż typ danych Spatial istnieje;
• Postgresql – tak samo jak MySQL;

Build tools:

Tutaj ogólnie chciałem by coś przetestowali z listy dostępnej tutaj, jednak przez wybranie TFS raczej skoncentrowaliśmy się na opanowaniu BuildTemplates niż na innych „toolach”, co ogólnie spowodowało przy starcie zgrzyt, przekleństwa i kilka zawieszeń serwera. Skończyło się na tym, że buildujemy projekt z wykorzystaniem Albacore i nie jest to proces z automatyzowany – to znaczy, ktoś musi odpalić build i dopiero pliki zostaną przegrane tam gdzie trzeba i jak trzeba.

Source Control:

Tutaj wyjścia nie mieliśmy, od samego początku wszystko miało być na TFS, co nie powiem stanowi pewne utrudnienie w pracy jak chociażby zmarnowanie połowy dnia na synchronizację pracy z weekendu :/

Pozostałe narzędzia:

Kilka bibliotek narzuciłem, ale to głównie dlatego, że też albo ja zbytnio nie znam alternatywy, albo narzędzie ma już swój rynek a wraz z nim community, które jest chętne do pomocy. Do takich narzędzi można zaliczyć zarówno jQuery, Quartz.NET, NBuilder (to dodałem ostatnio), NHibernate/EF/LINQ2SQL Profiler (w zależności jaki framework by został wybrany) i nLog (jakoś nie przepadam za log4net). Przy technologii web app już nie dałem żadnego wyboru MVC 3 z wykorzystaniem Razor syntax. Tutaj byłem „twardy” :)

Uwagi końcowe:

Szczerze, prawie wybrałbym tak samo, jednak w testach poszedłbym w MSpec (dla mnie bardziej intuicyjne), Autofac (dwa projekty z Castle, pora więc się czymś innym pobawić) i bardzo ale to bardzo chciałem pójść w Document Database (ale jednak nie wszystko się dostaje od razu ;)).

Dajcie znać co sądzicie o pomyśle pet project oraz może już sami już coś podobnego zorganizowaliście w firmie?

PS1.: bardzo długo zwlekałem z tym postem, głównie przez to co działo się potem, jednak potrafię to teraz ubrać w słowa więc niedługo powinien pojawić się dodatkowy post.

PS2.: nikt z zespołu nie napisał do końca aplikacji… nawet mogę powiedzieć, że w połowie nie byli, może więc 2 tygodnie dla junior dev i z takim zestawem narzędzi to trochę za mało.

PS3.: zdjęcie: są to tak zwane gitary z opakowania po cygarach, całe community powstało wokół tego pomysłu i jakby ktoś z was był zainteresowany jak taką można zrobić sobie samemu lub pooglądać zdjęcia lepiej wykonanych czy też posłuchać jaki dźwięk one wydaję zapraszam na stronę community Cigar Box Guitars