- RudiaMoon 제안 프로젝트 설계 (1h)
- 프로젝트 요구사항 설명 (10min)
- 테스트케이스 (0.5h)
- 평일에 할 task 나누기 (0.5h)
- 실습1회분량 (0.5h)
- RudiaMoon 제안 프로젝트 검토
- 요구사항 develop - review 해보기
- 걷어낼 세부 요구사항 삭제 (DB조회 -> 콘솔출력)
- 이후에 실습
- 지난번에 하다 마무리 못지은 계산기문제를 하자
- 만약 못 만들어진 3개가 주중에 끝난다면, 옵션기능을 추가로 하면 다음주중에 실습을 계속 진행 할 수 있을 것 같다
ohahohah
- 오늘 뭔가 실습 하면서 쌓여왔던 것들이 몸에 익는게 느껴져서 좋았다. kimsuoh가 기뻐하는 모습을 보니 같이 기뻤다. 오늘 시간을 task별로 나눠서 했는데, 그게 정해져서 집중해서 해야할 일을 구체적으로 정해놔서 가능했던 것 같다. 항상 이런 것을 정해놓지 않으면 여기까지야!가 안되고 조금씩 더 하게 되는게 어려운 것 같다. pomodoro도 하고, task를 정하고 해서 지치지 않고 일을 깔끔히 끝내게 되어 좋았다.
RudiaMoon
- 원래는 실습만 하기로 해서 모였던 거긴 한데, 2시간 동안 설계를 주로 했던것 같다. 그래서 그부분이 조금 아쉽다. 하지만, 평일에 실습을 많이 할 거니깐 기대가 된다.
- 같이 공부한 부분을 응용하는 것이여서, 서로 놓친 부분을 말해주면서 보완한 것 같아서 좋았다.
kimsuoh
- 드라이버랑 내비게이터가 정확히 할 일을 하는 기분이 들었다. 책을 읽은게 도움이 되는구나 생각이 됬다.
- 그리고 오늘 기분이 좋아서 너무 좋았다.
- 평일에 올려놨던 것 개인 컴퓨터에 세팅
(ohahohah : Git에서 PR 내려 받는법 아시나요? 그냥 pull을 받아오는 것은 안된다. 체리픽을 하거나, 마스터로 PR 받고, 나중에 셋팅을 해보자 현재는 마스터로 바로 머지를 하겠다)
- 팀별 페어프로그래밍 회고
- 문제 - 계산기 문제 mob-programming
- kimsunoh 말로 TDD 해보기
- (옵션) aws c9 협업
- (rudia) 회고가 남아있는데 왜 다시 회고하는지 이해 못하겠다.
- (kimsunoh) 읽지 못했다.
- (ohahohah) 아쉬웠던 점, 좋았던 점을 꼽아보자, 아쉬웠던 점은 오늘 보완해서 할 꺼고, 좋았던 점은 오늘도 해볼꺼다
- (rudia) kimsunoh와 할 때는 페어프로그래밍을 한 것 같다. 대화를 나누는 부분을 설계단으로 옮기면 더 좋을 것 같았다. ohahohah 자신의 생각을 입밖으로 내뱉으면서 하는 점을 의식적으로 해야한다는 점이 하이파이브 해야한다
- (ohahohah) rudia와 페어프로그래밍은 계속 해왔었는데, 지루할때 도입해서 한거라 게임처럼 배틀식이라 협업관점하고는 좀 달랐다. 제대로 된 페어프로그래밍하자, 페어프로그래밍이 뭐였지? 하는 의문이 들어서 페어프로그래밍에 대한 자료를 찾아서 공유했다. Rudia와는 거의 1년 가까이 (변형된)페어프로그래밍을 계속 해왔어서 의사소통에 익숙해서 부드럽게 진행할수 있었다. 그리고 좋았던 점은 Rudia가 Kimsunoh와의 페어프로그래밍 회고를 공유하고, 느꼈던 문제점을 상세하게 알려주었다. 그때 안타까웠던 점을 보완해서 시도할 수 있어서 좋았어요.
- (kimsunoh) 오랜만에 해본거라서 좋았어요. 얘기를 해봐서 프로그래밍을하니깐 얘기한 부분을 캐치해서 알려준거랑 얘기하면서 프로그래밍하는거 다시 생각하는거 좋았어요. 설계단에서 해야할 일을 코딩단에서 해야하니깐 오래 걸려서 그 부분이 아쉬웠어요. 다른사람이랑 나랑 이 일을 해결하려면 나부터가 먼저 준비되어있어야하지 않았나 내 생각을 어디에다가 정해놓고 나 스스로 설명하는 점이 필요하지 않을까? 라는 생각이 들었다.
- (ohahohah) 두 사람 페어프로그래밍에서 처음 3분 30초부터 시작해서 페어프로그래밍 바꿀 턴 시간을 맞춰가는 것도 좋았다. sunoh이야기는 내가 이해하기로는 '내 생각이 정리되어있어야 다른 사람에게 전달하고 이야기할 수 있다'인 거 같다. 다만 덧붙이고 싶은 것은 TDD는 (로직을 모르는)불확실한 상황에서 요구사항에 대한 테스트부터 만들고 시작한다. 미지의 세계를 탐험하는거라 내 생각을 정리해서 전달하는게 위험할 수 있다고 생각함. 요구사항을 만족시키기 위한 테스트케이스가 아니라 내 로직을 검증하기 위한 테스트를 만들게 된다.로직을 견고하게 전달하는 것보다 내가 생각하는 요구사항을 말로 설명하고 공유하는 것부터 시작이라고 생각.
- (kimsunoh) 요구사항 해석에 대해서 이견이 생겼었음. 요구사항 분석이 더 필요. (r과 다르게 이해했던 걸 실제 요구사항 예시들어 설명) 내가 이해한 것과 다르게 다른 사람이 한다면 그 상황에 대해 물어볼 수 있을 정도의 요구사항 이해도가 필요.
- (ohahohah) Rudia와 페어프로그래밍할때 제가 네비게이터 역할을 잘 안한듯. 네비게이터 안하고 그냥 딴짓함. 저거 막히니까 제가 찾아볼게요. 하고 막 찾고 나서 보면 Rudia는 이미 그 문제 해결하고 다른 로직짜고 있음ㅋㅋㅋ
- (kimsunoh, rudia) 서로의 테스트 배틀 발생 - 혜영 테스트 케이스 만들고, 선오 테스트 케이스 따로가 되어버림.
- (ohahohah) 테스트배틀ㅋㅋㅋ 페어프로그래밍 아티클을 검색하다가 '버그는 줄어들었지만 페어프로그래밍한 두 사람과의 관계가 멀어졌다'는 댓글을 봤다ㅋㅋㅋㅋ 팟캐스트에서 들을때는 드라이버가 멈춰서 설명하지 말고 내가 지금 무얼하는지 중얼중얼하라는 말을 했다. 네비게이터는 내가 제안한 로직대로 드라이버가 안갈 때 답답함. 그래도 참고 흐름을 따라가려고 계속 노력해가자. 설계 이야기는 충분히 하되 설계가 변경되는 걸 두려워하지 말자. 한 번에 완
정리
- 버그는 줄이고, 둘사이는 멀어지지 말자
- 상대방의 코드를 존중하자
- (kimsunoh) 우산 만드는 걸 예시로 소개함
- 검은펜 : Test 목록 나열
- 파란펜 : Test assert 조건 정리
- 빨간펜 : Test 케이스 카테고리 지정
-
(옵션) 커스텀 구분자를 지정할 수 있다. 커스텀 구분자는 문자열 앞부분의 “//” 와 “\n” 사이에 위치하는 문자를 커스텀 구분자로 사용한다.
-
쉼표(,) 또는콜론(:)을구분자로가지는문자열
-
구분자를기준으로분리한각숫자의합을반환
-
숫자이외의값또는음수를전달하는경우 RuntimeException 예외를 throw한다
- 문자열에 쉼표나 콜론이 존재하는지
- 구분자 형식이 맞는지 (3:::2:4)
- 숫자이외의 값 또는 음수가 입력문자열인 경우 RuntimeException 예외를 throw하는지
- 가:나:다
- 덧셈을 제대로 하는지
- 입력값에 대한 덧셈계산을 제대로 하는지 (인수테스트)
- 입력문자열이 null일때 RuntimeException 예외를 throw하는지
- ohahohah - 우리 90분 걸렸다
- kimsunoh- 아침에 너무 시간 적다. 하나의 테스트케이스만 한다. 문 - 동의
- ohahohah - 맥락 끊긴다
- RudiaMoon - 맥락 끊기는건 답이 없어요. 우리가 공부를 미리 해오는 성격은 아니잖아요 -_- ?
- kimsunoh - 사실...이다 ㅎㅎㅎ, 오 - 맞다 안한다.
- kimsunoh - 책은 책 대로 하고 2주에 한번씩 만나서 TDD 프로젝트 한다 - 모두 동의
ohahohah
- 좋았던 거
- 오늘 정말 좋은 포인트가 많았다. 근데 다 기억이 안남ㅠ
- 오늘 서로서로 보완하면서 진행이 된 점
- 2명씩 만나서 페어프로그래밍 했던것 공유하는 회고도 좋았다.
- 아쉬웠던 점
- 오늘 너무 오래해서 힘들었다. 시간을 딱 정해놓고 하는게 좋을 것 같다.
- 셋이서 하니깐 말을 많이 하게 되서 힘들었다.
- 제안
- 하다보면 시간이 길어짐. 이번에 해야할 최소한의 Task를 정하자.
- Task 기록을 남기자!
- 'n시간동안 할 수 있는 최소한의 task는 이정도'라고 해두어도 실제 예상과 벗어난다. 다음부터는 task가 얼마나 걸리는지 시간을 재서 기록하자. 다음에 이 기록을 실제 할 수 있는 양을 파악하는 참고자료로 써보자.
RudiaMoon
- 설계단계에서 용어정의, 구체화
- 이어폰 만들기 실습할때 용어정의와 구체화를 했던 것 처럼, 테스트 케이스를 만들때도 용어정의 구체화 두 단어를 생각하며 하자
- 호응 2명보단 세명 호응 더 좋았다.
- 화이파이브와 괴성이 좋았다. 리액션을 제대로 받는 기분!!!!!!
- 앞으론 오프라인 미팅 실습만
- 만났을 때는 실습 위주로만 했으면 좋겠다.
- 사실, 코드를 작성한 것 보다 논의와 얘기가 더 많았다
- 오 - 앞의 과정도 중요하게 생각한다./온라인에서 정리해서 오프라인 와서 하는 것도 좋은 방법일 것 같다./논의와 코드 작성 부분을 하루에 하지말자. 힘들자. 두 번에 나눠서 하자.
- exception 처리 꿀팁알게되어 좋았다
kimsunoh
- 위키피디아 집단지성과 같이 셋이하니깐 셋의 관점이 달라서 좋았어요.
- 한글로 테스트케이스적는거 너무 좋았아요.
- 오프라인 미팅 실습 일자 잡기
- 다음 실습 Task별로 시간 측정하기
- 오프라인 미팅 실습 전, 총괄 회고
- 오 - 오늘은 TDD 학습과 실습을 동시에 해서 시간이 오래 걸린 듯
- 문 - 총괄 회고는 실습 전날 온라인에서 할 수 있을 것 같다
- Agile 팟캐스트, slack에 올려진 아티클들을 읽어보기
- 서로 이해하는 수준이 같은 시점에서 시작할 수 있다
- 간단한 소감 공유하기
=======
RudiaMoon
- 어제 힘들었던 부분들이 해결된 기분이 들어서 좋았음. 예를 들어 어제는 설명하느라 시간을 많이 들였는데, 그냥 중얼중얼해도 된다는 말을 듣고 편하게 할 수 있었음.
- 저번에는 설계에 대한 생각이 달라서 그 부분을 맞추는 과정이 오래걸렸는데 오늘은 먼저 설계에 대해서 같이 이야기해보고 기록하고 나서 구현에 들어가서 좋았음.
- 저번 시간에 힘들었던 부분 보완되어서 기뻤음
(ohahohah : 회고에서 어떤 부분이 힘들었는지 짚었기때문에 오늘 바로 고칠 수 있었다고 생각함. 어떤 부분이 문제인지 알았기 때문에 피드백을 바로 줄 수 있었음.)
ohahohah
- 서로 설계관점이 달라 흥미로웠어요
- 오늘 얘기한 해야할 포인트들 다 기록한 Rudia 모습 배우고 싶었다.
- 그동안 변형된 페어 프로그래밍했는데 코드 배틀식을 했는데 그게 습관이 남아있어서 아차 싶었다(한 명이 코딩할때 딴짓하고). 습관 고치는데 시간 걸리겠다. 싶었음
RudiaMoon
- ohahohah가 말했던 것처럼 페어프로그래밍의 원래 역할을 상기했으면 좋겠다.
ohahohah
- 페어프로그래밍의 원래 역할을 상기했으면 좋겠다.
- 보완? 페어프로그래밍이 뭔지에 대해서 우리는 모른다. 좋은 사례? 방법을 찾아보자. (김창준 덕후이기 때문에 김창준 애자일 팟캐스트 추천 - 링크 보내드리겠음)
- 한명이 코딩할때 딴짓하지말자. 네비게이터의 역할은 무엇일까?
ohahohah
- 다른 사람과 했을때 아쉬웠던 점 공유했던 거. 피드백을 구한 거(이런 점 안좋았는데 어떻게 고칠까? 라고 질문던지는 거)
RudiaMoon
- 초록막대 후에 리팩토링하기
kimsunoh
- 재미있었어요.
- 시간이 부족하다라는 느낌이 많이 들어요. 코드를 짜는 시간보다 상대방과 대화를 하며 설득시키는 시간이 더 들었으므로 그런 느낌이었다.
RudiaMoon
- 아침 30분 안에 pair로 코드리뷰 하는게 힘들 것 같다
- 오늘 테스트 연습은 90분 걸림
- 같이 pair하는 걸로는 시간이 너무 부족하다. 이미 요구사항 분석과 프로그래밍된 코드를 놓고 코드리뷰를 하는 것은 가능 할 것 같다.
- ohahohah님과 페어프로그래밍 할때와 비교한다면 내가 생각한 의도의 코드가 아니라 @kimsunoh님과 의견을 맞춰가면서 코드를 진행하려니깐 로직이 바로 그려지지 않아 페어프로그래밍시 속도가 느려져서 내 자신이 답답해졌다.
RudiaMoon
- 출력값을 테스트할 때가 아쉬웠다
- 내가 생각하는 출력값 테스트와 @kimsunoh가 생각하는 테스트가 달랐다
- 이미 나와있는 테스트 틀을 가져다 썼으면 시간을 단축 시킬 수 있었을 것 같다.
kimsunoh
- 타이머를 키고해서, 대화를 충분히 나눌 수 있는 시간이 부족했다
- 프로그래밍 요구사항 정리를 할때, 다이어그램 만들 듯이 그때 메서드명을 정하고 개발을 시작해야 됐을 것 같다
- 프로그래밍 하면서 동시에 메서드를 정하려고 하니깐 시간이 많이 든 것 같다
RudiaMoon
- TDD 배운것을 학습할 수 있었다
- 시간이 빨리지나갔다. 그랬다는건 재미있었다는 뜻과 같다고 생각한다
kimsunoh
- 테스트코드를 다이렉트로 처음부터 짠게 너무 오랜만이어서, 새록새록 했다
- 대화를 계속 하면서 하니깐, 의견을 모을 수 있어서 좋았다
- 이거는 pair 프로그래밍의 장점인 것 같다.