1marksguitarandampcombo

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

PODOBNE ARTYKUŁYWIĘCEJ OD AUTORA

18 KOMENTARZE

  1. To jest pomysł tak niesamowicie wypasiony, że aż słów brak. Szacun za przekonanie firmy do zrobienia czegoś takiego i przygotowania całego przedsięwzięcia.
    Osobiście nie znam firmy która mogłaby takie coś zrealizować.

  2. Fantastic :)
    Miałem kiedyś możliwość robienia czegoś takiego samodzielnie i jest to super sprawa. A że robi to zespół to jest to super ^N.
    Właśnie wszedłeś na ścieżkę budowania zespołu. Z moich obserwacji wynika, że zespołów raczej nie ma (sam pracowałem tylko w jednym), a raczej grupy ludzi wykonujących ten sam projekt (czyli ‘zespół’ tylko z nazwy). I nie dotyczy to tylko programowania, ale ogólnie słabego poziomu zarządzania ludźmi.

  3. Artykul i pomysl bardzo fajny. Ale w praktyce w wiekszosci przypadkow to sie nie uda, ze wzgledu na istnienie (tak jak Artur napisal) ‘zespolow tylko z nazwy’.

  4. Świetny artykuł, bardzo ciekawy pomysł na integrację zespołu i to jak sprawić, aby zespół przyjął twoje wybory za swoje :)

  5. Wszystko fajnie, ale ja osobiście nie znam firmy którą stać na takie 2 tygodniowe zabawy :(

  6. bardzo dobry komentarz dostalem na facebook:

    _zespoły istnieją nie tylko z nazwy – po prostu w naszej polskiej mentalności ich nie dostrzegamy_

    zgadzam sie z tym, zupelnie inne mamy podejscie do zycia i pracy niz inne kraje (choc tez sa takie podobne do nas). czesc tego jest tez spowodowana przez naszym menagerio.. ale co zrobic :) co najwyzej zmienic prace :)

  7. :) o, a ja znam i to wiele, tylko one wola ten czas przeznaczyc na cos innego jak na przyklad pre-sales lub "prezentacja dla zespolu" zamiast "zabawy z kodem". Pamitam jakby to bylo wczoraj, po zrobieniu prezentacji dla ludzi z firmy przy rozmowie o ocenie rocznej dostalem "-" bo moja prezentacja nie zawierala PowerPointa to rozeslania.

    zreszta jakis rozwoj programisty musi byc, szkolenia nie skutkuja o czym pisal @Procent ostatnio, metody nauczania poprzez prezentacje firmie przez senior dla junior tez nie daja duzo, wiec albo firmy sie naucza ze to co robia nie dziala, albo beda tracic co lepsze jednostki na rzecz innych firm ktore to rozumieja.

    a jak nie mozna miec pet project, to z komercyjnego zrobic sobie pole do zabawy. Ile razy przestrzelilo sie z wymaganiami? "ja to bym zrobil w 10 dni", potem menagerio, "dobra 20 dni", potem sales "no nie, 20 to sie nie oplaca, czas PMa bedzie 20, czyli lacznie 40", a nakoncu idzie oferta na "100 dni" :) wiec czas jest :) trzeba tylko dobrze to wpasowac :)

  11. Gutek. Rewelacja. Dawno nie czytałem tak dobrego postu, który poza relacją z bardzo ciekawego i udanego eksperymentu (a jednak) dodatkowo wrzuca zestawienie co ciekawszych narzędzi.

    Pozdrowienia
    Arek

  12. [quote]Ile razy przestrzelilo sie z wymaganiami? "ja to bym zrobil w 10 dni", potem menagerio, "dobra 20 dni", potem sales "no nie, 20 to sie nie oplaca, czas PMa bedzie 20, czyli lacznie 40", a nakoncu idzie oferta na "100 dni"[/quote]

    Z mojego doświadczenia wynika raczej odwrotna praktyka: ja mówię że zajmie mi coś 40 dni, a potem dowiaduję się, że oferta idzie na dni 10. I nie dość, że nie ma czasu na żadne zabawy – trzeba na uszach stawać, żeby w ogóle się w czasie wyrobić. A na naukę/rozwój zostaje czas prywatny. :(

  13. Super tekst. Super pomysł. To jest jeden z tych minusów pracy na własną rękę (własna działalność). Brakuje mi pracy w grupie, burzy mózgów, rozmów z zespołem ludzi, itp :)

    Fajnie, że udało Ci się coś takiego zorganizować w firmie. Swego czasu (w firmie Trimtab) miałem takie możliwości, to było piękne. :)

  16. dzieki :) ale zas co do burzy mozgow, to jednak wciaz u mnie kroluje skype i kilka osob na nim – mimo wszystko, to sa wciaz junior i czasami po prostu mozna stanac na pytaniu bo bedzie trzeba wytlumaczyc wszystko od podstaw, potem dac 2 dni na przemyslenia i potem dopiero zrobic burze mozgow :)

  17. Oznaczyłem w RSSach gwiazdką i tak odkładałem i odkładałem przeczytanie tego posta, aż w końcu…
    Bajer! Pomysł bomba. Ja razem z zespołem wpadliśmy kiedyś na pomysł zrobienia czegoś podobnego, tylko dla jednej kategorii – bazy danych i frameworki z tym związane. Każdy dostał coś dla siebie i potem prezentacja przed wszystkimi (jakieś 3 zespoły, 20 osób?). Należało po prostu w 5 minut sprzedać się jak najlepiej. Zespoły pokusiły się nawet o to, by osoba prezentująca była odpowiednio wyznaczona i ubrana!

  18. dzieki :)

    zas co do prezentacji pomyslow (swietny pomysl z ubraniem! :)), ja jednak nie przepadam ze taka forma nauki – wole usiasc i samemu napisac prototyp, mi po prostu pozostaje wiecej w glowie niz z prezentacji nawet jezeli potem mam mozliwosci wrocenia do nie.

    To co jednak jest fajnego w tym, ze przyokazji dev uczy sie jak prowadzic prezentacje – wyczes. w koncu nie jestesmy tylko i wylacznie od klepania kodu a takie cos moze zaowocowac w przyszlosci chyba nawet bardziej niz nauka framework :)

Comments are closed.