niedziela, 16 listopada 2014

Po Code Retreat 2014

Gdy piszę te słowy przyszły już pierwsze opinie na googlowym formularzu. Ludziom się generalnie podobało a po obecności słów "ch*j" i "du*a" wnioskuję, że studentom także.

Za rok trzeba będzie mocniej się postarać by ludzie mieli więcej szans popełnić błędy w kodzie i się na nich uczyć zamiast rozkminiać samą grę nad kartką. Najlepiej od razu podpowiedzieć kilka niedoskonałych rozwiązań na standardowe pytania - jak reprezentować planszę i od czego zacząć pisać testy.

Przez ostatnie dwa miesiące słyszałem wiele głosów w stylu "ej no znowu ta gra życie, może coś nowego..." a koniec końców chyba nie licząc jednej lub dwóch osób wszyscy uczestniczyli po raz pierwszy i doskonale pojechaliśmy "klasyką".

  1. Sesja wstępna-dowolna
  2. TDD i tylko jeden poziom zagłębienia kodu w metodach
  3. Jeden poziom zagłębienia, metody maksymalnie 5 linii długości i brak else
  4. obiad(oj jedzenia sporo było)
  5. Sesja "cicha" oraz do wyboru albo object-calisthenics lub not only OOP - wszyscy wybrali to pierwsze ;)
  6. Zostawiamy kod z poprzedniej sesji i mamy dodatkowe wymagania

Dominowała Java ale pojawił się też .Net, Ruby i Scala. Im więcej języków tym ciekawiej.

Dziękuję wszystkim za przybycie i organizatorom za zadbanie o wszystkie detale spotkania.

Ściana w kodzie

podobny temat poruszyłem już tutaj : o instanceof

Ciekawy problem powstaje gdy rozwiazujemy zadanie tworząc abstrakcję "Cell" i klasy pochodne "LiveCell" oraz "DeadCell". Jednocześnie gdzieś w kodzie musimy zliczać ilość żywych komórek - jak to zrobić?. Cześć osób dodaje do Cell metodę "isAlive"

Główny problem z tym rozwiązaniem polega na tym, że jeśli wyobrazimy sobie diagram klas to generalnie ten kwadrat co jest na górze nie powinien nic wiedzieć o tych co są na dole (chyba, ze ktoś rysuje do góry nogami) bo jeśli wie to jest ryzyko, że jak się zmieni coś na dole to trzeba będzie zmieniać przez tę zależność dosłownie wszystko. A jeśli w kwadracie na górze mamy metodę "isAlive" to on już wie, że gdzieś tam dziedziczy z niego żywa komórka, a teoretycznie cały bajer polega na tym aby bezboleśnie dodawać nowe podtypy bez mieszania w tym co jest zrobione do tej pory. Jeśli nie tak to jak można inaczej?

Prześledźmy taki tok myślowy :

  • Jeśli ktoś reprezentuje komórki przy pomocy boolean na tablicy to wykorzysta wartość true/false do stwierdzenia czy komórka jest żywa
  • Podobnie jeśli reprezentujemy je przy pomocy 0 i 1 - tutaj też nie będzie problemu.
  • enum {DEAD,ALIVE} - również łatwo rozpoznać typ komórki
  • LiveCell, DeadCell - tutaj można postąpić analogicznie. Generalnie dziedziczenie pozwala nam przenieść część logiki z kodu do kompilatora, który to wybierze odpowiednia implementację przez co sam kod jest bardziej elastyczny. Ale to nie znaczy, że wszystko ma się sprowadzać do tylko i wyłącznie tego mechanizmu. Tutaj łatwo można sprawdzić typ komórki w jakimś niezależnym i łatwym do testowania komponencie przy pomocy budzącego emocje "instanceof". Jeśli używamy tego mechanizmu do sprawdzenia ile elementów danego typu jest kolekcji wtedy raczej jest to ok, błąd wystąpi wtedy gdy używamy go by na podstawie typu wykonać jakieś operacji dla żywej komórki(i co gorsze rzutowanie) - wtedy w zasadzie wracamy do bazowego "if (komorka zywa) evoluujTak else evoluujInaczej"

Email Calisthenics

W trakcie ostatecznej retrospektywy wpadliśmy również na pomysł nowego ćwiczenia - bardziej w kierunku tych ludzie co więcej "komunikują niż programują".

W trakcie "Global Day of Email Retreat" uczestnicy grają w "Grę w życie" i mają ją rozwiązać odpowiednim łańcuchem maili. Ograniczenia.

  1. Respect people's time - Max 3 Recipients per email
  2. Focus - Only one discussion thread per email
  3. Save our eyes - whole email is written with the same font
  4. Don't overreact - No Top Management in CC
  5. Merit Arguments - No personal attacks in an email
  6. Avoid templates - participants can not use words "ASAP,Unacceptable,Concerned,Urgent or Opportunity"
Czy coś w ten deseń...

2 komentarze: