Conway의 "Life of Life"가 코드 후퇴에 사용되는 이유는 무엇입니까?

Code Retreat는 소프트웨어 개발의 기본 사항에 중점을 둔 하루 종일 교육 이벤트입니다. "글로벌"코드 퇴각의 날이 다가오고 있습니다. 즉, 나는 전에 한 번 가봤으며 엄청난 양의 혼돈이 있었다고 말해야합니다 ... 괜찮습니다.

내가 아직 얻지 못한 것 중 하나는 "Game of Life"가 TDD에 좋은 문제인 이유와 그에 대한 좋고 나쁜 TDD의 느낌입니다.

이것이 꽤 개방 된 질문이라는 것을 알고 있으므로 자유롭게 의견을 보내십시오.

원래 Conway의 게임 오브 게임 (Game of Life)은 2009 년 1 월 첫 번째 코드 리트릿에서 작업 할 Java 애플릿을 가지고 있었기 때문에 선택되었습니다. 오늘의 목표는 타임 박스 연습에 관한 몇 가지 아이디어를 실험하는 것이 었습니다. 우리가 가지고 있기 때문에 GoL 애플릿.

그 후, 두 명의 활동적인 촉진자 (특히 2009 년 여행사 여행 중, 부쿠레슈티의 Alex Bolboaca)에서 GoL을 학습 도구로 사용하는 방법을 조사했습니다. 동시에 우리는 coderetreat 형식을 오늘날의 형식으로 발전시키고있었습니다. 2009 년 Alex는 하나 이상의 다른 문제 (포커 핸드 스코어링)를 시도했지만 GoL만큼 유용하지는 않았습니다. 역사에 대한 자세한 내용은 http://coderetreat.org/history 를 참조 하십시오.

Coderetreat는 단순한 설계 (특히 단순한 설계의 4 가지 규칙), 테스트 중심 개발 및 기타 소프트웨어 개발의 기본 측면에 대한 이해를 향상시키는 데 중점을 둡니다. GoL은 구조적 관점에서 여전히 풍부하지만 이해하기가 매우 간단한 문제라는 이점이 있습니다. Coderetreat에서 연습하는 모든 주제의 예로 사용할 수있는 시스템의 일부를 쉽게 제공합니다. 예를 들어, 여러 방법에서 (x, y) 매개 변수를 사용하는 일반적인 구현은 DRY 원리에 대해 이야기 할 수있는 좋은 기회입니다 (모든 지식은 시스템에서 하나의 유일한 표현을 가져야 함). 체계. 변경 비용을 최소화하는 설계 작성의 예로 사용할 수있는 다른 많은 측면이 있습니다.

현재 다수의 코드 처리를 수행 한 사람들이 상당히 많으며, 여전히 문제의 흥미로운 측면을 실습으로 사용할 수 있습니다.

Conway의 Game of Life는 상당히 강력한 결과를 가져 오는 매우 간단한 코딩 세트이기 때문에 적합합니다. 테스트 주도 개발을 추진하기 위해 그것을 사용하는 것에 관해서는, 당신이 찾고있는 결과가 당신이 작성하는 코드에서 명확하지 않기 때문에 테스트가 상당히 까다로워지기 때문에 베팅했습니다. 글라이더를 가져 오는 코드를 작성하는 것은 이전에 수행하지 않았거나 오랜 시간 동안 수행하지 않은 경우 매우 까다로운 방법입니다. 따라서 TDD는 일반적으로 TDD와 같이 페어 프로그래밍으로 실행될 때 전문 분야를 확장하는 데 적합합니다.

