Dlaczego „Gra życia” Conwaya jest używana do wycofywania kodu?


15

Code Retreat to całodzienne szkolenie, które koncentruje się na podstawach rozwoju oprogramowania. Zbliża się „globalny” dzień wycofania kodu i nie mogę się doczekać. To powiedziawszy, byłem już w jednym z nich i muszę powiedzieć, że był ogromny chaos ... co jest w porządku.

Jedną z rzeczy, których wciąż nie rozumiem, jest to, dlaczego „Gra życia” jest dobrym problemem dla TDD i jakie to dobre i złe TDD.

Uświadom sobie, że to dość otwarte pytanie, więc możesz je komentować.


To wydaje się bardzo zorientowane na dyskusję pytanie, które najlepiej byłoby zadać na naszym czacie inżynierii oprogramowania .
Adam Lear

@Anna Lear: Dzięki, ale nie chcę rozmawiać, szukam odpowiedzi. Jeśli to nie jest dobre pytanie, jest w porządku.
wpadki

3
@AnnaLear Myślę, że pytanie jest bardziej na temat, niż OP przypisuje się.
Tom Squires

1
@Tom Myślałem o tym sam i cieszę się, że dobrze sobie radzi. Chętnie się myli. :)
Adam Lear

Odpowiedzi:


26

Pierwotnie gra w życie Conwaya została wybrana, ponieważ mieliśmy pod ręką aplet Javy do pracy nad pierwszym koderetreat'em w styczniu 2009 roku. Celem tego dnia było eksperymentowanie z pewnymi pomysłami na temat praktyki czasowej, a my po prostu wybraliśmy aplet GoL, ponieważ go mieliśmy.

Po tym jednak, jako kilku aktywnych facylitatorów (szczególnie ja podczas mojej podróży czeladnika w 2009 roku i Alex Bolboaca w Bukareszcie) badałem wykorzystanie GoL jako narzędzia edukacyjnego. Jednocześnie ewoluowaliśmy format przetwarzania kodu do tego, czym stał się dzisiaj. W 2009 roku Alex wypróbował co najmniej jeden inny problem (zdobywanie punktów w pokerze), ale nie uznał go za tak przydatny jak GoL. Więcej informacji o historii można znaleźć na stronie http://coderetreat.org/history

Coderetreat koncentruje się na poprawie naszego zrozumienia prostego projektowania (w szczególności 4 zasad prostego projektowania), rozwoju opartego na testach i innych podstawowych aspektów rozwoju oprogramowania. Zaletą GoL jest to, że jest bardzo prostym problemem do zrozumienia, a jednocześnie jest bardzo bogaty z perspektywy strukturalnej. Z łatwością udostępnia części systemu, które mogą być wykorzystane jako przykłady wszystkich tematów, które ćwiczymy w programach typu coderetreat. Na przykład wspólna implementacja, która przyjmuje parametry (x, y) w wielu metodach, jest świetną okazją do rozmowy o zasadzie DRY (każda wiedza powinna mieć jedną i tylko jedną reprezentację w systemie) w odniesieniu do topologii system. Istnieje wiele innych aspektów, które można wykorzystać jako przykłady budowy projektu minimalizującego koszty zmian.

Jest już sporo osób, które dokonały wielu zabiegów kodowych i wciąż znajdują ciekawe aspekty problemu, które można wykorzystać jako praktykę.


10

Gra życia Conwaya byłaby dobrze dopasowana, ponieważ jest to dość prosty zestaw kodowania, który ma niezwykle potężne wyniki. Jeśli chodzi o użycie go do napędzania programowania opartego na testach, postawiłbym go, ponieważ testy byłyby dość trudne do napisania, ponieważ wyniki, których szukasz, nie są oczywiste z kodu, który piszesz. Pisanie kodu, który daje szybowce, jest dość trudne, jeśli nie robiłeś tego wcześniej lub nie robiłeś tego przez długi czas. Dlatego nadaje się do rozciągania sztuki tej dyscypliny, szczególnie gdy jest wykonywana w programowaniu parowym, jak zwykle TDD.

Jeśli chodzi o nauczanie cię przydatnych rzeczy; jest to ćwiczenie w rodzaju myślenia bocznego. Musisz pojąć, jak będzie działał twój kod, uruchomić go, zobaczyć, jak się nie udaje, zebrać dane, przefakturować i kontynuować iterację. Wszystkie te rzeczy są kluczowe dla TDD. Łącząc go ze światem rzeczywistym, jest to podobne do klienta, który przekazuje ci niejasny dokument wymagań, który mówi tylko „Chcę X”. Dajesz im X, ale dotarcie do X może być trudne. Gra życia Conwaya jest dobra w nauczaniu tego. Kodowanie jest również dość łatwe i zazwyczaj nie wymaga to wielu ton kodu. ( APL jest jednym z bardziej ekstremalnych przykładów implementacji.) Jest więc odpowiedni dla krótkich sesji, które miałoby miejsce rekolekcje, a nie tygodniowej lub dwutygodniowej iteracji, jak to zwykle bywa w środowisku produkcyjnym.