유용한 것들을 가르치는 한; 그것은 일종의 측면 사고에 대한 운동입니다. 코드가 작동하는 방식을 개념화하고, 실행하고, 실패하고, 데이터를 수집하고, 리팩토링하고, 계속 반복해야합니다. 이 모든 것은 TDD에 중요합니다. 실제와 연결하면 "I want X"라는 막연한 요구 사항 문서를 고객에게 건네주는 것과 비슷합니다. 그래서 당신은 그들에게 X를 주지만 X에가는 것은 까다로울 수 있습니다. Conway의 인생 게임은 그것을 가르치는 데 능숙합니다. 또한 코딩하기가 쉽고 일반적으로 많은 코드를 사용하지 않습니다. ( APL 은 구현의 가장 극단적 인 예 중 하나입니다.) 따라서 일반적으로 프로덕션 환경에서 볼 수 있듯이 후퇴가 1 주일 또는 2 주일이 아닌 짧은 세션에 적합합니다.

인생의 게임은 한편으로는 매우 간단한 규칙이며, 다른 한편으로는 확장 성과 관련된 고급 프로그래밍의 최악의 경고가 있습니다. 결과는 결정 론적이지만, 무한한 플레이 필드와 무한한 수의 셀이 처리해야하는 문제가 있습니다.

챌린지 사양에 최소 성능 및 최대 메모리 풋 프린트가 포함 된 경우, 테스트에 빠르게 성장하는 패턴 또는 다양한 방향으로 진행하는 패턴이 포함되며 이는 매우 실망스러운 과제가 될 수 있습니다.

X 반복 후에 알려진 입력과 알려진 출력을 얻었으며 너무 많은 시간이 걸리는 것을 제외하고는 모든 단계를 알고 있습니다. 사양에 맞도록 매우 극단적 인 최적화를 수행해야합니다. 고정 된 크기의 이중 버퍼링 된 2d 비트 배열을 스캔하는 사소한 알고리즘은 성능이 크기의 O (n ^ 2)에 따라 저하되므로 완전히 부적절합니다. 채워진 블록을 새로 생성 된 오브젝트로 처리하면 갑자기 많은 양의 메모리가 소모되고 느려집니다. 제한된 크기의 보드로 모든 것을 분리하면 때때로 작동하지만 때로는 실패합니다 ...

그리고 대부분의 "글로벌"테스트는 성능 표준을 충족시키지 못하므로 작은 목표와 작은 하위 테스트를 개발해야합니다.

그것은 당신이 연습 / 훈련하고자하는 프로세스의 측면에 달려 있습니다.

선택한 접근 방식 / 프로젝트 관리 패러다임에 관계없이 하루는 소프트웨어 엔지니어링의 모든 측면을 다루기에 충분하지 않습니다. 따라서 효과적이기 위해서는 전체의 작은 부분에 집중해야합니다.

예를 들어 TDD의 기술적 측면에 중점을두면 요구 사항 및 고객과의 관계 주위에 큰 회색 영역을 표시하고 솔루션 코딩을 바로 할 수 있습니다.

이와 관련하여 Game of Life는 단순하고 잘 이해되어 있으며 토론을 위해 개방되어야 할 회색 영역이 많지 않기 때문에 좋은 후보입니다. 따라서 테스트 작성을 바로 시작할 수 있고 테스트를 거칠 수 있습니다.

다른 한편으로 목표가 우리가 TDD를 사용하여 요구 사항을 연마하는 방법을 보는 것이라면 인생 게임을 선택했을 수도 있지만 개발자에게 이것이 내가 원하는 것이라고 말하지 않았을 것입니다. 대신 실제로 이름으로 언급하지 않고 힌트와 아이디어를 제공하는 것을 둘러 보았습니다. 그것은 인생의 게임이 참석자들이 거의 신속하게 배치를 통해 볼 수 있기 때문에 이런 종류의 운동에는 너무 간단하다는 것을 증명할 수 있다고 말했다.

그러한 합성 운동에 대한 예를 항상 쉽게 찾을 수있는 것은 아닙니다. 하루 하루 가야 할만큼 단순해야하지만 하루를 마무리하기에는 너무 단순하지 않아야합니다. 그것은 재미 있지만 의미가 없어야합니다 ...하지만 나에게는 조금 독창적이어야합니다. 학생들이 숙제를위한 비디오 클럽 관리 시스템을 만들도록 몇 번이나 요청했는지 기억할 수 없습니다. iiirch.