10
Uznałbym, że szybowiec jest zachowaniem „wschodzącym”. Twoje testy jednostkowe muszą tylko zakodować reguły dotyczące życia i śmierci komórek, biorąc pod uwagę określoną liczbę sąsiadów.
Robert Harvey

1
Szybowiec to zdecydowanie nowe zachowanie. Niektórzy uczestnicy programów typu coderetreats opracują większe testy, które obejmują takie rzeczy, jak szybowiec, ale są to testy orientacyjne, a nie testy zorientowane na jednostkę / TDD. Zachowanie wynika z budowania reguł, które są dobrze zdefiniowane.
coreyhaines 24.11.11

3

Gra w życie to z jednej strony bardzo prosty zestaw reguł, z drugiej zawiera jedne z najgorszych zastrzeżeń zaawansowanego programowania, związane ze skalowalnością . Chociaż wyniki są deterministyczne, istnieje wyzwanie, jakim jest nieskończone pole gry i nieskończona liczba komórek do przetworzenia.

Jeśli specyfikacja wyzwania obejmuje minimalną wydajność i maksymalny ślad pamięci , testy obejmują szybko rosnące wzorce lub wzorce, które przemieszczają się w różnych kierunkach daleko i szeroko, może to stać się bardzo frustrującym wyzwaniem.

Otrzymałeś znane dane wejściowe i wyjściowe po iteracjach X i znasz wszystkie kroki, aby się tam dostać ... z wyjątkiem tego, że kroki trwają zbyt długo i zbyt długo. Musisz wykonać kilka ekstremalnych optymalizacji, aby dopasować je do specyfikacji. Trywialny algorytm skanowania podwójnie zbuforowanej tablicy 2d bitów o stałym rozmiarze staje się całkowicie nieodpowiedni, ponieważ jego wydajność spada z O (n ^ 2) wielkości. Traktowanie wypełnionych bloków, gdy nowe odradzane obiekty nagle zjadają mnóstwo pamięci i stają się wolne. Rozdzielanie wszystkiego na tablice o ograniczonych rozmiarach czasem działa, czasem się nie udaje

A ponieważ większość „globalnych” testów nie spełni standardu wydajności, musisz opracować mniejsze cele, mniejsze podtesty, które rozwiążą zastrzeżenia…


2

Wszystko zależy od tego, w jakim aspekcie procesu chcesz ćwiczyć / trenować.

Pojedynczy dzień nie wystarczy, aby objąć wszystkie aspekty inżynierii oprogramowania, niezależnie od wybranego paradygmatu podejścia / zarządzania projektami. Aby więc była skuteczna, prawdopodobnie powinieneś skoncentrować się na małym podzbiorze całości.

Jeśli przykładowo skupiasz się na technicznych aspektach TDD, możesz chcieć odejść od dużych szarych obszarów wokół wymagań i relacji z klientem i od razu przejść do kodowania rozwiązania.

Pod tym względem Gra w Życie jest dobrym kandydatem, ponieważ jest prosta, dobrze zrozumiana i nie ma wielu szarych obszarów, które wymagają otwarcia na debatę. W ten sposób możesz od razu zacząć pisać test i kodować go.

Z drugiej strony, jeśli celem było sprawdzenie, w jaki sposób możemy wykorzystać TDD do dopracowania wymagań, mógłbym wybrać grę życia, ale nie powiedziałbym twórcom, że tego właśnie chcę. Zamiast tego krążyłbym wokół, podając wskazówki i pomysły, nie wspominając o tym po imieniu. To powiedziawszy, gra w życie może okazać się nieco zbyt prosta do tego rodzaju ćwiczeń, ponieważ uczestnicy najprawdopodobniej dość szybko przejrzą sztuczkę.

Przykłady takich syntetycznych ćwiczeń nie zawsze są łatwe do znalezienia. musi to być proste, aby zrobić to w ciągu jednego dnia, ale nie zbyt proste, aby przejść przez cały dzień. To musi być zabawa, ale nie bez znaczenia ... Ale dla mnie to musi być trochę oryginalne, nie pamiętam, ile razy poproszono mnie o nakłonienie uczniów do stworzenia systemu zarządzania wideoklubem do pracy domowej ... iiirch.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.